While the availability of Reader View is somewhat noticeable visually, a screen reader user won't be aware of this unless they explicitly explore the toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D48036
--HG--
extra : moz-landing-system : lando
This reverts bug 1425541.
This was intended to make it easy for accessibility clients to retrieve the Reader View state programmatically.
However, it was never actually used by any clients.
Differential Revision: https://phabricator.services.mozilla.com/D48035
--HG--
extra : moz-landing-system : lando
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
This doesn't enable the rightClick option for telemetry reporting as that is complicated to support, see bug 1528250.
Differential Revision: https://phabricator.services.mozilla.com/D19951
--HG--
extra : moz-landing-system : lando
This makes the browser_UsageTelemetry_urlbar*.js tests pass for the all of the
FX_URLBAR_SELECTED_RESULT_* histograms apart from the "METHOD" one which will be handled
in bug 1500476.
I have handled the recording of telemetry in the controller, as this seems a better
location than BrowserUsageTelemetry.jsm due to needing to reach into the results and obtain
specific details.
Differential Revision: https://phabricator.services.mozilla.com/D19785
--HG--
extra : moz-landing-system : lando
This add checks for everything bar 'preloaded-top-site' which isn't used/enabled at the moment (bug 1527888).
Depends on D19709
Differential Revision: https://phabricator.services.mozilla.com/D19784
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
Replacing existing getParentProcessScalars with a generic implementation of getProcessScalars
Differential Revision: https://phabricator.services.mozilla.com/D18861
--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
This patch includes the following changes:
- added a new "num_strings" extra key to the "addonsManager install" and "addonsManager manage"
telemetry events, where "num_strings" represents the "number of permissions actually visible
in the extension permission doorhanger"
- do not record a telemetry event for the "permission_prompt" (or "sideload_prompt") if the
permissions_prompt is not going to be shown
- add num_strings and removed "num_perms" and "num_origins" extras from the test assertions in the existing tests
- added some additional assertions to test in automation that we don't record the telemetry
event for "permission_prompt" when no permission prompt is being shown for an
extension update (as part of the browser_extension_update_background_noprompt.js test)
Differential Revision: https://phabricator.services.mozilla.com/D16992
--HG--
extra : moz-landing-system : lando
This custom element replaces XBL <content> usage by directly prepend the two needed child nodes when the element is connected.
This is doable because
- There isn't any direct access of child nodes under <menulist>. Everyone seems to access via .menupopup, which is usually the only child.
- We don't need to move the children under <menulist>. If we need to and if the child is a <xbl:children> (which could happen if <menulist> is inside an XBL <content> that just get cloned to the document), the layout will get very confused and crash (see finding in bug 1514926)
Differential Revision: https://phabricator.services.mozilla.com/D16149
--HG--
rename : toolkit/content/widgets/menulist.xml => toolkit/content/widgets/menulist.js
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
As non-promptable permission won't prompt user to ask for their approval, we should use different texts for the cancel button of promptable permissions.
Differential Revision: https://phabricator.services.mozilla.com/D16770
--HG--
extra : moz-landing-system : lando
As non-promptable permission won't prompt user to ask for their approval, we should use different texts for the cancel button of promptable permissions.
Differential Revision: https://phabricator.services.mozilla.com/D16770
--HG--
extra : moz-landing-system : lando
We're going to remove all autoplay temporary permission related codes, so we don't need to cache it anymore.
Differential Revision: https://phabricator.services.mozilla.com/D14325
--HG--
extra : moz-landing-system : lando
We've handle showing the blocking icon in patch2, so we don't need to set block permission in PermissionUI.
Differential Revision: https://phabricator.services.mozilla.com/D14797
--HG--
extra : moz-landing-system : lando
We've handle showing the blocking icon in patch2, so we don't need to set block permission in PermissionUI.
Differential Revision: https://phabricator.services.mozilla.com/D14797
--HG--
extra : moz-landing-system : lando
This is an attempt to fix a Talos regression caused by the cost of URL
parsing. The approach I'm taking here is to modify the requirements of
bug 1509047 part 2 slightly so that I can remove the expensive code
which resulted in the Talos regression.
The change in behaviour is that the automatic access grants for the
Storage Access API will use the number of unique domains visited in the
session as opposed to the number of unique origins visited.
Differential Revision: https://phabricator.services.mozilla.com/D14156
--HG--
extra : moz-landing-system : lando
There is a problem in FaviconLoader where we can attempt to load icons after the
page has been unloaded somehow. Because DeferredTask pushes its task to the idle
queue there is a short gap between when DeferredTask's timer fires and when its
task starts. If the page is unloaded in that gap we are unable to cancel the
task and when it starts it fails to access the content page.
However, when the page unloads we do clear the list of icons and since there is
no reason to do anything when the list of icons is empty we can just bail out
of the load task early and never try to touch the content page in this case.
Differential Revision: https://phabricator.services.mozilla.com/D14188
--HG--
extra : moz-landing-system : lando
This is a quick fix to ensure that the search install panel is shown when an extension uses is_default. The intention is to uplift for 64.
Differential Revision: https://phabricator.services.mozilla.com/D13078
--HG--
extra : moz-landing-system : lando
Jan-Ivar Bruaroey
James Teh
Sebastian Hengst
Mark Banner
Gijs Kruitbosch
Tom Tung
Oana Pop Rus
Michael Kaply
Doug Thayer
Emilio Cobos Álvarez
Ed Lee
Olli Pettay
Drew Willcoxon
Sebastian Streich
Haik Aftandilian
Paul Zuehlcke
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
Jared Wein
Mike Conley
Csoregi Natalia
Boris Zbarsky
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
ui.manish
Razvan Maries
Narcis Beleuzu
Christoph Kerschbaumer
Gurzau Raul
Junior Hsu
Alexander Surkov
Mark Striemer
Varun Dey
Myk Melez
Timothy Guan-tin Chien
alwu
Harry Twyford
Michael Kelly
Dave Townsend
Daniel Stenberg
Dennis Schubert
Jan Varga