Affected versions

• 89.0a1(20210414093129)

Affected platforms

• Windows 10x64

Steps to reproduce

1. Open Firefox and add Bookmarks Menu and Save to Pocket to Overflow menu.
2. Click the Bookmarks Menu and then Back Arrow.
3. Click The Save to Pocket button and back arrow.
4. Click again the Bookmarks Menu button.

Expected result

• Bookmarks menu is opened.

Actual result

• Nothing happens. Browser console errors: link

Regression range

• Last good revision: aa432f04a7da3f25eea116cd5548bc9c8554f18c (2021-04-13)
  First bad revision: 14541ee6ce5e7c9f273e83c0ad3b2ba1c46b02c5 (2021-04-14)
  1:30.55 INFO: Pushlog:
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=aa432f04a7da3f25eea116cd5548bc9c8554f18c&tochange=14541ee6ce5e7c9f273e83c0ad3b2ba1c46b02c5
  Bisecting further mozregression points at bug 1704927 but I’m not sure due to interminency so I’ve attached the complete pushlog.

Notes

• Attached a screen recording.
• It seems that I cannot reproduce this with browser.proton.enabled:false. Tried multiple times and the issue is not reproducing.
• I cannot reproduce the issue on Ubuntu 20 and macOS 10.15.
• This is intermittent and may require a few tries.

I see that the context menu is also affected if Unpin from overflow menu is activated while the sync is in progress. STR:

1. Log in to sync and add Fxa icon to the overflow menu.
2. Enter Fxa from the overflow menu and click on Sync.
3. Click on Unpin from the overflow menu while the sync is in progress.

Bisecting these steps gives the same regression range. I don't know if should I file a separate bug on this as well.

Gijs, do you have any idea what would cause the browser console errors shown?

The regression range points at this being a graphics bug, but I don't see how graphics backend changes can cause frontend exceptions to be thrown (unless we're just exposing timing issues).

(In reply to Matt Woodrow (:mattwoodrow) from comment #2)

Gijs, do you have any idea what would cause the browser console errors shown?

The regression range points at this being a graphics bug, but I don't see how graphics backend changes can cause frontend exceptions to be thrown (unless we're just exposing timing issues).

The error is from https://searchfox.org/mozilla-central/rev/d280cc26237b62096b89317e4ed6dea8b2bdf822/browser/components/customizableui/PanelMultiView.jsm#680 which means that when clicking the bookmarks menu / pocket item, we don't think the panel is showing any view, so we can't show a subview (because for that to happen, there must be a parent view to slide out to the left). So somehow the internal state has gotten messed up. It looks like the only place we remove items is from _closeLatestView, so that is being called too much - but hard to know exactly how/why without taking a debugger out (and that's assuming I can reproduce).

I would expect the issue to go away if you close and reopen the panel in which the problem occurs.

In terms of timing and interaction with graphics/layout, the code relies on transitionend and transitioncancel events, so if the graphics change could have caused changes in how/when those are dispatched, it's quite possible that this causes issues here. I will keep the needinfo and hope I can look at this more later today or tomorrow, but if this gives you ideas about what might be going wrong that would be helpful.

OK, investigating this by reproducing with only the bookmarks menu item on Windows, it seems that the reason for the errors is that the click events aren't getting dispatched until after the user gives up and closes the panel (at which point the panel code correctly goes "well, I'm invisible, this makes no sense"). This is very disorientating because there is visual hover/active feedback for the clicks on the item, but none of the JS event code is being hit (based on adding logging to said JS code).

From a conversation with Emilio, this points to issues with APZ and event dispatching, which also makes some amount of sense of the web render relation? So passing needinfo back to folks who might know about that.

Unsure if it's a red herring, but we set overflow: hidden or similar on the subviews that we slide between during the animation, to avoid scrollbars appearing and then disappearing when the height of the panel changes - perhaps that's related?

(For the pocket case, which I didn't initially test, when things break we do seem to get the click event for the item, but the ViewShowing event is not dispatched until after the view closes again, which is why it is empty and doesn't show any content)

Though I will dig into today, probably this is not related to APZ since we don't enable APZ in popups which do not have remote browsers. The menu doesn't look like it has a remote browser.

It's possible that the combination of WR + no APZ has not been exercised very much so far and has some bugs which no-WR/no-APZ and WR/APZ do not have. To test this theory, it would be interesting to see if enabling APZ in this popup (even though it's not remote) fixes the bug.

