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
With recent fixes that can properly identify whitelisted domains, whitelisted
domain suffixed, valid known public suffixes, and forcing to visit URI-like
strings that end with a slash, it's time to re-evaluate the URIFixup behavior.
Until now URIFixup considered everything a URI unless it had specific search
characteristics, this patch inverts that behavior.
The scope of this change is to improve the urlbar behavior as the main Search
Access Point, since that's the direction we're moving towards.
This lands with a temporary hidden feature pref browser.fixup.defaultToSearch,
that will be removed once the feature has been released.
Differential Revision: https://phabricator.services.mozilla.com/D76852
Creates a new pref, "...activity-stream.feeds.system.topsites" to control whether TopSitesFeed is enabled. The existing "...activity-stream-feeds.topsites" pref is kept to allow users to downgrade and to ensure that people who disabled Top Sites in the past will continue to not see Top Sites on the New Tab Page -- the difference being that Top Sites will now be generated for those users.
Differential Revision: https://phabricator.services.mozilla.com/D75603
The private search result is shown in Nightly but not otherwise. The test is
failing because it expects the private search result to be at index 1 and the
form history result to be at index 2, but the form history is actually at index 1.
The test just needs to get the right index. There's another part of the test
that clicks a remote suggestion, but it's not affected because the search
happens to match a couple of history results, so the private search result isn't
shown even on Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D76585
The need for --disable-install-strip in the mac mozconfigs comes from a
discrepancy in how stripping is handled between platforms. On Windows,
there is no stripping. On non-Mac unix, `strip` removes local symbols as
well as debug info and debug symbols. On Mac, it actually removes too
much, and one has to pass flags to remove both local symbols (`-x`) and
debug symbols (`-S`). Debug info is already in a separate file
(`.dSYM`).
For profiling reasons, we do ship e.g. nightlies with local symbols but
not debug info or symbols (or at least that's the intent). On Windows,
again, nothing to do. On non-Mac unix, we pass `--strip-debug` to
`strip` so that it keeps local symbols. That's where the discrepancy
comes in for Mac: the build system doesn't handle this at all, so the
mozconfigs contain --disable-install-strip to avoid stripping.
The build system should be doing what it's expected to be doing from the
start, without mozconfigs opting into anything.
AFAIK, we only really need the local symbols, so we can `strip -S` on
Mac when profiling is enabled, rather than `strip -x -S`. This also
significantly reduces the size of the installer for nightlies.
And while we're here, move the logic out of old-configure and into
python configure.
Differential Revision: https://phabricator.services.mozilla.com/D76789
This is mostly changes to handle retrieving the security state asynchronously via the parent process, needing lots of async/await additions.
It also removes the docshell mixed content flag checks (which don't seem to be used in code, only tests), which are mostly still covered by checks of the security UI.
Differential Revision: https://phabricator.services.mozilla.com/D75448
This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
Differential Revision: https://phabricator.services.mozilla.com/D75447
Detect a profile for the installation, if found offer refresh on welcome page:
- Replace text
- Add help link and button
Add a different prompt to close the browser for refresh.
When leaving the welcome page:
- via help link, launch a URL
- via Refresh button, launch Firefox with the necessary args
Add utility functions to launch the link and Firefox.
Remove the UN_CONFIRM_CLICK label and hide the subheading, this was an
addition to the design. Move down UN_CONFIRM_PAGE_TITLE to fill in the space.
Move the check for the install-specific profile to common.nsh from stub.nsi,
wrapped in stack ops to save regs and with _MOZFUNC_UN for uninstaller compat.
Move InitHashAppModelId to just after un.UninstallUnOnInitCommon (which sets
$INSTDIR correctly), so AUMID would be available in un.PreWelcome. I don't
think there's anything else that would change $INSTDIR in the uninstaller
so this should be ok.
Unrelated but adjacent cleanup: Remove inappropriate use of _MOZFUNC_UN
in CopyPostSigningData.
Differential Revision: https://phabricator.services.mozilla.com/D76435
This is mostly changes to handle retrieving the security state asynchronously via the parent process, needing lots of async/await additions.
It also removes the docshell mixed content flag checks (which don't seem to be used in code, only tests), which are mostly still covered by checks of the security UI.
Differential Revision: https://phabricator.services.mozilla.com/D75448
This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
Differential Revision: https://phabricator.services.mozilla.com/D75447
This implements reading the list from remote settings. We only read it at startup if necessary, or on add-on installation.
We do not check for updates - if something is removed, we'll wait until next startup before processing it.
Also adds lots of tests for canOverride as this seems a critical part to get right.
Differential Revision: https://phabricator.services.mozilla.com/D76473
It's possible for gBrowser.selectedTab to be set to null. This should be a no-op, but this
part of webrtcUI that tabbrowser calls doesn't handle the case, and causes an exception to
be thrown. This patch allows the no-op case to occur properly.
Differential Revision: https://phabricator.services.mozilla.com/D76736
These features allow the indicator to not pull focus from the originating window, which
is important to maintain user task continuity, especially for screenreader users.
Differential Revision: https://phabricator.services.mozilla.com/D76735
This also requires removing the registry value cleanup from the unregister-task
command and adding a new uninstall command which removes both the task and the
registry values, because this patch now runs unregister-task during updates to
remove the task before re-adding it, and that needs to leave the registry alone.
Differential Revision: https://phabricator.services.mozilla.com/D76354
