This regressed in 262812@main because we moved the code to enter AC mode when always compositing to the DrawingArea constructor to make sure the UI process starts receiving IPC messages for the new drawing area as soon as possible after a drawing area switch due to cross origin navigation. The problem now is when going back after a cross origin navigation because there's a display refresh monitor switch too, but to create the proper display refresh monitor we need an already created drawing area, since WebChromeClient::displayRefreshMonitorFactory() returns the WebPage drawing area, not yet set during its constructor. So, we need to enter AC mode right after the drawing area is created instead of in the constructor to ensure the right display refresh monitor is created. This doesn't fail in GTK3 because we create a DisplayRefreshMonitorGtk, but that's not the right one either, since it's expected to be used only for non-AC mode.