The html:dialog event can respond to [esc] keypresses itself. In that case,
we need to close the embedded dialog ourselves, or the UI ends up broken.
We also need to make sure that if e.g. the opening multiple pages from bookmarks warning is up,
and then the user tries to quit or in some other way opens another dialog, things don't break.
This also applies to tests that repeatedly invoke dialogs, where we need to wait for both
the SubDialog instance and the wrapping html:dialog element to agree on their state.
Differential Revision: https://phabricator.services.mozilla.com/D107463
With the changes in this patch stack, it will become more common for frontend
code to receive onLocationChange notifications for subframes, as we will now
correctly report events for oop subframes, and will also deliver notifications
for the first document loaded in subframes in order to update the current remote
URI on CanonicalBrowsingContext.
This change makes more of the callbacks fired by onLocationChange be guarded by
the isTopLevel check, including setting the "URL" crash annotation and updating
the macOS touchbar, which should hopefully both fix existing latent bugs, and
ensure that these issues don't occur with the more frequent onLocationChange
callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D105554
The html:dialog event can respond to [esc] keypresses itself. In that case,
we need to close the embedded dialog ourselves, or the UI ends up broken.
Differential Revision: https://phabricator.services.mozilla.com/D107463
This commit uses CSS grid layout to position content modal prompts, and to get the
requisite 5% top and bottom margins in a way that doesn't require JS to update,
and adapts to resizing and things like the find bar and devtools opening. To make
this work right it also removes the 5px negative top margin for these dialogs.
Then this commit adds some logic to SubDialog.jsm to support this behaviour.
Prior to this change, SubDialog.jsm sets height/width on the dialogs that go
through it, except if they pass sizeto=available (used by the print dialog).
This new sizeTo value similarly avoids all the complex sizing logic - but also
avoids the print logic of having an aspect ratio to maintain when the window
changes size. We use the content size it determines to set the height of the
dialog (a grid row): either 90% (so there's 5% above and 5% below) or the
document height, whichever is smaller.
The next commit will use this setup to deal with the problem of variable length
content inside the dialog that we're trying to show.
Differential Revision: https://phabricator.services.mozilla.com/D107110
CLOSED TREE
Backed out changeset 0580aaec32a0 (bug 1693277)
Backed out changeset be8108cd9820 (bug 1693277)
Backed out changeset 8b9986d057d7 (bug 1693277)
This commit uses CSS grid layout to position content modal prompts, and to get the
requisite 5% top and bottom margins in a way that doesn't require JS to update,
and adapts to resizing and things like the find bar and devtools opening. To make
this work right it also removes the 5px negative top margin for these dialogs.
Then this commit adds some logic to SubDialog.jsm to support this behaviour.
Prior to this change, SubDialog.jsm sets height/width on the dialogs that go
through it, except if they pass sizeto=available (used by the print dialog).
This new sizeTo value similarly avoids all the complex sizing logic - but also
avoids the print logic of having an aspect ratio to maintain when the window
changes size. We use the content size it determines to set the height of the
dialog (a grid row): either 90% (so there's 5% above and 5% below) or the
document height, whichever is smaller.
The next commit will use this setup to deal with the problem of variable length
content inside the dialog that we're trying to show.
Differential Revision: https://phabricator.services.mozilla.com/D107110
FillHistoryMenu was returning early and preventing the context menu from opening when there is only one history item. For long-presses, the menu typically doesn't open until after the updateSessionHistory callback was finished so the menu shows properly, but context menus have no delay. However, when browsingContext.sessionHistory is available, we can get the history without callbacks.
Also, combine the two similar session history tests into one more complete test.
Differential Revision: https://phabricator.services.mozilla.com/D106694
Allows to perform the search in a new foreground/background tab or
a new window using modifiers or middle mouse button.
Introduces a certain level of consistency with other entries in
the context menu, like navigation and "view image".
Differential Revision: https://phabricator.services.mozilla.com/D103354
The "Preferences" -> "Settings" changes have been reverted so this can land now. Those string changes will be handled in bug 1694511.
Differential Revision: https://phabricator.services.mozilla.com/D105577
We're not 100% certain if Help is the right spot for this, but we're going
to give it a shot and see. If it turns out it _is_ the right spot, we'll
probably do something a little more self-contained, and less hacky.
I'm leaving the old .properties file just in case we change our mind here.
Yes, we'll want to port to Fluent anyways, but our ultimate choice of where
we put this thing is probably going to dictate where the string lives.
Differential Revision: https://phabricator.services.mozilla.com/D104832
It should also not be displayed for the browser toolbox.
I messed up strings with the initial landing:
- wrong event name used in browser.js (no dynamic update)
- wrong flag passed from BT launcher (stripes show up when BT is used)
Sorry about that
Differential Revision: https://phabricator.services.mozilla.com/D105666
This removes observation of the 'disabled' attribute from the macOS
full screen menu items, because removing the attribute doesn't work
correctly. This is a scenario that, as far as I can tell, didn't
happen elsewhere until now. On other OSes we use a single item which
gets disabled state directly from the command attribute (ie without
an 'observes' child) which appears to work fine.
It also exempts the editing commands from being disabled, but it
appears that at least on macOS, undo history is lost anyway. It's
not clear to me why this is the case, but I don't think it needs
to block an initial landing of this work.
Differential Revision: https://phabricator.services.mozilla.com/D103389
