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
