Closed Bug 1631229 Opened 4 months ago Closed 3 months ago

While in full screen, hovering any toolbar item (except for the tab strip's) to a point that its tooltip will appear and then moving the mouse over to a different toolbar item will hide the toolbars

Categories

(Firefox :: Toolbars and Customization, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 77
Tracking Status
firefox-esr68 --- unaffected
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- verified

People

(Reporter: itiel_yn8, Assigned: Gijs)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

STR:

  1. Windows 10, latest Nightly
  2. Press F11 to toggle full screen
  3. Hover any toolbar item (except for the tab strip's) and wait for its tooltip to appear
  4. Move your mouse to a different toolbar item, without leaving the toolbars area

AR:
The entire toolbar hides.

ER:
The toolbar should remain visible.

Note that quickly moving the mouse from a toolbar item to another without waiting long enough for the tooltip to appear will not cause this issue.

Not sure if this is a feature though, but this feels wrong. As long as my mouse is on the toolbar area, I don't think the toolbar should hide itself.

Wow. I did not know what I was getting myself into when filing this bug...

I'll start off by saying that bug 1621634 is related here.
If you click (when in full screen) on a window control button (can probably be any button on the toolbars, not sure) after its tooltip appeared, the click will be ignored and the toolbar will autohide itself.

But that's nothing...
While testing for a regression range (which is [1], meaning that bug 1492582 is probably the regressor), I attempted to move my mouse away from the Restore button right after I clicked it (at this point, the toolbar was autohiding itself), and Firefox froze.
The problem is, the ENTIRE WINDOWS froze. Only the mouse was working.
So Ctrl+Shift+Esc, Ctrl+Alt+Del (multiple times), Alt+Tab, Win+Tab -- NOTHING worked. I waited a few minutes and still nothing. I had to force reboot my machine.

As I thought it was a temporary glitch, I did the same thing on latest Nightly. And I managed to reproduce it for 3 times in a row.
One of the times this happened the mouse was extremely lagging, with the speakers beeping on every mouse move (the PC specs are i7-6700 with 16GB RAM, Samsung SSD 860 Pro btw).
Needless to say this never happened to me on this machine, even with high load.

At this point I'm afraid to even attempt to reproduce this again...

[1] https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a79182facdfb66acc72c0be720c8543978d2af5d&tochange=d967ac6c56aeec99c2fba3814c8550a1c5971384

Has Regression Range: --- → yes
Has STR: --- → yes
Keywords: regression
Regressed by: 1492582

Hmm, apologies for the tone of comment 1 above, I was just too excited of my findings and results :-)

Duplicate of this bug: 1621634

The problem is that here:

https://searchfox.org/mozilla-central/rev/d2cec90777d573585f8477d5170892e5dcdfb0ab/browser/base/content/browser-fullScreenAndPointerLock.js#600-604,608-610

The event target is no longer the popup, but the document. event.originalTarget still works. So we're meant to ignore popuphidden events from tooltips, but we don't.

While that makes it relatively easy to fix this, I'm concerned (a) what other things might be broken by this change - other popuphidden or popupshown event listeners, in other words - and/or what other events (are all document event listeners "broken" in this way?) and why this changed as a result of the switch to an HTML doc.

:bdahl, do you know the answers to some of these questions?

Flags: needinfo?(bdahl)

In documents with root XUL elements, tooltip listeners are handled by each XUL element. In docs with root HTML elements, a single tooltip listener is created for the whole document.

A quick search didn't turn up any other broken event listeners. There are some tests at https://searchfox.org/mozilla-central/rev/3446310d6cc5c85cde16a82eccf560e9b71a3d44/toolkit/content/tests/widgets/popup_shared.js#193

FWIW, I was hoping we'd eventually be rid of all XUL root elements and have one behavior, but that hasn't happened yet.

Flags: needinfo?(bdahl)

Regression in a recent release. Fix looks to be simple/low-risk. It would be OK to uplift this to 76 but it's pretty low severity (outside of the lockup seen on the window controls). Gijs has said that he can attach a patch.

Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Priority: -- → P1
Attachment #9143233 - Attachment description: Bug 1631229 - make popup hiding exiting fullscreen work correctly for tooltips and nopreventnavboxhide, r?dao → Bug 1631229 - make popup hiding exiting fullscreen work correctly for tooltips, r?dao
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/f53992d7dd1b
make popup hiding exiting fullscreen work correctly for tooltips, r=dao
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 77

Fixed on latest Nightly.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.