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
Most usage is a straight replacement but gtk needs extra changes as it transfers plain text in UTF8 natively and needs to be converted into UTF16, and Windows uses single-byte characters for RTF and CF_HTML formats so we preserve this.
Differential Revision: https://phabricator.services.mozilla.com/D158587
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
Trivial-ish backout (with a change from click() to doCommand(), which
also works around the issue described in the original commit).
MANUAL PUSH: Test-only to keep the tree green CLOSED TREE
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
Use asynchronous methods to retrieve or generate page thumbnails. Also
add explicit handling for unloaded browsers without stored page
thumbnails. In that case, give the preview frame a fallback style
instead of showing a broken img or an empty black canvas.
Differential Revision: https://phabricator.services.mozilla.com/D159672
These don't work on emulated flexbox. We only have a couple of uses.
See D159726 for the diagnostic patch I used to catch these.
Differential Revision: https://phabricator.services.mozilla.com/D159727
