This was done erroneously in an earlier code fix that was trying to fix
the showing and hiding of the menubar. It is not necessary to hide the
nav toolbox when the menubar is animated away. The nav toolbox will be
hidden when the user moves the cursor out of the nav toolbox area.
Differential Revision: https://phabricator.services.mozilla.com/D192972
Turns out macOS relies on the background being set in the toolbox rather
than :root because we slide the toolbox down entirely when the menubar
shows up in full-screen.
Since this is also the set up we have for lightweight themes and Linux,
and we can change Windows to do the same now that Aero is not a thing
anymore, clean-up the code and move all the toolbox background code to a
shared place.
In the future if we want to do something like Mica / Aero on Windows
again, we could do this trivially by setting --toolbox-non-lwt-bgcolor:
transparent or so on the relevant platform's file.
I can write a simpler patch for beta if needed.
Differential Revision: https://phabricator.services.mozilla.com/D189055
Prior to this patch, users with the pref `browser.fullscreen.autohide` set
had to hit a 1-pixel tall element to get the tab bar to appear. If they miss
this shallow element, the macOS menubar will animate down, covering the
target, and it won't be possible to make the tab bar to appear until the
menubar is animated away again.
This patch ensures that any time the macOS menubar is animated down, we also
show the tab bar.
Differential Revision: https://phabricator.services.mozilla.com/D187821
Fullscreen/PointerLock warnings are initialized with hidden="true", but
change to hidden="" after being shown and hidden again. I think this
started happening when we began using HTML elements instead of XUL as
they handle hidden attribute differently.
Differential Revision: https://phabricator.services.mozilla.com/D177790
Fullscreen/PointerLock warnings are initialized with hidden="true", but
change to hidden="" after being shown and hidden again. I think this
started happening when we began using HTML elements instead of XUL as
they handle hidden attribute differently.
Differential Revision: https://phabricator.services.mozilla.com/D177790
Chrome for Windows does not dispatch `keydown` event for shortcut keys existing
from the fullscreen mode. Therefore, we can follow it.
For reserving only shortcut keys in fullscreen mode, we need to duplicate XUL
`<key>` elements which define the shortcut keys (only one in Windows/Linux,
but 3 in macOS). Then, their `disabled` attributes should be managed when
toggling the fullscreen mode.
Finally, we need to make `XULKeySetGlobalKeyListener` check the `disabled`
attribute **of** `<key>` elements because it's check in `DispatchXULKeyCommand`
in the final step:
https://searchfox.org/mozilla-central/rev/11a4d97a7b5cdfa133f4bda4525649f651703018/dom/events/KeyEventHandler.cpp#315-316
and it stops handling everything with doing nothing. I'm not sure whether this
was intentionally implemented or just a inefficient code which we didn't take
care the performance. However, I think that ignoring the disabled `<key>`
elements is reasonable behavior from `<key>` element users point of view.
(I found only one `<key>` which is disabled by default:
https://searchfox.org/mozilla-central/rev/11a4d97a7b5cdfa133f4bda4525649f651703018/browser/base/content/browser-sets.inc#225-233)
Differential Revision: https://phabricator.services.mozilla.com/D178262
Baseline profile: https://share.firefox.dev/3p5PgDn (jank)
Profile with just setting pinned tab position to absolute: https://share.firefox.dev/30jKR5p (jank)
Profile with just moving relative positioning to CSS: https://share.firefox.dev/3p6c5a7 (jank)
Profile with this patch: https://share.firefox.dev/3FRLmnK (no jank)
Markus said setting abspos pinned tabs would be safe as long as there were no relative-positioned ancestors in the tab overflow scrollbox. The only notable ancestor of a pinned tab is the tab arrowscrollbox itself, so there aren't any surprise ancestors here. Manual testing indicates things work fine.
I also confirmed that this patch fixes bug 1725151.
Differential Revision: https://phabricator.services.mozilla.com/D121403
I've tested this (both with and without titlebar) in Linux, Win10,
Win11, Win7 and macOS.
* On macOS behavior doesn't change at all (since on fullscreen we didn't
show the buttons to begin with).
* Linux now shows "native" buttons on fullscreen (which is also an
improvement).
* On Windows 10/11 the sizing of the buttons is now the same when
fullscreen vs. not (which is an improvement).
* On Windows 7 we now use regular native-looking buttons (like on
windows 10) instead of the custom windowControls.png. That could be
considered a slight regression I guess, but is consistent with win10.
Differential Revision: https://phabricator.services.mozilla.com/D128196
