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
Two fixes:
* The urlbar view isn't a popup anymore, so `FullScreen` should listen for `onViewOpen` and `onViewClose` on the urlbar controller instead of popup events.
* Change the keypress listeners to keydown to listen for enter events in the urlbar and hide the toolbars.
Differential Revision: https://phabricator.services.mozilla.com/D62123
--HG--
extra : moz-landing-system : lando