For more direct debugging of the issue, a place to start might be to turn on MOZ_LOG=event.retarget:5, and see if there's anything fishy / different about the event targets in the case where the click is ignored vs. the case where the click goes through. (I did briefly attempt to try this, but I'm not sure how to get such logs on Windows outside of a local build environment, which I don't have right now.)

I can easily reproduce this on Windows 10 in Nightly 90 with:

1. webrender enabled
2. gfx.webrender.software.unaccelerated-widget.allow=true/false

I can't reproduce this with:

1. webrender + swiggle enabled
2. webrender disabled

STR

1. Place the library button at the top of the overflow menu via customize, along with a few other buttons
2. click on that to expand
3. click on the library panel back arrow

Every single time the back arrow doesn't respond to clicks.

No browser console errors here when the problem reproduces. Also confirmed with both swiggle popup settings and fission disabled. Still see it.

I can't reproduce this in a clean profile for the same build. Maybe this has something to do with the amount of crap I have in my Library sub folders?

Doesn't appear to be related to graphics though.

I found a work around. I have a rather large collection of items in my bookmarks toolbar. The '<' button happens to land such that about 95% of it sits on top of that. If I click on the lower 5% below the bookmarks toolbar, the button works.

Also, when moving the mouse up across the button, when I cross the threshold of the toolbar, the button flickers slightly.

Confirmed when I disable webrender, the problem goes away. So this is some sort of hit testing issue I think.

Ok, I was unable to reproduce this in a clean profile, so I loaded up with similar content. Finally figured out what was causing this -

webrender enabled
and
gfx.webrender.unaccelerated-widget.force=true

which enabled accelerated webrender rendering for popups.

Hey Alexandru, could QA confirm this issue for us? We're having a hard time reproducing in a default configuration.

STR:

1. Insure you're testing in an environment that gets WebRender via about:support (Exclude WebRender Software variants)
2. Insure the following prefs are defaulting to the right values -
   gfx.webrender.unaccelerated-widget.force=false
   gfx.webrender.software.unaccelerated-widget.allow=false
3. Enable the bookmarks toolbar when testing
4. Test the responsiveness of overflow dropdown related buttons that sit on top of Bookmarks toolbar.

Thanks!

STR(original Bug1703569):

1. Make sure Compositing is WebRender via about:support
2. (optionally)
   gfx.webrender.unaccelerated-widget.force=false (default in Nightly)
   gfx.webrender.software.unaccelerated-widget.allow=false (the problem occurs regardless of this setting)
3. Put Text Encoding toolbutton in Overflow Menu.
4. Restart
5. Open data:text/html;Shift_JIS,Other than UTF-8:%E3%81%82<a href="https://www.google.com" style="float:right;padding-right:50px;">Go to Google</a>
6. Click >> Overflow Menu button.
7. Click Text Encoding to open sub-panel
8. Click < button at the top-left corner of the panel
9. Repeat(5-10 times) step 7 & 8

Actual results:
The panel hangs up. No longer open the panel.

Thanks Alice. Unfortunately I'm only able to reproduce if gfx.webrender.unaccelerated-widget.force=true with your test case. Presumably we have an underlying issue here that is intermittent that I'm just not able to trigger.

(In reply to Jim Mathies [:jimm] from comment #16)

Hey Alexandru, could QA confirm this issue for us? We're having a hard time reproducing in a default configuration.

STR:

1. Insure you're testing in an environment that gets WebRender via about:support (Exclude WebRender Software variants)
2. Insure the following prefs are defaulting to the right values -
   gfx.webrender.unaccelerated-widget.force=false
   gfx.webrender.software.unaccelerated-widget.allow=false
3. Enable the bookmarks toolbar when testing
4. Test the responsiveness of overflow dropdown related buttons that sit on top of Bookmarks toolbar.

Thanks!

Hello Jim! Just wanted to confirm that what I'm testing is correct: after step 3 you are referring that the buttons should be added on the toolbar or inside the Overflow menu? And those buttons are: Save to pocket, Library, Text Encoding, Show your bookmarks, Forget and Downloads? Also in about:support Compositing field shoud have Webrender right? Thank you!

Confirming that I can no longer reproduce the issue using Firefox 90.0a1 (20210511213906) on Windows 10x64. Tried multiple times str from comment 0 and comment 1. Also tried str from comment 8 and 18 as well.