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
