Open Bug 1695822 Opened 7 months ago Updated 1 day ago

Scrolling popup window content opened by extensions seems to be broken on Linux


(Core :: Graphics: WebRender, defect, P3)




Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- affected
firefox86 --- unaffected
firefox87 --- wontfix
firefox88 --- wontfix
firefox92 --- wontfix
firefox93 --- affected
firefox94 --- affected


(Reporter: hiro, Assigned: botond)


(Blocks 1 open bug, Regression)


(Keywords: correctness, regression)


(4 files)

Attached video recording.webm


  1. Make sure WebRender is enabled.
  2. Install this addon,
  3. Click the popup addon icon at the right edge of the browser toolbar
  4. Choose "Open this tab as a popup"
  5. Scroll the content in the popup

I have totally no idea why bug 1689189 caused this.

Regressed by: 1689189

Does this only happen with software webrender or hardware as well?

Flags: needinfo?(hikezoe.birchill)

yes, I can reproduce this both with software/hardware webrender on Linux.

Flags: needinfo?(hikezoe.birchill)
Severity: -- → S3
OS: Unspecified → Linux
Priority: -- → P3
Summary: Scrolling popup window content opened by extensions seems to be broken → Scrolling popup window content opened by extensions seems to be broken on Linux

Can you attach your about:support? I'm not able to reproduce with WR nor SW-WR, wondering if there is anything interesting in your config.

Flags: needinfo?(hikezoe.birchill)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)

I have totally no idea why bug 1689189 caused this.

This changed who got SW-WR, and that's it, so I'm guessing you must have been using Basic and got put on SW-WR?

Attached file about:support
Flags: needinfo?(hikezoe.birchill)

Did bug 1698067 have any effect here?

See Also: → 1698067

(In reply to Lee Salzman [:lsalzman] from comment #8)

Did bug 1698067 have any effect here?

Linux isn't getting SW-WR popups by default right now. Only Windows gets it for transparent windows. You can get it with set to true but that isn't the case here from the about:support. I wasn't able to reproduce either way.

Blocks: gfx-stalled
No longer blocks: gfx-triage

Debian Testing, Gnome Xwayland
Still reproducible. It can be fixed by resizing the popup a bit and it doesn't occur afterwards anymore.

mozregression --launch 2021-09-13 --pref gfx.webrender.all:true -a
MOZ_X11_EGL=1 mozregression --launch 2021-09-13 --pref gfx.webrender.all:true -a
MOZ_ENABLE_WAYLAND=1 mozregression --launch 2021-09-13 --pref gfx.webrender.all:true -a

mozregression --good 2020-09-13 --bad 2021-09-13 --pref gfx.webrender.all:true -a

10:48.12 INFO: Last good revision: 20ba0abd37d1a4409099fa83f0cc6bf15cfbba92
10:48.12 INFO: First bad revision: 52a4a14e2d32071fe9b15cdfa7d6e400f0d913c5
10:48.12 INFO: Pushlog:

52a4a14e2d32071fe9b15cdfa7d6e400f0d913c5 Kartikaya Gupta — Bug 1667202 - Allow scroll metadata creation even for APZ-disabled scrollframes. r=botond

Basic was unaffected:
mozregression --repo autoland --launch 52a4a14e2d32071fe9b15cdfa7d6e400f0d913c5 --pref gfx.webrender.force-disabled:true -a

OpenGL was unaffected:
mozregression --repo autoland --launch 52a4a14e2d32071fe9b15cdfa7d6e400f0d913c5 --pref gfx.webrender.force-disabled:true layers.acceleration.force-enabled:true -a

Blocks: wr-linux
No longer blocks: gfx-stalled, wr-linux-correctness
Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(botond)
Keywords: correctness
Regressed by: 1667202
No longer regressed by: 1689189
See Also: → 1730856

Thanks, I can reproduce the issue.

I'll do some initial investigation to narrow down where the problem lies.

Assignee: nobody → botond
Flags: needinfo?(botond)

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{ type: "popup" }) (as this extension does) always end up as eWindowType_dialog? I base that on the following:

  • The implementation of adds "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 CHROME_WINDOW_POPUP to be set
    • "dialog" in the feature list causes CHROME_OPENAS_DIALOG to be set
  • Finally, the window type is set based on the chrome flags:
    • it's initialized to eWindowType_dialog if CHROME_OPENAS_DIALOG is set
    • it's changed 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 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).

(In reply to Botond Ballo [:botond] from comment #12)

dialogs with remote content

There are two other WebRender popup bugs on Linux:

Hmm, with these patches, in a Try push I get toolkit/content/tests/chrome/test_popup_button.xhtml or toolkit/content/tests/chrome/test_popup_attribute.xhtml failing in M-1proc (with an OOM crash??) 3/10 times.

Treeherder suggests a known intermittent, bug 1609074, which has been duped over to bug 1607713, but without my patch the failure rate is 0/10.

Not quite sure what to make of that.

(In reply to Darkspirit from comment #15)

There are two other WebRender popup bugs on Linux:

I had a look, these ones look unrelated to APZ, but rather issues on the graphics side.

You need to log in before you can comment on or make changes to this bug.