The popup is not using APZ. WebRender + no APZ is not a well-supported configuration, and I don't think we want to put effort into supporting it, because Fission is going to require APZ anyways. Rather, we want to enable APZ in the popup. I was under the impression we did that in bug 1493208, but the pref we flipped there only affects windows of type `eWindowType_popup`, and in this case, the window type is `eWindowType_dialog`. I looked into why that is, and it seems to me that windows created by extensions using `browser.windows.create({ type: "popup" })` (as [this extension does](https://github.com/aqt/webext-popup/blob/845fe4ec9cde0b05f07d191e61df9778e9d7c9c6/content/background/background.js#L258)) always end up as `eWindowType_dialog`? I base that on the following: * The implementation of `browser.windows.create()` [adds](https://searchfox.org/mozilla-central/rev/196daa17009ea2aaad62458edf033201d2750d98/browser/components/extensions/parent/ext-windows.js) `"dialog"` to the window features list if `type: "popup"` was provided. It does not seem to add `"popup"` to the feature list anywhere. * The window features are then translation into `nsIWebBrowserChrome` flags: * "popup" in the feature list [causes](https://searchfox.org/mozilla-central/rev/196daa17009ea2aaad62458edf033201d2750d98/toolkit/components/windowwatcher/nsWindowWatcher.cpp#1917) `CHROME_WINDOW_POPUP` to be set * "dialog" in the feature list [causes](https://searchfox.org/mozilla-central/rev/196daa17009ea2aaad62458edf033201d2750d98/toolkit/components/windowwatcher/nsWindowWatcher.cpp#1985) `CHROME_OPENAS_DIALOG` to be set * Finally, the window type is set based on the chrome flags: * it's [initialized](https://searchfox.org/mozilla-central/rev/196daa17009ea2aaad62458edf033201d2750d98/xpfe/appshell/nsAppShellService.cpp#591) to `eWindowType_dialog` if `CHROME_OPENAS_DIALOG` is set * it's [changed](https://searchfox.org/mozilla-central/rev/196daa17009ea2aaad62458edf033201d2750d98/xpfe/appshell/nsAppShellService.cpp#595) to `eWindowType_popup` if `CHROME_WINDOW_POPUP` is set That seems to be consistent with bug 1253128 comment 0 which states that `type=popup` in the `browser.windows` API should create a "dialog" type window. (cc @kmag in case I'm overlooking something obvious here) Based on this, my tentative plan is to enable APZ for windows of type `eWindowType_dialog`. To limit the scope of this change, I plan to do it only for dialogs with remote content, similar to our current treatment of `eWindowType_popup` (otherwise, presumably some browser-native dialogs may be affected which may not be desirable).
Bug 1695822 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The popup is not using APZ. WebRender + no APZ is not a well-supported configuration, and I don't think we want to put effort into supporting it, because Fission is going to require APZ anyways. Rather, we want to enable APZ in the popup. I was under the impression we did that in bug 1493208, but the pref we flipped there only affects windows of type `eWindowType_popup`, and in this case, the window type is `eWindowType_dialog`. I looked into why that is, and it seems to me that windows created by extensions using `browser.windows.create({ type: "popup" })` (as [this extension does](https://github.com/aqt/webext-popup/blob/845fe4ec9cde0b05f07d191e61df9778e9d7c9c6/content/background/background.js#L258)) always end up as `eWindowType_dialog`? I base that on the following: * The implementation of `browser.windows.create()` [adds](https://searchfox.org/mozilla-central/rev/196daa17009ea2aaad62458edf033201d2750d98/browser/components/extensions/parent/ext-windows.js) `"dialog"` to the window features list if `type: "popup"` was provided. It does not seem to add `"popup"` to the feature list anywhere. * The window features are then translated into `nsIWebBrowserChrome` flags: * "popup" in the feature list [causes](https://searchfox.org/mozilla-central/rev/196daa17009ea2aaad62458edf033201d2750d98/toolkit/components/windowwatcher/nsWindowWatcher.cpp#1917) `CHROME_WINDOW_POPUP` to be set * "dialog" in the feature list [causes](https://searchfox.org/mozilla-central/rev/196daa17009ea2aaad62458edf033201d2750d98/toolkit/components/windowwatcher/nsWindowWatcher.cpp#1985) `CHROME_OPENAS_DIALOG` to be set * Finally, the window type is set based on the chrome flags: * it's [initialized](https://searchfox.org/mozilla-central/rev/196daa17009ea2aaad62458edf033201d2750d98/xpfe/appshell/nsAppShellService.cpp#591) to `eWindowType_dialog` if `CHROME_OPENAS_DIALOG` is set * it's [changed](https://searchfox.org/mozilla-central/rev/196daa17009ea2aaad62458edf033201d2750d98/xpfe/appshell/nsAppShellService.cpp#595) to `eWindowType_popup` if `CHROME_WINDOW_POPUP` is set That seems to be consistent with bug 1253128 comment 0 which states that `type=popup` in the `browser.windows` API should create a "dialog" type window. (cc @kmag in case I'm overlooking something obvious here) Based on this, my tentative plan is to enable APZ for windows of type `eWindowType_dialog`. To limit the scope of this change, I plan to do it only for dialogs with remote content, similar to our current treatment of `eWindowType_popup` (otherwise, presumably some browser-native dialogs may be affected which may not be desirable).