So that it shows on top of the fullscreen <browser> element. Note that
the fullscreen toggler and co doesn't need the same treatment, luckily,
because we only use it for the "firefox fullscreen" mode.
Differential Revision: https://phabricator.services.mozilla.com/D233643
Keep using the static position as we did before. As long as we don't
have anchor positioning this seems better than whack-a-mole-ing every
possible urlbar position change.
In order to make the fullscreen animation work, make our position
computation ignore transforms, which is how anchor positioning would
behave anyways.
Differential Revision: https://phabricator.services.mozilla.com/D227758
As far as I can tell nothing really looks at inFullscreen in other
elements that are not the root, not in JS nor in CSS, so this code seems
like it can go?
Differential Revision: https://phabricator.services.mozilla.com/D207123
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
