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
Only 3 callers are using a non-UTF-8 charset as the first parameter.
* MediaDocument.cpp: This does not make sense because the "filename" part of
URLs will always be encoded with UTF-8.
* nsContextMenu.js: This is wrong because "mailto:" URLs don't care about the
document charset.
* Finder.jsm: This caused bug 1623222.
Differential Revision: https://phabricator.services.mozilla.com/D67386
--HG--
extra : moz-landing-system : lando
* Track and clear a timerID for the ConfirmationHint to avoid callbacks from one show() call interfering with a subsequent call.
* Tighten up waiting for and verifying the confirmation hint in browser_doorhanger_generated_password.js
* Pass in the correct browser when retrieving the anchorNode for the confirmation hint.
Differential Revision: https://phabricator.services.mozilla.com/D67398
--HG--
extra : moz-landing-system : lando
This patch does the following:
* Moves most logic for initiating about:home / about:newtab into AboutNewTab.jsm
* Makes AboutNewTab the API surface for overriding the default about:newtab URLs.
* Reduces the surface of nsIAboutNewTabService, and makes the properties read-only
* Splits the remaining code in the nsIAboutNewTabService into an implementation for
the parent process, and one for content processes.
This split will hopefully help reduce confusion about which code in
AboutNewTabService is running in which process.
Differential Revision: https://phabricator.services.mozilla.com/D65569
--HG--
rename : browser/components/newtab/test/xpcshell/test_AboutNewTabService.js => browser/components/newtab/test/xpcshell/test_AboutNewTab.js
extra : moz-landing-system : lando
This patch does the following:
* Moves most logic for initiating about:home / about:newtab into AboutNewTab.jsm
* Makes AboutNewTab the API surface for overriding the default about:newtab URLs.
* Reduces the surface of nsIAboutNewTabService, and makes the properties read-only
* Splits the remaining code in the nsIAboutNewTabService into an implementation for
the parent process, and one for content processes.
This split will hopefully help reduce confusion about which code in
AboutNewTabService is running in which process.
Differential Revision: https://phabricator.services.mozilla.com/D65569
--HG--
rename : browser/components/newtab/test/xpcshell/test_AboutNewTabService.js => browser/components/newtab/test/xpcshell/test_AboutNewTab.js
extra : moz-landing-system : lando
This telemetry records, for each toplevel window, the relationship between the
actual fission-enabled status of the window, and the "fission.autostart" pref.
This takes the form of a categorized telemetry histogram with the following
keys:
* EnabledByAutostart: useRemoteSubframes == true fission.autostart == true
* EnabledByUser: useRemoteSubframes == true fission.autostart == false
* DisabledByAutostart: useRemoteSubframes == false fission.autostart == false
* DisabledByUser: useRemoteSubframes == false fission.autostart == true
'DisabledByUser' helps indicate useful information such as how often fission
testers need to open non-fission windows due to breakage, while
'EnabledByAutostart' and 'EnabledByUser' helps give a better image of how many
people are testing fission.
Differential Revision: https://phabricator.services.mozilla.com/D61927
--HG--
extra : moz-landing-system : lando
Added right click on new tab button to open containers menu.
Removed long press and added option to enable left click in preferences menu.
Renamed privacy.userContext.longPressBehavior to privacy.userContext.newTabContainer.enabled
Differential Revision: https://phabricator.services.mozilla.com/D58410
--HG--
extra : moz-landing-system : lando
This patch was started by Alex Vamvounis <a.vamvounis@gmail.com> and finished by
Mike Conley <mconley@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D53075
--HG--
extra : moz-landing-system : lando
focusAndSelectUrlbar can fire after isCustomizing() is false but before customizeMode is fully exited. This means the Urlbar is refocused but then quickly loses focus after the main browser window is focused. By adding this additional check we can be sure that the browser focus event occurs before the Urlbar is refocused.
Differential Revision: https://phabricator.services.mozilla.com/D59715
--HG--
extra : moz-landing-system : lando
Top Sites must be disabled for this to work correctly. This is because we haven't defined the behaviour for when two restricting providers are active. Bug 1607797 must be resolved before this is preffed on.
Differential Revision: https://phabricator.services.mozilla.com/D59351
--HG--
extra : moz-landing-system : lando
ContentBlockingEvents is now accessed via WindowGlobalActor::ContentBlockingEvents.
Updating and storing contentBlockingEvent in RemoteSecurityUI are no longer needed.
Depends on D55622
Differential Revision: https://phabricator.services.mozilla.com/D55623
--HG--
extra : moz-landing-system : lando
ContentBlockingEvent in RemoteSecurityUI is updated after receiving a notification from a child process.
Since contentBlockingEvent will be removed from the child, this patch removes the use of
contentBlockingEvent in RemoteSecurityUI and uses the API defined in WindowGlobalActor.
Depends on D55621
Differential Revision: https://phabricator.services.mozilla.com/D55622
--HG--
extra : moz-landing-system : lando
These events were sent excessively on onStateChange. This patch makes it so that:
- we only listen to top-level document changes (we used to send all events from iframes)
- we don't send events unless there's tracking content on the page
- we only send a single event on tab switch instead of multiple
Differential Revision: https://phabricator.services.mozilla.com/D57006
--HG--
extra : moz-landing-system : lando
If the user types a full url, confirms it, and then focuses the urlbar, we should
not
When focusing the address bar after typing and confirming a page, we end up reopening
the view because the search string is the same. This causes unexpected noise and
selection problems (the url is not selected anymore).
This patch changes the behavior so we don't reopen on valid pageproxystate, that
seems to make sense considering the feature scope of restoring an abandoned search.
Additionally, make the keyboard shortcut not trying to reopen the view if it's
already open, to avoid messing up with the selection.
Finally, restore the appropriate allowAutofill status from the last context.
This may still cause us to not autofill something that was previously autofilled,
if 2 tabs contain the same exact search, but that's an edge case, so acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D56635
--HG--
extra : moz-landing-system : lando
