This just pulls chunks of TelemetryStopwatch and similar code,
which often eats up several lines, into some helper functions.
This should just help reduce the cognitive load of reading this
code.
Depends on D47349
Differential Revision: https://phabricator.services.mozilla.com/D47350
--HG--
extra : moz-landing-system : lando
This way we ensure that the reentrancy guard always stays in effect.
It should just be a little easier to reason about everything if it's
all channeled through the same place.
Differential Revision: https://phabricator.services.mozilla.com/D47349
--HG--
extra : moz-landing-system : lando
It's useless if the tab is already visible (i.e., has renderLayers=true), per
the previous patches, and that's the only point at which it gets called.
Differential Revision: https://phabricator.services.mozilla.com/D47131
--HG--
extra : moz-landing-system : lando
Adds a new event listener to `browser.urlbar` called `onResultPicked`. This event is fired for tip results when they don't specify a URL. Hypothetically it could be fired for any type of result that didn't specify a URL, but that's only tips for now.
The listener is passed two arguments: the payload of the result that was picked, and a "details" object whose properties depend on the type of result. For tips, details is `{ helpPicked }`, where `helpPicked` is true if the help button was picked and false if the main button was picked.
Differential Revision: https://phabricator.services.mozilla.com/D46254
--HG--
extra : moz-landing-system : lando
Re-enable skipped webRTC tests on Mac which were disabled due to the macOS 10.14 permission prompts causing timeouts.
Don't trigger OS camera and microphone permission prompts for fake devices (used for tests).
Differential Revision: https://phabricator.services.mozilla.com/D46893
--HG--
extra : moz-landing-system : lando
There is still another related bug 1579591, which this may make a bit less likely, since that seems to be timing dependent, but
the patch is not trying to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D46242
--HG--
extra : moz-landing-system : lando
This is done to offset the requirement that extensions have to get persistent permission before
they can start using WebRTC in popups.
Differential Revision: https://phabricator.services.mozilla.com/D45335
--HG--
extra : moz-landing-system : lando
The goal is to
- Avoid showing any permission prompt when calling getUserMedia in webextension popups,
while still checking for persistent permissions.
- Never allow getUserMedia calls on background pages.
Differential Revision: https://phabricator.services.mozilla.com/D45333
--HG--
extra : moz-landing-system : lando
This is done to offset the requirement that extensions have to get persistent permission before
they can start using WebRTC in popups.
Differential Revision: https://phabricator.services.mozilla.com/D45335
--HG--
extra : moz-landing-system : lando
The goal is to
- Avoid showing any permission prompt when calling getUserMedia in webextension popups,
while still checking for persistent permissions.
- Never allow getUserMedia calls on background pages.
Differential Revision: https://phabricator.services.mozilla.com/D45333
--HG--
extra : moz-landing-system : lando
This is done to offset the requirement that extensions have to get persistent permission before
they can start using WebRTC in popups.
Differential Revision: https://phabricator.services.mozilla.com/D45335
--HG--
extra : moz-landing-system : lando
The goal is to
- Avoid showing any permission prompt when calling getUserMedia in webextension popups,
while still checking for persistent permissions.
- Never allow getUserMedia calls on background pages.
Differential Revision: https://phabricator.services.mozilla.com/D45333
--HG--
extra : moz-landing-system : lando
I haven't been able to work out a reason why we should show the
spinner before this.loadTimer is cleared. All this does is allow
for random reordering of events to sometimes show a spinner early.
This should ideally just make the spinner logic more rubust to
event ordering changes, without sacrificing visibility into tab
switch timings.
Differential Revision: https://phabricator.services.mozilla.com/D44878
--HG--
extra : moz-landing-system : lando
This just adds a bit of information to the AsyncTabSwitcher's
logging and cleans up the display to make it quicker to find
what changed, especially with large numbers of tabs. The bit of
new information that I'm particularly interested in is what
event triggered a particular update - so now every time we call
postActions, we include the name of the event.
Differential Revision: https://phabricator.services.mozilla.com/D44710
--HG--
extra : moz-landing-system : lando
The idea here is that we avoid updating all site data in SiteDataManager.jsm
just for checking a single host/origin and that we optimize performance by prioritizing
the most common data type (cookies) and synchronous lookups (AppCache) and returning
early if any data was found.
We will still refresh the site data list for clearing once the user clicks on "Clear Site Data".
Differential Revision: https://phabricator.services.mozilla.com/D42800
--HG--
extra : moz-landing-system : lando
This will allow these heuristics to be used on mobile.
This depends on GeckoView supporting a JavaScript module
at resource:///modules/BrowserUsageTelemetry.jsm with the
interface described in nsIBrowserUsage.idl. Bug 1573238 has
been filed in order to implement this module on GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D41621
--HG--
extra : moz-landing-system : lando
All built-in engines have migrated from OpenSearch to WebExtensions.
WebExtensions do not support resource: or chrome:-URLs in their
`favicon_url` field, so the "resource:" and "chrome:" URLs can only be
used by external opensearch XML files. These should not rely on internal
resources from omni.ja, as the bug shows. So just drop support for
"chrome:" and "resource:"-URLs, as we don't need them any more.
Current OpenSearch engines that relied on chrome/resource:-URLs can
either replace the URL with a data:-URL, or migrate to WebExtensions.
Differential Revision: https://phabricator.services.mozilla.com/D40345
--HG--
extra : moz-landing-system : lando
With the current code, if any event handler throws, `_processing` remains
true, and every subsequent event goes into an infinite loop dispatching 0ms
timeouts to run on the next tick.
Differential Revision: https://phabricator.services.mozilla.com/D39931
--HG--
extra : moz-landing-system : lando
This is based on D39589, which moves the top sites API from toolkit to browser.
* Add a `newtab` option to `browser.urlbar.topSites.get` (similar to the abandoned D36200) that returns exactly the top sites shown on newtab
* Add a `AboutNewTab.getTopSites` function that returns those sites from activity stream
* Keep the changes made in bug 1547669
There are a couple of missing things related to the default top sites that this doesn't address but ideally we would have. I think we can come back to these if necessary.
* Actual favicons for the default top sites instead of using the bigger tile images since they don't seem to be the same for every site.
* Proper names names for the default sites. There's a `hostname` property, but it would be nice to have e.g. "YouTube" instead of "youtube".
Differential Revision: https://phabricator.services.mozilla.com/D39591
--HG--
extra : moz-landing-system : lando
At a high level, this change does the following:
- move the pluginchild actor to be a JSWindowActorChild
- move the parent handling from browser-plugins into a JSWindowActorParent
- move the crash handling from ContentCrashHandlers.jsm to the parent actor,
using a `PluginManager` object. It needs to talk to the actors (and vice
versa), so this seemed a better fit than spreading actor implementation
details to other JSMs.
- switch to using plugin IDs to identify plugins cross-process, instead of
combinations of names or other properties of the plugin tag. As part of that,
ensured plugin IDs are unique between "fake" plugins and the other ones.
- drop support for having a notification for more than 1 plugin. We only support
Flash, in practice, so there didn't seem to be much point in the added
complexity of trying to support more than 1 thing.
Some notes:
- the previous implementation mixes runIDs (for NPAPI plugin process "runs")
and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee
these don't conflict, so I've split them out to avoid issues. There's a
pluginCrashID object I pass around instead that has either a runID or
pluginID. Happy to rename some more for clarity.
- the previous implementation used `pluginInfo` and `plugin` for a bunch of
different types of variables. I've tried to be consistent, where:
* `pluginElement` is a DOM element for a plugin
* `activationInfo` is a JS object used to track click to play state for a plugin
* `plugin` is a plugintag as returned by the pluginhost service
* `pluginCrashID` is an identifier for a crashed plugin (see previous point).
- I'm still using broadcastAsyncMessage to tell the content processes about
gmp plugin crashes and plugin crash submission updates, because there's no
guarantee the actors are instantiated (for gmp plugins) nor can the parent
easily find out which actors to talk to (for either gmp or npapi plugins).
Open to suggestions there, too. I think our best bet might be moving that to
IPDL-based IPC within the GMP code, but that feels like a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D37665
--HG--
rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm
extra : moz-landing-system : lando
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : source : f4e21e465f384b90fa1e768141c4db708748bf66
extra : histedit_source : 95d8a4242e8e04df9e29c2b647558d37e910b845
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : rebase_source : affeda0295a5195124709f322de524aea3a28a3f
In bug 1519577, the badged-button class for toolbarbuttons was replaced
with a "badged" attribute but a few old uses of the class were overlooked.
This patch fixes them.
Differential Revision: https://phabricator.services.mozilla.com/D34438
--HG--
extra : moz-landing-system : lando
In https://hg.mozilla.org/mozilla-central/rev/25397a6f8c4f#l1.35 we added an early return to
the SanitizeOnShutdown function to avoid cleaning principals by permission if the user had
set their preferences to clear all storage on shutdown anyway. This unfortunately ended
the function execution before it would call `removePendingSanitization("shutdown");` later on
and thus remove the pending shutdown sanitization (which, in fact, had completed successfully earlier).
The result is that the shutdown sanitization would be left dangling and run again on next startup,
where, for reasons I don't fully understand, it would race and conflict with loading the home page,
if that home page was from web content.
The solution is to remove the pending shutdown sanitization immediately after the sanitization is done.
As far as I can see there was never really a point in having it happen after session principal
cleanup finished, since in case of a crash it would not run the principal cleanup again next startup,
just the shutdown cleanup.
For good measure I also moved the new tab container sanitization to happen earlier in this function,
to prevent it from dangling as well.
Differential Revision: https://phabricator.services.mozilla.com/D33087
--HG--
extra : moz-landing-system : lando
The "add search engine" page action wants to use badged toolbarbuttons,
but it does this by adding the "badged-button" class (which changes the
XBL binding) after the button has already been created and added to
the DOM. To avoid having to switch between non-badged and badged buttons
when toolbarbutton is converted to custom elements, add a property to
page actions so that the badged status can be determined when the element
is created.
Differential Revision: https://phabricator.services.mozilla.com/D31940
--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
The "add search engine" page action wants to use badged toolbarbuttons,
but it does this by adding the "badged-button" class (which changes the
XBL binding) after the button has already been created and added to
the DOM. To avoid having to switch between non-badged and badged buttons
when toolbarbutton is converted to custom elements, add a property to
page actions so that the badged status can be determined when the element
is created.
Differential Revision: https://phabricator.services.mozilla.com/D31940
--HG--
extra : rebase_source : 335ba3c9ff73f3fa2f17ac113623e5572f7389c5
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
- `Array.map` becomes `Array.from`
- Array copying via `Array.slice` becomes `Array.from`.
- `Array.forEach` that did not rely on closures becomes `for`-`of` loops.
- Anything else: `Array.X` becomes `Array.prototype.X`.
Complex cases:
dom/bindings/test/TestInterfaceJS.js and
dom/bindings/test/test_exception_options_from_jsimplemented.html
use `Array.indexOf` to generate an error with a specific error message.
Switched to `Array.prototype.forEach` to generate the same error.
js/src/jit-test/tests/basic/exception-column-number.js
In this test `Array.indexOf()` is used to generate an error. Since the
exact message doesn't matter, I switched to `Array.from()`.
Intentionally not changed:
editor/libeditor/tests/browserscope/lib/richtext/richtext/js/range.js
Did not modify because this is 3rd-party code and the code uses
feature detection as a fall back when Array generics are not used.
testing/talos/talos/tests/dromaeo/lib/mootools.js
Did not modify because mootools adds the `Array.slice` method to the
`Array` object.
Not changed because they check the implementation of Array generics:
js/src/jit-test/tests/basic/arrayNatives.js
js/src/jit-test/tests/basic/bug563243.js
js/src/jit-test/tests/basic/bug618853.js
js/src/jit-test/tests/basic/bug830967.js
js/src/jit-test/tests/jaeger/recompile/bug656753.js
js/src/jit-test/tests/self-hosting/alternate-static-and-instance-array-extras.js
js/src/tests/non262/Array/generics.js
js/src/tests/non262/Array/regress-415540.js
js/src/tests/non262/extensions/regress-355497.js
js/src/tests/non262/extensions/typedarray-set-neutering.js
Depends on D27802
Differential Revision: https://phabricator.services.mozilla.com/D27803
--HG--
extra : moz-landing-system : lando
We need to handle autofilling the first result separately from autofilling results in general (which happens in UrlbarInput.setValueFromResult), so add a new UrlbarInput.autofillFirstResult method. The controller calls it instead of setValueFromResult. I ported the logic from nsAutoCompleteController, as described in the bug.
Other changes are related to the new test for this.
As part of this work, I was interested in learning how awesomebar handles browser_autoFill_typed.js, so I added it to the legacy tests, with a small tweak in the test for awesomebar.
Differential Revision: https://phabricator.services.mozilla.com/D26852
--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
This adds support for a "post-prompt" that appears dismissed (only the icon showing) when
the browser decides to automatically deny a permission request from a site (either based on
internal heuristics or because the user prefers not to receive permission prompts).
In order to move quickly and not overload the patch I have only implemented the post-prompting
for desktop-notification so far, however, implementing it for other permissions should be
a trivial follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D25415
--HG--
extra : moz-landing-system : lando
When history is cleared, clear the flag that indicates a user has visited the domain.
Differential Revision: https://phabricator.services.mozilla.com/D24404
--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
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
This adds an onRefresh option for app menus so we can update custom controls
in any opened window. In this case, we need to refresh the checkbox state in the
addon-installed panel. We test this using the theme install test and verify both
windows do not have the checkbox.
Differential Revision: https://phabricator.services.mozilla.com/D23224
--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
It doesn't need a high precision performance.now() to count minutes. In addition, if there are no windows to be closed, it's not doing anything, so it doesn't need to open a new one.
Differential Revision: https://phabricator.services.mozilla.com/D21083
--HG--
extra : moz-landing-system : lando
When we open firefox with pinned tabs, we first paint a window with
one tab open, and then that tab gets displaced after the pinned tabs
come in. This aims to ensure that our first paint contains the
pinned tab, so that we don't have tabs moving around after first
paint.
MozReview-Commit-ID: GC1y6NlgLTd
Differential Revision: https://phabricator.services.mozilla.com/D18742
--HG--
extra : moz-landing-system : lando
If no extension controls the settings, ExtensionSettings may not be initialized on startup. Fall back to the defaults in that case.
Differential Revision: https://phabricator.services.mozilla.com/D21866
--HG--
extra : moz-landing-system : lando
It doesn't need a high precision performance.now() to count minutes. In addition, if there are no windows to be closed, it's not doing anything, so it doesn't need to open a new one.
Differential Revision: https://phabricator.services.mozilla.com/D21083
--HG--
extra : moz-landing-system : lando
This adds a mechanism that discards tabs when the browser detects a low-memory
scenario. Tabs are discarded in LRU order prioritizing regular tabs over
pinned ones, pinned ones over tabs playing audio and all of the previous over
pinned tabs playing audio.
Differential Revision: https://phabricator.services.mozilla.com/D20476
--HG--
extra : moz-landing-system : lando
When we open firefox with pinned tabs, we first paint a window with
one tab open, and then that tab gets displaced after the pinned tabs
come in. This aims to ensure that our first paint contains the
pinned tab, so that we don't have tabs moving around after first
paint.
MozReview-Commit-ID: GC1y6NlgLTd
Differential Revision: https://phabricator.services.mozilla.com/D18742
--HG--
extra : moz-landing-system : lando
Doug Thayer
Mark Banner
Emilio Cobos Álvarez
Ed Lee
Olli Pettay
Drew Willcoxon
Sebastian Streich
Haik Aftandilian
Paul Zuehlcke
Oana Pop Rus
Kris Maglione
Daniel Varga
Rob Wu
Johann Hofmann
Bogdan Tara
Mihai Alexandru Michis
Harry Twyford
monikamaheshwari
Andreas Farre
Abdoulaye O. Ly
Ciure Andrei
Moritz Birghan
Ehsan Akhgari
Brindusan Cristian
Jan-Ivar Bruaroey
Jared Wein
Mike Conley
Michael Kaply
Csoregi Natalia
Boris Zbarsky
Gijs Kruitbosch
Sylvestre Ledru
Andreea Pavel
Jonathan Kingston
Sean Feng
Victor Porof
Andrew Swan
Geoff Lankow
Dale Harvey
Erica Wright
Nihanth Subramanya
Melvin George
Andrea Marchesini
Liang-Heng Chen
meandave
Cosmin Sabou
Nika Layzell
Ricky Rosario
Ryan Hunt
Mike de Boer
Dão Gottwald
Shane Caraveo
Trushita
phoenixabhishek
Jan-Erik Rediger
Luca Greco
Felipe Gomes
Andrei Oprea
akshitha
Tom Tung
Coroiu Cristina
Ian Moody
shindli
monmanuela
Thomas Nguyen
Kyle Machulis
Edouard Oger
Dorel Luca
Chris H-C
Marco Bonardo
Gabriele Svelto
Trishul