This is a pretty big change on paper, but most of the lines are copy-pasted, with some small
adjustments to get the content blocking code comfortable in browser-siteProtections.js.
Differential Revision: https://phabricator.services.mozilla.com/D37556
--HG--
extra : moz-landing-system : lando
This is a pretty big change on paper, but most of the lines are copy-pasted, with some small
adjustments to get the content blocking code comfortable in browser-siteProtections.js.
Differential Revision: https://phabricator.services.mozilla.com/D37556
--HG--
extra : moz-landing-system : lando
This patch makes the mini panel been shown after page reload due to
switch the tracking protection state. The mini panel will be auto hidden
after certain time, which can be configured by the pref
'browser.protections_panel.mini_panel_auto_hide_timing'. The default
value is 5 seconds.
This also implements the behavior that showing the protections panel on
clicking the mini panel.
Differential Revision: https://phabricator.services.mozilla.com/D36018
--HG--
extra : moz-landing-system : lando
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
This patch introduces a new type of content process, which has a dynamic name.
This type of content process is labeled as `webIsolated=${SITE_ORIGIN}` and is
used within fission-enabled windows.
To enable this, additional information about the fission status of the target
window must be passed into E10SUtils. This was done by updating every call site
manually to pass an extra boolean. A better solution perhaps should be used in
the future.
With this patch enabled, we now perform process switches, but only when
navigating to HTTP URIs. If we navigate to a non-HTTP URI in an iframe with
fission enabled, it will not behave correctly. This must be done in a
follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29570
--HG--
extra : moz-landing-system : lando
When UrlbarInput.uninit is called after customize mode ends, uninit calls this.inputField.controllers.removeControllerAt(0), which is supposed to remove the input's CopyCutController inserted in the constructor. But the controller at index 0 at that point is not the CopyCutController. Instead it's some built-in controller that supports these commands (at least these): cmd_charPrevious, cmd_charPrevious, cmd_beginLine, cmd_endLine. (Verified by adding logging to nsXULControllers::GetControllerForCommand.) That's why arrow left/right and home/end don't work after ending customize mode.
The problem is that this.inputField.controllers in the constructor and this.inputField.controllers in uninit (when customize mode ends) are not the same. I wasn't able to track down why, but I'm guessing that the textbox or something in its state is being reset or cloned when customized mode ends or maybe right after it starts. The CopyCutController isn't in the controllers array at all on uninit. (Verified by adding support for cmd_adw and iterating through the controllers array, looking for a controller supporting cmd_adw.)
Note that urlbarBindings.xml has a try-catch around removeController(), I'm guessing for what turns out to be this reason: https://searchfox.org/mozilla-central/rev/7944190ad1668a94223b950a19f1fffe8662d6b8/browser/base/content/urlbarBindings.xml#190
However, CopyCutController *is* in the controllers array when customize mode starts. So I added a new gURLBarHandler.customizeStart method that calls a new UrlbarInput.removeCopyCutController method.
Other things I tried or thought of doing:
Call gURLBarHandler._reset on customize start instead of end. Problem with that is that the UrlbarInput ends up getting immediately recreated because some other parts of the browser access gURLBar at that time. (Of course I replaced the `gURLBar = this.urlbar` assignment in _reset with another lazy getter definition.)
Just don't worry about removing CopyCutController at all. That seems bad because then we'd leak it, unless the controller is removed or the controllers array is emptied at some point by XUL, and I'm not at all certain about that. (Although I guess this is effectively what awesomebar does, given the link above!)
Differential Revision: https://phabricator.services.mozilla.com/D29613
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
So it is still preventDefault()able once non-primary clicks aren't web visible.
Don't let browser.js' contentAreaClick handle any non-primary clicks.
ClickHandlerChild.jsm handles them first anyway. Can probably rip it out
entirely in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D26791
--HG--
extra : moz-landing-system : lando
This code builds on top of the E10S "remote tabs" configuration system to add a
system for specifying that remote subframes should be used. Fission can be
enabled for a window by including the "fission" flag in options when opening
the window.
Differential Revision: https://phabricator.services.mozilla.com/D26560
--HG--
extra : moz-landing-system : lando
Applying the attribute early enough allows us to avoid rebinding the urlbar,
plus a few checks to ensure "popup" windows, without a visible toolbar, work
properly.
Differential Revision: https://phabricator.services.mozilla.com/D27253
--HG--
extra : moz-landing-system : lando
Removed FX_PREFERENCES_OPENED_VIA probe as it expired in 63.Origin parameter for openPreferences has also been removed.
Differential Revision: https://phabricator.services.mozilla.com/D26795
--HG--
extra : moz-landing-system : lando
The larger changesets in this patch are simply moving code from one file into the other with hg mv.
A short summary of the changes:
- I removed the forked redirection from AboutRedirector.cpp
- I deleted the original aboutNetError.xhtml and aboutNetError.css files
and moved aboutNetError-new.xhtml and aboutNetError-new.css in their place instead.
- I removed the browser.security.newcerterrorpage.enabled pref and all its usages.
- I removed some localization strings and resources that went unused because of the above changes.
Differential Revision: https://phabricator.services.mozilla.com/D25232
--HG--
extra : moz-landing-system : lando
Replaced instances of callers in both C++ and JS files to query the state from the principal directly.
Differential Revision: https://phabricator.services.mozilla.com/D22532
--HG--
extra : moz-landing-system : lando
This limits us to 1 preloaded browser per window, in the top 3 normal windows + top 3 private windows.
If we try to create additional browsers beyond that, we instead move a pre-existing browser across.
Differential Revision: https://phabricator.services.mozilla.com/D21129
--HG--
extra : moz-landing-system : lando
Add histograms to count fingerprinting and cryptomining blocking states per page load.
Differential Revision: https://phabricator.services.mozilla.com/D20389
--HG--
extra : moz-landing-system : lando
This limits us to 1 preloaded browser per window, in the top 3 normal windows + top 3 private windows.
If we try to create additional browsers beyond that, we instead move a pre-existing browser across.
Differential Revision: https://phabricator.services.mozilla.com/D21129
--HG--
extra : moz-landing-system : lando
When switching tabs we use the securityUI.contentBlockingEvent property to update the shield state.
That property is set in https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/browser/base/content/browser.js#5025.
Unfortunately, that event is only received by the current browser because is is registered with gBrowser.addProgressListener instead of gBrowser.addTabsProgressListener. Thus, the background tab is not storing its content blocking event.
To fix this, we also listen for content blocking events with addTabsProgressListener, but exclude the
currently selected tab there.
Differential Revision: https://phabricator.services.mozilla.com/D23485
--HG--
extra : moz-landing-system : lando
Just set the RemoteType in the options object argument, instead of
doubling up the information.
Differential Revision: https://phabricator.services.mozilla.com/D23250
--HG--
extra : moz-landing-system : lando
Add histograms to count fingerprinting and cryptomining blocking states per page load.
Differential Revision: https://phabricator.services.mozilla.com/D20389
--HG--
extra : moz-landing-system : lando
This also changes the name of 'canceledAuthenticationPromptCounter' to account for the
fact that we no longer count up when the prompt was cancelled, but when it was shown.
Differential Revision: https://phabricator.services.mozilla.com/D21680
--HG--
extra : moz-landing-system : lando
We had previously missed to call browser.updateSecurityUIForContentBlockingEvent on
onLocationChange updates, to reset the contentBlockingEvent state. This would mean that
on tab switch the contentBlockingEvent state for benign pages would still be what it was
set to on the last tracker page.
Differential Revision: https://phabricator.services.mozilla.com/D20328
--HG--
extra : moz-landing-system : lando
This patch changes the name of LanguagePrompt.jsm to RFPHelper.jsm.
The RFPHelper is going to not only be responsible for the language
--HG--
rename : toolkit/components/resistfingerprinting/LanguagePrompt.jsm => toolkit/components/resistfingerprinting/RFPHelper.jsm
extra : histedit_source : 37b437de2c52b37b07da11cabdbcb9f2749c0a65
This patch changes the name of LanguagePrompt.jsm to RFPHelper.jsm.
The RFPHelper is going to not only be responsible for the language
--HG--
rename : toolkit/components/resistfingerprinting/LanguagePrompt.jsm => toolkit/components/resistfingerprinting/RFPHelper.jsm
extra : rebase_source : 58e6b8e167dfb01db9115a9b8c929fe533e31592
Replaced new Function() by CustomEvent carrying original click event as sourceEvent.
Adapted all oncommand listeners to use event.sourceEvent instead of event.
Differential Revision: https://phabricator.services.mozilla.com/D18847
--HG--
extra : moz-landing-system : lando
Having separate tab stops for every toolbar control results in an unmanageable number of tab stops.
Therefore, we group several buttons under a single tab stop and allow movement between them using left/right arrows.
However, text inputs use the arrow keys for their own purposes, so they need their own tab stop.
There are also groups of buttons before and after the URL bar input which should get their own tab stop.
The subsequent buttons on the toolbar are then another tab stop after that.
Tab stops for groups of buttons are set using the <toolbartabstop/> element.
This element is invisible, but gets included in the tab order.
When one of these gets focus, it redirects focus to the appropriate button.
This avoids the need to continually manage the tabindex of toolbar buttons in response to toolbarchanges.
Navigation to for the View site information button and notification anchors is now managed by this new framework.
As such, they no longer need their own position in the tab order and the CSS has been tweaked accordingly.
For now, this new functionality is behind a pref (browser.toolbars.keyboard_navigation) which is currently disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D15060
--HG--
extra : moz-landing-system : lando
Having separate tab stops for every toolbar control results in an unmanageable number of tab stops.
Therefore, we group several buttons under a single tab stop and allow movement between them using left/right arrows.
However, text inputs use the arrow keys for their own purposes, so they need their own tab stop.
There are also groups of buttons before and after the URL bar input which should get their own tab stop.
The subsequent buttons on the toolbar are then another tab stop after that.
Tab stops for groups of buttons are set using the <toolbartabstop/> element.
This element is invisible, but gets included in the tab order.
When one of these gets focus, it redirects focus to the appropriate button.
This avoids the need to continually manage the tabindex of toolbar buttons in response to toolbarchanges.
Navigation to for the View site information button and notification anchors is now managed by this new framework.
As such, they no longer need their own position in the tab order and the CSS has been tweaked accordingly.
For now, this new functionality is behind a pref (browser.toolbars.keyboard_navigation) which is currently disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D15060
--HG--
extra : moz-landing-system : lando
AddonManagergetInstallForURL() has a number of optional arguments, most
of which are passed infrequently. Convert them from positional arguments
to a single options object.
Differential Revision: https://phabricator.services.mozilla.com/D18475
--HG--
extra : rebase_source : 503c09b54fab90cefe69286b05def43ef70074df
The fix in bug 1312243 introduced a maximum of three consecutive cancelations (controlled by a pref) that a user could perform until Firefox would prevent the page from showing more dialogs.
This, in my opinion, is a great idea. The implementation, however, has a major fallacy: It checks the inner window id in the well-meaning attempt to find user navigation or reloads and clears its internal counter when that window id changes. Unfortunately this also clears the counter on non-user-initiated navigations and reloads. I believe that the true intention of the patch was to cancel the auth dialog after 3 attempts, except if:
- The user reloads the page on their own terms
- The user navigates to a different site on their own
Which is what I plan to implement, using the same pattern we applied to implement temporarily blocked site permissions:
- Temporarily store basic auth counter state on the browser object, as a map from baseDomain (eTLD+1) to number of cancellations
- Reset this state only on user initiated reload
- Reset the counter for a domain if the user has entered login data into the dialog and submitted
This would mitigate the DOS issue while hopefully not breaking any sites that rely on basic auth.
Differential Revision: https://phabricator.services.mozilla.com/D18019
--HG--
extra : moz-landing-system : lando
This is a rollup of all the patches that have landed on the cedar project branch:
891252fdd0
Bug 1492475 - Part 1: Migrate most, if not all nsSearchService consumers to use async APIs. r=florian
79b2eb2367
Bug 1492475 - Part 2: Move nsIBrowserSearchService.idl to toolkit/components/search/nsISearchService.idl and update references. r=florian
a947d3cdf0
Bug 1492475 - Part 3: The search service init() method should simply return a Promise. r=florian
c1e172dfac
Bug 1492475 - Part 4: Remove the synchronous initialization flow. r=florian
cd41189eac
Bug 1492475 - Part 5: Since async initialization of the search service now is implicit behavior, remove the distinctive verbiage used internally. r=florian
2ae7189dfa
Bug 1492475 - Part 6: Update the cache build task to work with an actual Promise and re-initialize only once at the same time - all to fix race conditions here. r=florian
c8ee92973f
Bug 1492475 - Part 7: Make the region fetch not block the init flow, to ensure it's as fast as possible. r=florian
c44e674e16
Bug 1492475 - Part 8: Introduce an init flag, which can only be used privately, that allows to explicitly skip waiting for the region check process to complete. r=florian
6c79eaf1d3
Bug 1492475 - Part 9: Update unit tests to stop using 'currentEngine', in favor of 'defaultEngine'. r=Standard8
21b3aa17ee
Bug 1492475 - Part 10: Update unit tests to be fully aware of the new, async signatures of the search service API and remove sync init flow tests. r=mkaply,florian
ce5ba69019
Bug 1492475 - Part 11: Repair incorrect usage of the `identifier` property of nsISearchEngine instances. r=florian
fd177a7994
Bug 1518543 - Fix up the Android (Fennec) nsISearchService shim to work with the new asynchronous API. r=florian
3653d8ee22
Bug 1523708 - Change the search service interaction in the show-heartbeat action to use the new async API. r=florian
Differential Revision: https://phabricator.services.mozilla.com/D18355
--HG--
rename : netwerk/base/nsIBrowserSearchService.idl => toolkit/components/search/nsISearchService.idl
extra : moz-landing-system : lando
