Depends on D114970
With this change, the title text of the robot icon now reads "Browser is under remote control by { $component }"
With component being one of DevTools, Marionette or RemoteAgent.
Note that if several components are listening at the same time, only the first one we checked is displayed.
Having several remote control tools running at the same time is considered as an edge case here.
The main goal of the feature is to help users identify what triggered remote control in case they are confused by the icon showing up.
Differential Revision: https://phabricator.services.mozilla.com/D115195
Luminance goes from 0 to 255, so using 127 makes sense, and allows all
disabled titlebar colors that I found in various GTK themes to still be
considered dark enough (for those, 110 was too low).
Differential Revision: https://phabricator.services.mozilla.com/D114876
I noticed while testing the previous patch on various gtk themes that
the cache wasn't cleared / sytem colors weren't recomputed properly when
the native theme changes. This trivial patch fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D114879
Mixing the XUL and CSS box models is always a source of interesting glitches like
the one that this patch tries to fix. The animation for closing a Proton-y infobar
involves setting a negative margin on an element using CSS box, which has a parent
and siblings that are using XUL box.
Interestingly, it seems that only the high priority notification box hits this issue,
as the per-tab notification box is contained within a <named-deck>, which uses CSS
box - this observation was what led me to the solution in this patch: when constructing
the high priority notification box, we now place it inside of a <div>, which uses
CSS box, which allows us to sidestep this glitch.
The irony of fixing this CSS vs XUL box glitch by adding another CSS box amongst a
bunch of XUL boxes is not lost on me.
Differential Revision: https://phabricator.services.mozilla.com/D114552
There are a few disparate changes in this commit that combine to fix the bug.
In no particular order:
- set a min-height on windows with toolbars. This extends the minimum
content size from toolbarless windows to ones with toolbars, on the
assumption that the overhead from the toolbar and tabs is always
going to be at least 25px, even in compact mode (it's significantly
more at the moment). This is also conveniently *just* enough for
dialogs with a title, body and checkbox, at the default OS font size,
to be usable (though the bottom can still get a little cut-off).
- stop assuming there's 30px frame overhead on top of the size of the
browser in which the dialog is displayed in SubDialog.jsm. This is
perhaps true in prefs where we display a titlebar outside of the
browser, but we don't do this for content/tab/window-modal dialogs
shown in browser.xhtml so the code shouldn't assume. Without this,
when the window starts off not being tall enough to fit, we were
losing an additional 30px for no reason.
- instead of subtracting the 1em padding on the <dialog> that the
default styling provides (https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/layout/style/res/html.css#815 ) just reset it to 0 and stop subtracting it.
- remove the CSS rule for tab and window-modal dialogs that depends on
`--doc-height-px`. It is never set, because it is only set for the
`limitheight` sizeto value in SubDialog.jsm, and the only
consumer that sets that is at
https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/browser/base/content/browser.js#8988
for content dialogs.
- set the margin-top for the window-modal-dialog element from CSS
instead of from the gDialogBox code in browser.css (now without the 1em
subtraction, see above).
- expose the height of the dialog to the parent of the dialog overlay
from SubDialog.jsm as --inner-height
- use CSS to ensure the dialog is off-set to be just below chrome
when its size allows this, and otherwise move it up until it
fits. There's a code comment explaining this.
Differential Revision: https://phabricator.services.mozilla.com/D114292
There are a few disparate changes in this commit that combine to fix the bug.
In no particular order:
- set a min-height on windows with toolbars. This extends the minimum
content size from toolbarless windows to ones with toolbars, on the
assumption that the overhead from the toolbar and tabs is always
going to be at least 25px, even in compact mode (it's significantly
more at the moment). This is also conveniently *just* enough for
dialogs with a title, body and checkbox, at the default OS font size,
to be usable (though the bottom can still get a little cut-off).
- stop assuming there's 30px frame overhead on top of the size of the
browser in which the dialog is displayed in SubDialog.jsm. This is
perhaps true in prefs where we display a titlebar outside of the
browser, but we don't do this for content/tab/window-modal dialogs
shown in browser.xhtml so the code shouldn't assume. Without this,
when the window starts off not being tall enough to fit, we were
losing an additional 30px for no reason.
- instead of subtracting the 1em padding on the <dialog> that the
default styling provides (https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/layout/style/res/html.css#815 ) just reset it to 0 and stop subtracting it.
- remove the CSS rule for tab and window-modal dialogs that depends on
`--doc-height-px`. It is never set, because it is only set for the
`limitheight` sizeto value in SubDialog.jsm, and the only
consumer that sets that is at
https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/browser/base/content/browser.js#8988
for content dialogs.
- set the margin-top for the window-modal-dialog element from CSS
instead of from the gDialogBox code in browser.css (now without the 1em
subtraction, see above).
- expose the height of the dialog to the parent of the dialog overlay
from SubDialog.jsm as --inner-height
- use CSS to ensure the dialog is off-set to be just below chrome
when its size allows this, and otherwise move it up until it
fits. There's a code comment explaining this.
Differential Revision: https://phabricator.services.mozilla.com/D114292
Now that I finally wrote a test, I also noticed that we were trying to write the
checkbox permission value when the dialog gets aborted (ie removed because the
page disappears due to another page loading or the tab/window being closed),
which then threw an exception because the event target is the window rather than
the dialog element, and dialog.querySelector in maybeSetAllowTabSwitchPermission
fails.
Differential Revision: https://phabricator.services.mozilla.com/D114023
It turns out the shadow document doesn't need its own FTL imports, the parent can
include them instead. This moves the requirement back onto the caller to ensure
that any FTL files it needs are already imported when creating a notification-message.
Depends on D111189
Differential Revision: https://phabricator.services.mozilla.com/D111190
This also fixes links in top or in-process subframes and out-of-process subframes in extensions sidebars and panels so that they open in new tabs.
Differential Revision: https://phabricator.services.mozilla.com/D110102
Fairly self-explanatory. This just extends the tab-based modal popup hiding
behavior to modals going through gDialogBox.
Differential Revision: https://phabricator.services.mozilla.com/D109527
This effectively mirrors the panel hiding logic we use to hide
PopupNotifications panels so that we also hide notifications attached to the
hamburger menu. This will cover alerts and other similar modals originating
from content.
Differential Revision: https://phabricator.services.mozilla.com/D109526
This ensures the modal is visible. I'm deliberately not doing this for content or tab-modal
prompts, where there wasn't a history of doing this and where I think it would open up
dos-style annoyance vectors.
Differential Revision: https://phabricator.services.mozilla.com/D109058
Due to some kind of weirdness, you can end up with a weakly held preference
callback being run even after the DOM objects it holds references to are unlinked
by the cycle collector, which can cause crashes. This patch works around
that by taking advantage of the fact that we now drop weak references to DOM
objects when they are unlinked to change the preference callback closure to
instead hold a weak reference.
Differential Revision: https://phabricator.services.mozilla.com/D109031
The widget is only added if screenshots are enabled (similar behavior to the fxa
toolbar button).
Button must take into account onLocationChange due to the fact that screenshots
extension is not available on about pages.
Adds a test for the disabled state, with more screenshot tests intended in the future
Differential Revision: https://phabricator.services.mozilla.com/D107727
The preference shouldn't affect WebExtensions as it is non-obvious (WebExtensions might not be using a context menu so a user wouldn't expect that preference to affect them), and WebExtensions can choose themselves if a tab needs to be in the background or not.
This also removes it from the command line search flow where it had no effect anyway.
Differential Revision: https://phabricator.services.mozilla.com/D107870
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
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
- Added a new permission panel managed by the gPermissionPanel object
- Updated identity-box to separate identity and permission section
Differential Revision: https://phabricator.services.mozilla.com/D99892
We disabled Backspace as a keyboard shortcut to go back one page (bug 1041377). We can use the Back and Forward buttons' tooltips to advertise the other shortcuts users can use instead of Backspace (like we do on the Reload button's tooltip).
Differential Revision: https://phabricator.services.mozilla.com/D102053
This revision introduces helpers for determining whether or not dialogs opened with TabDialogBox show the checkbox for allowing focus (tab switching). The approach for showing the checkbox follows the pattern similar to how its handled for TabModalPromptBox:
First, when a prompt is opened, the "DOMWillOpenModalDialog" event is fired from `PromptParent.jsm` on the browser tab. The browser then determines if the tab the event is dispatched on is the current selected tab. If the dialog was opened from another tab, then we check if the content prompt principal permission "focus-tab-by-prompt" is allowed for the URI the dialog was opened for and store its prompt principal on the tab prompt's `_onNextPromptShowAllowFocusCheckboxFor` property. This presence for this value is ultimately what determines whether or not the checkbox is shown. Everything after that, the prompt's UI component is responsible for handling the checkbox's state and setting a handler for setting the permission when it's checked.
Implementing this for TabDialogBox makes it so we also store the prompt principal on the dialog box. We then process this value and send some information (such as explicitly setting a `checkLabel` value) via the `args` object for common dialog to process. And finally, we set the "focus-tab-by-prompt" permission for that URI via a closing callback for the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D102076
We disabled Backspace as a keyboard shortcut to go back one page (bug 1041377). We can use the Back and Forward buttons' tooltips to advertise the other shortcuts users can use instead of Backspace (like we do on the Reload button's tooltip).
Differential Revision: https://phabricator.services.mozilla.com/D102053
- Added a new permission panel managed by the gPermissionPanel object
- Updated identity-box to separate identity and permission section
Differential Revision: https://phabricator.services.mozilla.com/D99892
- Added a new permission panel managed by the gPermissionPanel object
- Updated identity-box to separate identity and permission section
Differential Revision: https://phabricator.services.mozilla.com/D99892
This revision introduces helpers for determining whether or not dialogs opened with TabDialogBox show the checkbox for allowing focus (tab switching). The approach for showing the checkbox follows the pattern similar to how its handled for TabModalPromptBox:
First, when a prompt is opened, the "DOMWillOpenModalDialog" event is fired from `PromptParent.jsm` on the browser tab. The browser then determines if the tab the event is dispatched on is the current selected tab. If the dialog was opened from another tab, then we check if the content prompt principal permission "focus-tab-by-prompt" is allowed for the URI the dialog was opened for and store its prompt principal on the tab prompt's `_onNextPromptShowAllowFocusCheckboxFor` property. This presence for this value is ultimately what determines whether or not the checkbox is shown. Everything after that, the prompt's UI component is responsible for handling the checkbox's state and setting a handler for setting the permission when it's checked.
Implementing this for TabDialogBox makes it so we also store the prompt principal on the dialog box. We then process this value and send some information (such as explicitly setting a `checkLabel` value) via the `args` object for common dialog to process. And finally, we set the "focus-tab-by-prompt" permission for that URI via a closing callback for the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D102076
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
The TabDialogBox will manage two separate SubDialog managers at the tab and content level. Dialogs managed at the tab level will always be on top of content ones and should always receive focus first when tab switching or refocusing the window.
Differential Revision: https://phabricator.services.mozilla.com/D100066
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
The TabDialogBox will manage two separate SubDialog managers at the tab and content level. Dialogs managed at the tab level will always be on top of content ones and should always receive focus first when tab switching or refocusing the window.
Differential Revision: https://phabricator.services.mozilla.com/D100066
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
The TabDialogBox will manage two separate SubDialog managers at the tab and content level. Dialogs managed at the tab level will always be on top of content ones and should always receive focus first when tab switching or refocusing the window.
Differential Revision: https://phabricator.services.mozilla.com/D100066
This patch makes the contentAreaUtils.saveURL to be aware of the
cookieJarSettings, and updates all callers.
This also updates the documentation of the persistArgs
'cookieJarSettings' for internalPersist().
Differential Revision: https://phabricator.services.mozilla.com/D98455
This formed the backbone of the previous process switching codepath, and
shouldn't be necessary anymore thanks to DocumentChannel's new codepath.
This also removes the eager process switching logic from frontend's _loadURI, as
it would rarely be taken, unless an invalid URI was entered, already.
Differential Revision: https://phabricator.services.mozilla.com/D94639
These methods are no longer necessary, as all loads which can trigger process
switches now go through DocumentChannel.
The shouldLoadURI methods on nsIWebBrowserChrome3 are unfortunately still
necessary as they're used by the disabled-by-default "Single-Site Browser"
feature. In the future this may be possible to clean-up.
Differential Revision: https://phabricator.services.mozilla.com/D94638
This patch makes the BrowserReloadWithFlags() to cache the content
principal before the remoteness changes. And use this cached principal
as the triggering principal for reloading.
We need to do this because the content principal in a browser will be
cleared during changing the remoteness. The browser will be destoried
and then constructed, and the content principal will be cleared. So, we
need to cache the content principal before in order to use the correct
principal.
Differential Revision: https://phabricator.services.mozilla.com/D96408
This formed the backbone of the previous process switching codepath, and
shouldn't be necessary anymore thanks to DocumentChannel's new codepath.
This also removes the eager process switching logic from frontend's _loadURI, as
it would rarely be taken, unless an invalid URI was entered, already.
Differential Revision: https://phabricator.services.mozilla.com/D94639
These methods are no longer necessary, as all loads which can trigger process
switches now go through DocumentChannel.
The shouldLoadURI methods on nsIWebBrowserChrome3 are unfortunately still
necessary as they're used by the disabled-by-default "Single-Site Browser"
feature. In the future this may be possible to clean-up.
Differential Revision: https://phabricator.services.mozilla.com/D94638
This adds the ability to force the bookmarks toolbar to appear on all pages. The checkbox in the toolbar context menu will reflect if the toolbar will appear outside of the newtab page. The toolbar will always appear on the newtab page. Profiles that already had the toolbar showing will have a migration to keep their experience unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D89222
This adds the ability to force the bookmarks toolbar to appear on all pages. The checkbox in the toolbar context menu will reflect if the toolbar will appear outside of the newtab page. The toolbar will always appear on the newtab page. Profiles that already had the toolbar showing will have a migration to keep their experience unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D89222
This adds the ability to force the bookmarks toolbar to appear on all pages. The checkbox in the toolbar context menu will reflect if the toolbar will appear outside of the newtab page. The toolbar will always appear on the newtab page. Profiles that already had the toolbar showing will have a migration to keep their experience unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D89222
By not re-using the "remote-listening" observer topic in Marionette
allows us to send different data through the observer notification.
This also prevents a crash in the Remote Agent component, which
expects a string, and not a boolean value to receive in data.
Differential Revision: https://phabricator.services.mozilla.com/D93513
* Always update the `_searchModesByBrowser` map when entering/exiting search
mode, not only for non-selected browsers, so that search mode can be saved and
restored properly per tab.
* Rename `setSearchMode` to `_updateSearchModeUI` and make it only update the UI.
* Add a new `setSearchMode` method that takes a browser and updates the map.
* Add `getSearchMode` so that SessionStore can get the search mode for a given
browser.
* Add a `searchMode` getter and setter for convenience. They call
`getSearchMode` and `setSearchMode` with the selected browser.
Differential Revision: https://phabricator.services.mozilla.com/D91910
In order to avoid over/under-counting, we need to treat window.print()
specially. The new UI was using aOpenWindowInfo.isForPrintPreview for
that, but that doesn't quite work for the old UI (because it will
trigger a regular print, not a preview).
But since isForPrintPreview was only really needed to distinguish
window.print(), just rename it and set it to true when the old UI is
triggered by window.print() as well.
Differential Revision: https://phabricator.services.mozilla.com/D92925
This allows to use the feature from the context menu and is very
straight-forward.
This has the benefit of working with fission (as print from the focused
frame) and so on.
Making a checkbox on the UI on top of this is doable, but it is a lot
more complex (requires a bunch of both front-end and platform work)
because undoing this implies restoring the DOM which "print selection"
removes.
I think the context menu entry is very useful regardless of whether we
add a checkbox to undo it, and other browsers (with smaller context
menus) seem to agree.
Differential Revision: https://phabricator.services.mozilla.com/D92205
The WebAuthn popup just used the current selected browser for its context,
while we actually want to stick with the window that brought us to the party.
This adds tests to ensure that the doorhanger stays on the tab it was originally
attached to, avoiding the 'wandering doorhanger' problem from the bug.
Differential Revision: https://phabricator.services.mozilla.com/D72255
