1958695 - [wayland] Privacy Badger Addon Icon menu on the left side of toolbar sometimes not visible

Status: RESOLVED FIXED

(WebExtensions :: Frontend, defect)

Description

[Maddi]

Attachment: fail.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

Debian Stable with Firefox .deb from Mozilla Repository or Flatpak.
Install the addon Privacy Badger.

Go to customize toolbar. Now drag the Privacy Badger icon to the left side of the menu bar.

Go to the website: https://www.golem.de/ticker/ or ing.de

Actual results:

Now press the Privacy Badger icon and you can see that it is empty.

With Firefox 136.0.4 i could not repoduce this error.

Comment 1

[Maddi]

Attachment: ok.png

Comment 2

[Francesco Lodolo [:flod]]

Could you try running mozregression to help to identify the issue, since you mention it works in 136.0.4?
https://mozilla.github.io/mozregression/quickstart.html

I can't reproduce the issue on Nightly and macOS.

Comment 3

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Toolbars and Customization' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[DeJaVu_CF]

Hello.
Link to the communication on camp-firefox.de
https://www.camp-firefox.de/forum/thema/139189-privacy-badger-2025-3-27-probleme-mit-der-darstellung-der-trackeranzeige/

I was able to reproduce the issue on Ubuntu 24 LTS and on Debian 12, both with Firefox 137. But not on Debian 12 with Firefox DEB 139 Nightly (Mozilla source). and not on windows or Mint for any firefox.
what i also can reproduce that constant clicking on the button that content is flickering for some milliseconds, then gone. i am not fully familiar with the Inspector and browser tools so i was not able to determine if it is firefox, or page content (moz-extension...)
and it happens also for Privacy Badger 2025.3.3, the previous build.
so i assume also a bug in firefox, but only for some builds.

have a nice day.

Comment 5

[DeJaVu_CF]

Attachment: good app_name: firefox build_date: 2025-02-03 20:06:57.517000 build_file: /home/abc/.mozilla/mozregression/persist/8b410273f3e5-shippable--autoland--target.tar.xz build_type: integration build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/

mozregression, for me, Ubuntu 24 LTS
``

Comment 6

[Francesco Lodolo [:flod]]

Sorry, I don't understand this output. You should have a single link to a pushlog at the end of the process.

Comment 7

[DeJaVu_CF]

can you deal with the pushlog links in text or not? you are the expert, i am only user trying to help out.
the order ist good/bad/bad/bad/good. i dont know the order or the time or which one is important. and i prefer to give full/much information as i can.
if you feel upset, then sorry.

Comment 8

[Sören Hentzschel]

From https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8b410273f3e55ab7341ea6375e3d5defbfcb6cae&tochange=9efb94e533503b0cd1309c16d01d488a69941059, only bug 581863 makes sense to me as a potential regressor. :emilio, is it possible that your change caused such a regression?

Comment 9

[Nirmal Advani]

I can't reproduce this bug on Firefox 137 on Pop OS 22.04 LTS.

Comment 10

[Emilio Cobos Álvarez [:emilio]]

