- 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
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
When the user chooses to print using the system dialog, we should hide the print
UI. We are choosing to hide the dialog stack instead of closing the dialog because
the print preview browser still needs to be available if the user tries to print.
We close the window if the user cancels the system dialog or once we receive the
promise from PrintUtils.printWindow.
Differential Revision: https://phabricator.services.mozilla.com/D88096
This also updates the behavior of the allowDuplicates check:
Instead of only checking if the top dialog is a duplicate, it will now check the whole stack and
skip the dialog open if a duplicate URL is found.
This fixes an issue where callers could alternate between dialogs to bypass the check.
Differential Revision: https://phabricator.services.mozilla.com/D88422
This was a pre-existing bug that my patch uncovered it.
Co-Authored-By: Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D88772
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
Do this by spinning the event loop until we've done the clone for
preview as appropriate.
This should be much less risky than finishing the previous patches
which would still be nice, but realistically landing them for 81 is not
going to happen.
This just returns without doing nothing in a couple cases, like when
there's already another modal dialog or such. That seems acceptable to
me, it's not clear what better way to do would be.
Differential Revision: https://phabricator.services.mozilla.com/D87484
We need to exit search mode when a page loads in the current tab. We may need to
exit search mode for page loads in other tabs too: If you're in search mode,
click a slow link, switch tabs, and the page loads in the meantime, then search
mode should be not be entered when you switch back. I don't think we handle that
case correctly right now, and this patch doesn't address that at all. That's
worth doing in another bug because I think the fix will be different.
At first I added an `onLocationChange` method to UrlbarInput that was called by
`XULBrowserWindow.onLocationChange` in browser.js [1], just like we have an
`onLocationChange` in UrlbarProviderSearchTips called by
`XULBrowserWindow.onLocationChange`. But we need to potentially exit search mode
any time `input.setURI` is called. `setURI` happens to be called by
`XULBrowserWindow.onLocationChange`, one of the several places that calls it
[2].
`setURI` is also called when switching tabs. Bug 1647899 already took care of
handling search mode for tab switches, but it would be nice to handle all this
in one place. `setURI` is also how `userTypedValue` is restored in the input,
and of course `userTypedValue` is something we need to restore when switching
tabs, just like search mode. For these reasons I moved per-tab search mode
restoration to `setURI` as part of this.
I'm also changing the name of the second parameter in `setURI`. I wasn't sure
whether it's true iff we're switching tabs, so I tracked down why that param was
added. It was added in bug 1478348, and comment 21 confirms it was added to tell
`setURI` and `XULBrowserWindow.onLocationChange` when they're being called due
to a tab switch. To make this clearer, I renamed the param and added some
javadoc for `XULBrowserWindow.onLocationChange`.
[1] https://searchfox.org/mozilla-central/rev/50cb0892948fb4291b9a6b1b30122100ec7d4ef2/browser/base/content/browser.js#5205
[2] https://searchfox.org/mozilla-central/search?q=symbol:%23setURI&redirect=false
Differential Revision: https://phabricator.services.mozilla.com/D87172
This patch adds the nsIDNSResolverInfo interface which is used to hold
information about the resolver to be used in a DNS resolution.
We use this to merge all of the *WithTRRServer resolve functions into one.
Passing a resolver info will use that object when appropriate. No resolver
info means that we default to using the system resolver, or the default TRR
resolver.
This patch also converts the RESOLVE_TYPE_* flags into a cenum and adds
the resolveType as a parameter to asyncResolve thus removing the need
to have asyncResolveByType methods.
Differential Revision: https://phabricator.services.mozilla.com/D86176
This patch adds the nsIDNSResolverInfo interface which is used to hold
information about the resolver to be used in a DNS resolution.
We use this to merge all of the *WithTRRServer resolve functions into one.
Passing a resolver info will use that object when appropriate. No resolver
info means that we default to using the system resolver, or the default TRR
resolver.
This patch also converts the RESOLVE_TYPE_* flags into a cenum and adds
the resolveType as a parameter to asyncResolve thus removing the need
to have asyncResolveByType methods.
Differential Revision: https://phabricator.services.mozilla.com/D86176
This is the simplest possible way to fix this bug in the interest of landing
ASAP. It keeps a hardcoded list of engines that search the web.
Differential Revision: https://phabricator.services.mozilla.com/D86664
We currently start with screen-relative coordinates, translate them to
widget-relative coordinates, and then translate them back to screen-relative
coordinates when actually showing the tooltip in XULBrowserWindow.showTooltip().
There's no reason for the extra conversions, so we can just send screen-relative
coordinates directly.
Since the widget origin for out-of-process frames is the origin of the frame
itself (instead of the tab, which is the case for in-process frames), the
screen-to-widget conversion was incorrect, and was causing a bug in how the
tooltip was being positioned. Avoiding that conversion altogether also fixes
that bug.
Differential Revision: https://phabricator.services.mozilla.com/D86750
The functionality has been fully subsumed by the new
initialBrowsingContextGroupId attribute, so it is no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D85653
This attribute, when combined with the remoteType attribute, should subsume all
callers of sameProcessAsFrameLoader, and also support selecting the same process
as an out-of-process iframe.
Differential Revision: https://phabricator.services.mozilla.com/D85651
The original issue this patch addresses is what happens when exiting customize
mode: the reinsertion of the urlbar (customize mode wraps it in a container)
causes fluent to re-run as there's a DOM mutation, which causes the default
placeholder to be re-translated. This caused issues because we were using
.properties to translate the string that included the engine name, and
fluent for the "default" placeholder string.
This patch fixes the issue by always using fluent, and using a hardcoded
'unknown' placeholder to deal with the case where there is no known engine.
Differential Revision: https://phabricator.services.mozilla.com/D85769
This moves search-one-offs.js into a jsm without making any substantive changes,
adds a new subclass in UrlbarSearchOneOffs.jsm, and uses `UrlbarSearchOneOffs`
in `UrlbarView` instead of the base `SearchOneOffs` class. `UrlbarSearchOneOffs`
will be fleshed out in part 2.
Differential Revision: https://phabricator.services.mozilla.com/D84784
This moves search-one-offs.js into a jsm without making any substantive changes,
adds a new subclass in UrlbarSearchOneOffs.jsm, and uses `UrlbarSearchOneOffs`
in `UrlbarView` instead of the base `SearchOneOffs` class. `UrlbarSearchOneOffs`
will be fleshed out in part 2.
Differential Revision: https://phabricator.services.mozilla.com/D84784
ts_paint depends on the first MozAfterPaint in the content window, not in the
browser as I had thought. After MozAfterPaint, it pings the parent process and
waits for a response (see `TalosPowers.loadPromise`), and then it ends. It will
wait up to 500ms for the response before timing out. Source:
https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/startup_test/tspaint_test.html
At first I modified UrlbarProviderSearchTips to wait on
`browser-delayed-startup-finished`, but the jsm kept appearing in ts_paint
profiles, and that's how I found out the above. So that's not sufficient.
There's already a promise in browser.js for waiting on the first paint in the
first content window, but it's "private." I added a public getter for it and
changed the name so it's clearer that it's related to the first content window,
not the browser window.
I also added a 500ms timeout just like the worst case in ts_paint.
Both checks (paint and the timeout) are done for a particular browser window
only the first time UrlbarProviderSearchTips sees it.
Finally, UrlbarProviderSearchTips can avoid importing BrowserWindowTracker
during startup by having browser.js pass the window to its `onLocationChange`. I
saw the BrowserWindowTracker.jsm import in some profiles while working on this.
With these changes, UrlbarProviderSearchTips no longer appears in ts_paint
profiles when I run it locally -- except when it is imported by
UrlbarProvidersManager, which ultimately happens due to setting the placeholder
text in the urlbar input. But even that doesn't appear in every profile.
I've also included the reordering of checks from a previous version of this
patch. That's still worth doing in general even if it's no longer relevant to
ts_paint.
Differential Revision: https://phabricator.services.mozilla.com/D80799
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
In Bug 1622749 a user preference for where to open new documents (from a
service worker notification) was temporarily overriden in order to quickly fix
a crash that was happening in mozilla::dom::ClientOpenWindow. The crash was
ocurring when the pref "browser.link.open_newwindow" was set to 2, meaning new
documents are opened in a new window, instead of a new tab. The reason the
browser crashed is because the path for opening a new document is different
depending on the current user setting, and in NEWWINDOW case we did not get a
browsing context returned when calling mozilla::dom::OpenWindow which resulted
in a failed assertion.
The solution is to pass in a callback to mozilla::dom::OpenWindow as part of
nsOpenWindowInfo object, and invoke that callback with a corresponding
BrowsingContext in nsFrameLoader when that browsing context is ready.
After we call mozilla::dom::OpenWindow, we wait on a promise, that will be
resolved when the callback is invoked, before executing the rest of the code
that depends on the browsing context for a newly opened document being
available.
Differential Revision: https://phabricator.services.mozilla.com/D72745
The initialization costs of the TabList constructors is very small compared to
the cost of actually calling _populate, so instead of calling init() from an
idle task, we can just wait until the view actually needs to be shown.
Differential Revision: https://phabricator.services.mozilla.com/D73946
The initialization costs of the TabList constructors is very small compared to
the cost of actually calling _populate, so instead of calling init() from an
idle task, we can just wait until the view actually needs to be shown.
Differential Revision: https://phabricator.services.mozilla.com/D73946
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
Things that were broken:
- prompts become unreadable when using dark-background lwthemes, because they
keep the window text-shadow (due to the namespace change of tabmodalprompt)
- prompts with long text without word-wrap possibilities
(e.g. `alert("x".repeat(1000))`) cause the text to escape its container.
Differential Revision: https://phabricator.services.mozilla.com/D73131
Use the PSL list to evaluate whether user typed strings in urlbar are valid URLs.
Cleanup the URIFixupInfo.fixupChangedProtocol property to be set appropriately.
Auto-correct the most common suffix typos for com, net, org.
Stop using URIFixup to trim urls when the urlbar value is set, instead always trim,
then untrim on focus if the trimmed string would cause, on navigation, a search
instead of a visit. This saves us from doing the URIfixup work on page load and
tab switch, running it only when strictly necessary.
Fix the "Did you mean to go to" prompt to show a protocol, avoiding the
confusing (but funny) "did you mean to go to 'space'" prompts.
Differential Revision: https://phabricator.services.mozilla.com/D68796
This patch updates the prompt code in browser.js and the tabprompts.jsm module
to support the two new prompt types: tab and content
- Updated TabModalPromptBox to support both prompt types
- Updated TabModalPrompt styles for tab prompt type
Differential Revision: https://phabricator.services.mozilla.com/D67134
Before 1496578, URIFixup::keywordToURI used to do a synchronous IPC call to be
able to access search engines from the content process. Consumers of URIFixup
didn't care. Bug 1496578 moved the IPC messaging to the callers, in particular
nsDocShell, but assumed nsDocShellLoadState wasn't loading from content.
It looks like in some cases it does, so this adds another sync IPC call for
GetFixupURIInfo.
The total numer of sync IPCs should not change from before Bug 1496578, URIFIxup
was just doing it internally, while now it happens at the call point.
Note the long term plan would be for these docshell objects callers to just
handle URIs, while the UI code should do fixup.
Bug 1375244 tracks the removal of these sync IPC messages.
Differential Revision: https://phabricator.services.mozilla.com/D70607
--HG--
extra : moz-landing-system : lando
This patch updates the prompt code in browser.js and the tabprompts.jsm module
to support the two new prompt types: tab and content
- Updated TabModalPromptBox to support both prompt types
- Updated TabModalPrompt styles for tab prompt type
Differential Revision: https://phabricator.services.mozilla.com/D67134
--HG--
extra : moz-landing-system : lando
This method is no longer necessary, as frontend will always make the correct
decisions for the remoteness of the intial content browser by reading
openWindowInfo.
Differential Revision: https://phabricator.services.mozilla.com/D67058
--HG--
extra : moz-landing-system : lando
The interface changes which browser.js and tabbrowser.js are being updated for
are performed in earlier parts. This patch just covers the required changes to
frontend code to propagate this information down to the nsFrameLoader when it is
created.
Differential Revision: https://phabricator.services.mozilla.com/D67053
--HG--
extra : moz-landing-system : lando
This API is no longer possible to implement, as it will always try to set the
OriginAttributes on a content BrowsingContext after it has been attached, and JS
can never observe a detached BrowsingContext.
Users of this API are instead changed to perform assertions that
originAttributes have already been set correctly.
Differential Revision: https://phabricator.services.mozilla.com/D67046
--HG--
extra : moz-landing-system : lando
This method is no longer necessary, as frontend will always make the correct
decisions for the remoteness of the intial content browser by reading
openWindowInfo.
Differential Revision: https://phabricator.services.mozilla.com/D67058
--HG--
extra : moz-landing-system : lando
The interface changes which browser.js and tabbrowser.js are being updated for
are performed in earlier parts. This patch just covers the required changes to
frontend code to propagate this information down to the nsFrameLoader when it is
created.
Differential Revision: https://phabricator.services.mozilla.com/D67053
--HG--
extra : moz-landing-system : lando
This API is no longer possible to implement, as it will always try to set the
OriginAttributes on a content BrowsingContext after it has been attached, and JS
can never observe a detached BrowsingContext.
Users of this API are instead changed to perform assertions that
originAttributes have already been set correctly.
Differential Revision: https://phabricator.services.mozilla.com/D67046
--HG--
extra : moz-landing-system : lando
