This adds an additional action that is triggered when the fullscreen
transition event is received. That interim action is used to re-focus the
original tab. Without this change, an asynchronous fullscreen transition
will silently swallow the MozAfterPaint event that is necessary to detect
the end of fullscreen.
Before this change, with asynchronous transitions, here's the flow:
1) The test opens Tab 1 which opens Tab 2.
2) Tab 1 enters fullscreen. This transition takes awhile but signals
success early. This is intentional because we want web content to be able
to be fully layed out when the fullscreen transition is complete.
3) Thinking that it has reached fullscreen, the test focuses Tab 2, which
causes a fullscreen exit transition to be queued up but not yet run.
Then Tab 1 is unfocused and a MozAfterPaint message is sent, but nobody is
listening for it so it has no effect. If the fullscreen transition was
synchronous, the actions of Step 6 (below) would happen before the change
in focus and there would be an event listener ready for the MozAfterPaint
event.
4) The test waits for the DOMFullscreenChild to send the
DOMFullscreen:Painted message, which it will do when it receives a
MozAfterPaint event.
5) Enter fullscreen transition completes, exit fullscreen transition
starts.
6) The MozDOMFullscreen:Exited event is sent to the DOMFullscreenChild,
which starts listening for the MozAfterPaint event. This event has
already been sent.
7) Test times out.
This change adds an additional action to take place between steps 6 and 7.
That additional action refocuses Tab 1. This makes it send another
MozAfterPaint event which the DOMFullscreenChild is ready to receive.
Differential Revision: https://phabricator.services.mozilla.com/D180884
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
Just forgetting to map them to new `key_enterFullScreen`. Note that both
`key_enterFullScreen` and `key_exitFullScreen` have same shortcut keys.
Therefore, mapping only to `key_enterFullScreen` must be fine for the
toggle UIs.
This patch does not contain the tests for checking the tooltip label on
the toolbar buttons because the shortcut key information does not appear
in the DOM tree.
Differential Revision: https://phabricator.services.mozilla.com/D179357
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
This test expects that a single call to window.restore() will bring the
window to the "normal" state. This is unfortunately not guaranteed since a
window that is zoomed then minimized will restore to the zoomed state.
This could cause the test to fail if window is zoomed at the start of the
test, because it will return to that zoomed state mid-test.
This change defines a general function to ensure that the window is in the
normal state before proceeding, then calls that at the beginning of the
test and in the middle of the test to ensure we are exercising the
transitions we intended to exercise.
Differential Revision: https://phabricator.services.mozilla.com/D171793
The transition from fullscreen to minimize and back is not directly
allowed in macOS, though our test harness can be forced to request it. The
modified test forces this transition explicitly, so we can eliminate it as
an accidental occurrence with other tests.
The transition from minimize to fullscreen fails on Linux and Windows, so
this change marks the entire test as failing on those platforms. New Bugs
have been opened on this issue and those are noted in the fail-if.
Depends on D166450
Differential Revision: https://phabricator.services.mozilla.com/D164248
The transition from fullscreen to minimize and back is not directly
allowed in macOS, though our test harness can be forced to request it. The
modified test forces this transition explicitly, so we can eliminate it as
an accidental occurrence with other tests.
The transition from minimize to fullscreen fails on Linux and Windows, so
this change marks the entire test as failing on those platforms. New Bugs
have been opened on this issue and those are noted in the fail-if.
Depends on D166450
Differential Revision: https://phabricator.services.mozilla.com/D164248