(In reply to Sören Hentzschel from comment #8)

From https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8b410273f3e55ab7341ea6375e3d5defbfcb6cae&tochange=9efb94e533503b0cd1309c16d01d488a69941059, only bug 581863 makes sense to me as a potential regressor. :emilio, is it possible that your change caused such a regression?

It is not impossible, in the sense that it is a linux window positioning change, and this is in a popup which is a native window. However, it seems somewhat unlikely since that should've only affected top level windows...

That said, that pushlog doesn't have any other more likely candidate really, so let's roll with it.

I was able to reproduce the issue on Ubuntu 24 LTS and on Debian 12, both with Firefox 137. But not on Debian 12 with Firefox DEB 139 Nightly (Mozilla source). and not on windows or Mint for any firefox.

What DE / compositor? GNOME? If so, Wayland or X11? Could you go to about:support and attach the information here?

Given this doesn't reproduce on 139, would it be possible for someone that can reliably reproduce to run mozregression --bad 137 --find-fix? That'd be able to see what makes it work on 139.

Comment 11

[Maddi]

In my case it's on Gnome Wayland and i cant reproduce it on Firefox Nightly.

Comment 12

[Maddi]

Attachment: raw.txt

Comment 13

[Maddi]

Attachment: text.txt

Comment 14

[Maddi]

Attachment: raw-en.txt

Comment 15

[Maddi]

Attachment: text-en.txt

Comment 16

[Alex Cornestean]

I could not reproduce the issue either, using the latest Privacy Badger v. 2025.3.27, on the latest Nightly (139.0a1/20250407212917), Beta (138.0b4/20250407102644) or Release (137.0/20250327043313) under Windows 11 and Ubuntu 24.04 LTS.

Nor did I reproduce the issue on the latest Release (137.0/20250331133932, Distribution ID canonical-002, from the Ubuntu Store) on Ubuntu 24.04 LTS.

Comment 17

[Maddi]

Attachment: ing.de-ubuntu-24.10.png

Comment 18

[Maddi]

Attachment: golem-ubuntu-24.10.png

Comment 19

[Maddi]

I can reproduce it on the following systems.

Ubuntu 24.10 Snap Firefox 137.0.1 RC
Ubuntu 24.10 Snap Firefox 137 Stable

Debian Stable
Firefox 137 from Mozilla .deb package (packages.mozilla.org...)
Firefox 137 Flatpak

Comment 20

[Nirmal Advani]

Attachment: Disconnect.png

While I was unable to reproduce this on Firefox 137.0 Pop OS 22.04 LTS X11, Disconnect addon only shows a line as seen in the screenshot attached. I just wanted to share this in case it is related to this bug.

Comment 21

[Maddi]

Attachment: Bildschirmaufzeichnung vom 2025-04-21, 08-06-56.webm

Comment 22

[Rob Wu [:robwu]]

Emilio, does the provided information allow you to debug the issue?

Comment 23

[Emilio Cobos Álvarez [:emilio]]

No, disconnect thing in comment 20 seems totally unrelated, and I haven't managed to reproduce this in either gnome or KDE...

Comment 25

[Tomislav Jovanovic :zombie]

Emilio, we got another report, is there anything we could ask reporters to try to diagnose this?

Comment 26

[Emilio Cobos Álvarez [:emilio]]

Hiro, I think you've worked on similar stuff. Any idea?

A log with MOZ_LOG=WidgetPopup:5 of this happening could be useful to see if there's something off.

Comment 27

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1958695 - Deal with popups in Document::UpdateRemoteFrameEffects rather than out of band. r=stransky,#layout,smaug

By code inspection, but I could see this code getting confused with
popup moves like the ones in wayland...

Comment 28

[Emilio Cobos Álvarez [:emilio]]

I think I found something by code inspection...

Let me try to dig a bit more but without reproducing it's quite hard. I'll have a link to builds in a bit, if affected people could try them it'd be good.

Comment 29

[Emilio Cobos Álvarez [:emilio]]

can someone try with a build from https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/THH5N9_cR1KS6WeJz7laRA/runs/0/artifacts/public/build/target.tar.xz and see if it's fixed for them? Thanks.

Comment 30

[Emilio Cobos Álvarez [:emilio]]

Ok I think I can reproduce consistently if I trigger a resize of the <browser> in the popup. Let me debug that when I have some time.

Comment 31

[Emilio Cobos Álvarez [:emilio]]

So on a debug build this repros a lot easier. STR:

• Install Privacy Badger (probably other popups work too).
• Put it at the left of the urlbar, in a way such that the popup would be partially out of the window (this causes us to use the move-to-rect codepath on Wayland).
• Click on the toolbar icon, or make it blank. If that shows a popup, do something like this on the browser console:

document.querySelector("panel browser").style.width = "450px"; // Or anything different from the default width

That triggers another hide/move-to-rect/show cycle and makes it very likely to hit. It is really really likely with D247773 applied.

When it hits, the content process is waiting for paints in here so it doesn't paint itself. But that probably means that the compositor is still paused somehow?

A few other observations:

• We hit an early out on OnExposeEvent() here.
• I still think D247773 is an improvement and we should probably try to get it landed, but it doesn't fix this bug.

Martin, Sotaro, this is more your area of expertise than mine, any chance you could take a look?

Comment 32

[Martin Stránský [:stransky] (ni? me) (PTO till Aug 03)]

Emilio,
can you try with widget.wayland.vsync.enabled set to false?
I think the hide/show sequence postpones the vsync frame callbacks somehow and we use HW vsync / HW acceleration for remote popups.
Thanks.

Comment 33

[Emilio Cobos Álvarez [:emilio]]

I can repro just fine with it set to false. To be clear vsync ticks arrive just fine to the content process, we just bail out because we're still waiting for other paints.

Comment 34

[Emilio Cobos Álvarez [:emilio]]

I'll try to record this with rr.

Comment 35

[Emilio Cobos Álvarez [:emilio]]

pernosco session here.

Comment 36

[Emilio Cobos Álvarez [:emilio]]

So the layer manager is recreated on unmap during the temporary-hidden state. That seems both wasteful and unfortunate?

A patch like this fixes the issue locally:

diff --git a/widget/gtk/nsWindow.cpp b/widget/gtk/nsWindow.cpp
index 5db3494b8eab..aeab577efb2a 100644
--- a/widget/gtk/nsWindow.cpp
+++ b/widget/gtk/nsWindow.cpp
@@ -9857,7 +9857,7 @@ void nsWindow::OnUnmap() {

   // Until Bug 1654938 is fixed we delete layer manager for hidden popups,
   // otherwise it can easily hold 1GB+ memory for long time.
-  if (mWindowType == WindowType::Popup) {
+  if (mWindowType == WindowType::Popup && !mPopupTemporaryHidden) {
     DestroyLayerManager();
   } else {
     // Widget is backed by OpenGL EGLSurface created over wl_surface/XWindow.

But that probably means that there is still a bug somewhere else.

Comment 37

[Emilio Cobos Álvarez [:emilio]]

Ok, so I dug a bit more and I think that's the right fix (at least for now). I took some notes in the pernosco session, but basically:

• Destroying the popup's layer manager ends up also destroying all the child WebRender bridges.
• The WRBridge for the remote content is destroyed with some pending transactions that aren't sent back to the content process.
• But even if they were, the content process will end up being disconnected after all / nothing re-creates the PuppetWidget's renderer.

So I think the code is just not set up to survive a LayerManager destruction while keeping rendering of remote contents working.

Comment 38

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1958695 - Don't destroy layer manager of temporarily hidden Wayland popup. r=stransky

Destroying the popup's layer manager ends up also destroying all the
child WebRender bridges.

The WRBridge for the remote content is destroyed with some pending
transactions that aren't sent back to the content process.

Even if they were, the content process will end up being disconnected
after all / nothing re-creates the PuppetWidget's renderer.

So I think the code is just not set up to survive a LayerManager
destruction while keeping rendering of remote contents working.

There's no good reason to clear these, too, they're likely to be shown
right after.

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/18b9500a0b40
Don't destroy layer manager of temporarily hidden Wayland popup. r=stransky

Comment 40

[Hiroyuki Ikezoe (:hiro)]

When I realized this need-info, It looks like the bug has already been resolve. :)

Comment 41

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/18b9500a0b40

Comment 42

[Phabricator Automation]

Comment on attachment 9485359 [details]
Bug 1958695 - Deal with popups in Document::UpdateRemoteFrameEffects rather than out of band. r=stransky,#layout,smaug

Revision D247773 was moved to bug 1965188. Setting attachment 9485359 [details] to obsolete.