We don't have an aarch64 build of OpenH264 yet, and WebRTC on aarch64 is
blocked by DirectShow support from MS, so just hide OpenH264 from the addons
manager UI for now.
We achieve this by moving the isEME() check in GMPUtils.isPluginHidden() down
to after the isPluginSupported()||isPluginVisible() check, so we can use
the media.gmp-gmpopenh264.visible pref to hide OpenH264 in the addons
manager.
When we are ready to enable WebRTC, we can flip the pref.
Differential Revision: https://phabricator.services.mozilla.com/D19903
--HG--
extra : source : 2788a3e0544a3acba9de53165605496d8c357441
extra : intermediate-source : 35bdf7e8994c939d6fcd01e95c2183bacd5b11d3
extra : histedit_source : a8bdb3a1cb6bfd7c72dbbf1fae36c863e6fe5144
Extend ActorChild for satchel's formSubmitListener in order to listen to the event.
Differential Revision: https://phabricator.services.mozilla.com/D16655
--HG--
rename : toolkit/components/satchel/formSubmitListener.js => toolkit/components/satchel/FormSubmitChild.jsm
extra : moz-landing-system : lando
Extend ActorChild for satchel's formSubmitListener in order to listen to the event.
Differential Revision: https://phabricator.services.mozilla.com/D16655
--HG--
rename : toolkit/components/satchel/formSubmitListener.js => toolkit/components/satchel/FormSubmitChild.jsm
extra : moz-landing-system : lando
We write the ABI of the plugin we installed to preferences so that if the ABI
stored in the profile of a previously installed plugin differs to the ABI of
the Firefox build we're runnning, we can uninstall the plugin and re-install
one with the correct ABI.
Since we're downloading a plugin of a different ABI than the parent process,
we need to modify the ABI written to preferences here.
This mechanism was added to handle Firefox profiles transitioning from running
in an x86 Firefox to an x64 Firefox on Windows. We can use the same mechanism
to handle transitioning from an x86 to aarch64 Widevine here.
When we eventually get an aarch64 version of Widevine, we can
rollback this changeset, and the ABI mismatch will be detected, and we'll
uninstall the x86 CDM, and download the new aarch64 CDM.
Differential Revision: https://phabricator.services.mozilla.com/D19901
--HG--
extra : source : b5f5996f7225be2ae56d38f7f8833ca200743acb
extra : histedit_source : d831a00887ab8932fd001a511b0559a76fa832b7
Allows subsequent patches to special case behavior when running on
Windows on ARM64.
Differential Revision: https://phabricator.services.mozilla.com/D19899
--HG--
extra : source : 44e24c6d7a695e2a8ab5d1c2451f1fbf4d5d996f
extra : intermediate-source : 67cc92a41638ec58b5c54e871b0e5eede698c92e
extra : histedit_source : b2cca3608baf5b49228741877d4e5b5c4e3fa575
* New topLevel loads get the nsILoadInfo.openerPolicy of the current top level document
* Parsing the Cross-Opener-Origin-Policy of a channel will update mLoadInfo.openerPolicy and this value will get propagated to the child process.
* SessionStore now checks nsIHttpChannel.hasCrossOriginOpenerPolicyMismatch (preffed off) and performs a process switch if needed
Differential Revision: https://phabricator.services.mozilla.com/D19000
--HG--
rename : toolkit/components/remotebrowserutils/tests/browser/browser_httpResponseProcessSelection.js => toolkit/components/remotebrowserutils/tests/browser/browser_httpCrossOriginOpenerPolicy.js
extra : moz-landing-system : lando
For HTTP loads from the preloaded document, no process swap was occuring
if the preloaded document was loaded in a 'web' process. This caused
test failures, and has potentially undesireable behaviour.
This patch just moves the check for preloaded document swaps to before
the check for http parent process interception, forcing a swap like
normal.
Depends on D19691
Differential Revision: https://phabricator.services.mozilla.com/D19692
--HG--
extra : moz-landing-system : lando
For HTTP loads from the preloaded document, no process swap was occuring
if the preloaded document was loaded in a 'web' process. This caused
test failures, and has potentially undesireable behaviour.
This patch just moves the check for preloaded document swaps to before
the check for http parent process interception, forcing a swap like
normal.
Depends on D19691
Differential Revision: https://phabricator.services.mozilla.com/D19692
--HG--
extra : source : f7ab0e6e739bd54b66b8aaa6219c7dba78f37eb1
For HTTP loads from the preloaded document, no process swap was occuring
if the preloaded document was loaded in a 'web' process. This caused
test failures, and has potentially undesireable behaviour.
This patch just moves the check for preloaded document swaps to before
the check for http parent process interception, forcing a swap like
normal.
Depends on D19691
Differential Revision: https://phabricator.services.mozilla.com/D19692
--HG--
extra : moz-landing-system : lando
* New topLevel loads get the nsILoadInfo.openerPolicy of the current top level document
* Parsing the Cross-Opener-Origin-Policy of a channel will update mLoadInfo.openerPolicy and this value will get propagated to the child process.
* SessionStore now checks nsIHttpChannel.hasCrossOriginOpenerPolicyMismatch (preffed off) and performs a process switch if needed
Differential Revision: https://phabricator.services.mozilla.com/D19000
--HG--
rename : toolkit/components/remotebrowserutils/tests/browser/browser_httpResponseProcessSelection.js => toolkit/components/remotebrowserutils/tests/browser/browser_httpCrossOriginOpenerPolicy.js
extra : moz-landing-system : lando
Old Confluence does not aware of conflated model keypress event (see UI Events
spec, https://w3c.github.io/uievents/#determine-keypress-keyCode).
Additionally, Confluence can be hosted with any domains. Therefore, we cannot
use blacklist to disable the conflated model keypress event only on it.
This patch checks whether current or parent document is Confluence with JS
module, called KeyPressEventModelCheckerChild. For kicking this module,
nsHTMLDocument dispatches an custom event, CheckKeyPressEventModel, when it
becomes editable only first time. Finally, if it's a Confluence instance, the
module let PresShell know that we need to use split model keypress event in it.
Differential Revision: https://phabricator.services.mozilla.com/D17907
--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 is to fix some of our tests that use BrowserTestUtils.waitForNewWindow, where
the browser that ends up being passed to it doesn't actually need to flip
remoteness.
For example, in the file:// URI case, we allow the first browse to an HTTP
URI to run within the same process. This means that the preferred remote
type is "file", despite the URI normally mapping to the "web" type of
content process.
Differential Revision: https://phabricator.services.mozilla.com/D18226
--HG--
extra : moz-landing-system : lando
These are not generally used for support, and there can be many of them which makes the report larger and harder to understand.
Differential Revision: https://phabricator.services.mozilla.com/D18195
--HG--
extra : moz-landing-system : lando
Bug 1450114 -Update browser themes to allow customization of selection background and text r=Jaws
Differential Revision: https://phabricator.services.mozilla.com/D17076
--HG--
extra : moz-landing-system : lando
Send a downgrade ping to telemetry when the downgrade UI is displayed.
--HG--
extra : rebase_source : 43a2437c5bf1ef448e5b1ca1cc3e32fc98b02868
extra : intermediate-source : b965981c9ce0449a8d70df6ad47ebf6c4f1f70b9
extra : source : 348f67b15246aa63b83457fde1a17540fa21379e
Send a downgrade ping to telemetry when the downgrade UI is displayed.
--HG--
extra : rebase_source : 799ef400bc20aaab520641d21d744fe83aa5da27
extra : intermediate-source : 6bb1233693b8b2790263dbd511d92857a9d31e0b
extra : source : 348f67b15246aa63b83457fde1a17540fa21379e
This will only happen if the pref is enabled, and works through the existing
mechanism for process switching loads. It should enable POST data to be
preserved when performing a process switch, for example when submitting
a form on a file:// or moz-extension:// URI to a http:// URI.
Depends on D15611
Differential Revision: https://phabricator.services.mozilla.com/D15612
--HG--
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
JS classes, unlike var or const, are not automatically made part
of the global scope in JSMs. This makes it impossible to import
ActorChild this way:
const {ActorChild} = ChromeUtils.import("resource://gre/modules/ActorChild.jsm", {});
By assigning the ActorChild class to this we work around this problem.
Differential Revision: https://phabricator.services.mozilla.com/D17080
--HG--
extra : rebase_source : 88feda088b4e66a1166c7624d834e6a1565ced9b
extra : source : 4b6549b8a6012efa6a3b250b26fff7cf0d1ca564
JS classes, unlike var or const, are not automatically made part
of the global scope in JSMs. This makes it impossible to import
ActorChild this way:
const {ActorChild} = ChromeUtils.import("resource://gre/modules/ActorChild.jsm", {});
By assigning the ActorChild class to this we work around this problem.
Differential Revision: https://phabricator.services.mozilla.com/D17080
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
Let SessionStoreUtils be a WebIDL namespace, rather than a XPCOM service
Differential Revision: https://phabricator.services.mozilla.com/D9776
--HG--
rename : toolkit/components/sessionstore/nsSessionStoreUtils.cpp => toolkit/components/sessionstore/SessionStoreUtils.cpp
extra : moz-landing-system : lando
When an ActorChild is predefined to listen for DOM events and it
does not implement EventTarget.handleEvent(), a standard JS error is
thrown in toolkit/modules/ActorManagerChild.jsm that the handleEvent
property is missing.
If you have more than one ActorChild this error message is cryptic as
it does not refer to _which_ of the children that is missing handleEvent.
This patch introduces a type check for handleEvent that throws an
error (as before) when it is not implemented.
Differential Revision: https://phabricator.services.mozilla.com/D16578
--HG--
extra : moz-landing-system : lando
In order to make the history easier to navigate, this changeset includes the
modifications required to make <xul:browser> actually work as a Custom Element,
and switches the app to use it instead of the XBL browser.
Differential Revision: https://phabricator.services.mozilla.com/D14911
--HG--
extra : moz-landing-system : lando
This prepares this binding for the unification with the "popup" binding, and removes the last consumer of the scrollByIndex method of XULScrollElement.
Because some code paths in "arrowscrollbox" are optimized using requestAnimationFrame, the related scrolling tests are now asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D15276
--HG--
extra : rebase_source : f5d26df106785f2c0d158b8a23a648a71ab06b2d
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
This patch implements InputType.inputType which is declared by Input Events.
The attribute has already been implemented by Chrome and Safari. Chrome
implements Input Events Level 1, but Safari implements Input Events Level 2.
Difference between them is only whether it supports "insertFromComposition",
"deleteByComposition" and "deleteCompositionText". This patch makes the
level switchable with pref and takes Level 1 by default because Level 2 is
still unstable around event order with composition events.
For reducing string copy cost at dispatching "input" event, this patch
makes EditorInternalInputEvent store valid input-type as enum class,
EditorInputType and resolves it to string value when
dom::InputEvent::GetInputType() is called. Note that the reason why
this patch names the enum class as EditorInputType is, there is InputType
enum class already for avoiding conflict the name, this appends "Editor"
prefix because "input" and "beforeinput" events are fired only when an
editor has focus.
Differential Revision: https://phabricator.services.mozilla.com/D14128
--HG--
extra : moz-landing-system : lando
This event is used for shield-study which has finished, so we could remove it.
Differential Revision: https://phabricator.services.mozilla.com/D14810
--HG--
extra : moz-landing-system : lando
Use more proper name for actor which will handle all autoplay related events.
Differential Revision: https://phabricator.services.mozilla.com/D14796
--HG--
rename : toolkit/actors/AudibleAutoplayChild.jsm => toolkit/actors/AutoplayChild.jsm
extra : moz-landing-system : lando
Let SessionStoreUtils be a WebIDL namespace, rather than a XPCOM service
Differential Revision: https://phabricator.services.mozilla.com/D9776
--HG--
rename : toolkit/components/sessionstore/nsISessionStoreUtils.idl => dom/chrome-webidl/SessionStoreUtils.webidl
rename : toolkit/components/sessionstore/nsSessionStoreUtils.cpp => toolkit/components/sessionstore/SessionStoreUtils.cpp
extra : moz-landing-system : lando
This event is used for shield-study which has finished, so we could remove it.
Differential Revision: https://phabricator.services.mozilla.com/D14810
--HG--
extra : moz-landing-system : lando
Use more proper name for actor which will handle all autoplay related events.
Differential Revision: https://phabricator.services.mozilla.com/D14796
--HG--
rename : toolkit/actors/AudibleAutoplayChild.jsm => toolkit/actors/AutoplayChild.jsm
extra : moz-landing-system : lando
There are multiple fixes contained in this patch:
- fixes for Android/mobile support
- adding extra strings to the ftl file that were never defined before, and previously the ID was just printed to the page
- update test_l10n.py to not rely on about:support anymore
- changing Troubleshoot.jsm to return and ID and args for the strings that should be displayed, so it is compatible with the Fluent API
- misc. fixes so strings that are not localized don't go through the Fluent codepath
Differential Revision: https://phabricator.services.mozilla.com/D15437
--HG--
extra : moz-landing-system : lando
Summary:
I would like to get username fields etc from form or input element in form.
Since LoginManagerContent._getFormFields has "_" prefix (it means private
member) and LoginManagerCotnent.getFieldContext doesn't return elements,
I would like to add simple API for it.
Reviewers: MattN
Bug #: 1497682
Differential Revision: https://phabricator.services.mozilla.com/D12880
--HG--
rename : toolkit/components/passwordmgr/test/unit/test_getFormFields.js => toolkit/components/passwordmgr/test/unit/test_getUserNameAndPasswordFields.js
extra : rebase_source : b4a354231b85371144ccc0fff76f948ae0d09278
This patch moves all UA Widget calls to helper functions in Element.cpp. The helper function AttachAndSetUAShadowRoot sets the shadow root in a runnable, so that it is in the same order of NotifyUAWidget* runnables.
Differential Revision: https://phabricator.services.mozilla.com/D13479
--HG--
extra : moz-landing-system : lando
I missed the failure in browser_selectpopup_colors.js since it doesn't run on
Linux. Fix the getComputedStyle usage in that code by using
getDefaultComputedStyle, which is what it really wants.
Also, do a bit of cleanup while at it: uaBackgroundColor was unused, and uaColor
was wrong (we don't override the ua color of the <option> element, it just
inherits, so it's the same as the <select> color, and that's what we were
comparing it against anyway).
Differential Revision: https://phabricator.services.mozilla.com/D13956
This probably deserves a comment as of why it belongs to this bug.
This patch series caused a single, reproducible timeout on
browser_ext_themes_toolbars.js, where the transitionend event it awaits for
stops triggering.
I got fascinated by it and I decided to poke around it in rr instead of just
removing the await line, and here's what's going on.
In the previous implementation of _sanitizeCSSColor, we were not flushing style
because of the optimization bug 1363805 introduced (which wasn't supposed to
deal with out-of-document elements, but it accidentally did so).
In any case, the fact that we were not flushing style in _sanitizeCSSColor
caused us to flush style sometime later when the lwtheme attribute was already
set up, and thus the selector in here matched:
https://searchfox.org/mozilla-central/rev/cfaa5a1d48d6bc6552199e73004ecb05d0a9c921/browser/themes/shared/browser.inc.css#40
And thus caused the transition rule to apply at a time where the
background-color change happened.
Now we were flushing on getComputedStyle on every call, and in the most
inefficient way possible (changing a custom property on the root before each
property change, which causes us to restyle the whole document to propagate it
down to all descendants).
Furthermore, we were flushing style at a time where the lwtheme attribute
change had not yet happened, and thus when the background-color changed, there
was no transition rule applicable, and the transition didn't fire.
This patch changes LightweightThemeConsumer to avoid restyling the whole
document over and over.
Also, while at it I realized that you could fool the sanitizer with !important
in an experiment stylesheet or with other !important rule in the page really.
It's not clear why you'd do that, but it may be worth to just making that
function completely sound, so I did that and added a test for it.
Differential Revision: https://phabricator.services.mozilla.com/D13716
See D13472 for spec quotes and such. Other browsers don't allow
getting computed styles in disconnected subtrees and we agreed to follow suit
(it does make sense because when you're not on the flat tree it's not defined
what you're supposed to inherit from, specially in presence of Shadow DOM).
Also, it allows the style system to rely on the DOM being in a sane state.
Differential Revision: https://phabricator.services.mozilla.com/D13551
I missed the failure in browser_selectpopup_colors.js since it doesn't run on
Linux. Fix the getComputedStyle usage in that code by using
getDefaultComputedStyle, which is what it really wants.
Also, do a bit of cleanup while at it: uaBackgroundColor was unused, and uaColor
was wrong (we don't override the ua color of the <option> element, it just
inherits, so it's the same as the <select> color, and that's what we were
comparing it against anyway).
Differential Revision: https://phabricator.services.mozilla.com/D13956
This probably deserves a comment as of why it belongs to this bug.
This patch series caused a single, reproducible timeout on
browser_ext_themes_toolbars.js, where the transitionend event it awaits for
stops triggering.
I got fascinated by it and I decided to poke around it in rr instead of just
removing the await line, and here's what's going on.
In the previous implementation of _sanitizeCSSColor, we were not flushing style
because of the optimization bug 1363805 introduced (which wasn't supposed to
deal with out-of-document elements, but it accidentally did so).
In any case, the fact that we were not flushing style in _sanitizeCSSColor
caused us to flush style sometime later when the lwtheme attribute was already
set up, and thus the selector in here matched:
https://searchfox.org/mozilla-central/rev/cfaa5a1d48d6bc6552199e73004ecb05d0a9c921/browser/themes/shared/browser.inc.css#40
And thus caused the transition rule to apply at a time where the
background-color change happened.
Now we were flushing on getComputedStyle on every call, and in the most
inefficient way possible (changing a custom property on the root before each
property change, which causes us to restyle the whole document to propagate it
down to all descendants).
Furthermore, we were flushing style at a time where the lwtheme attribute
change had not yet happened, and thus when the background-color changed, there
was no transition rule applicable, and the transition didn't fire.
This patch changes LightweightThemeConsumer to avoid restyling the whole
document over and over.
Also, while at it I realized that you could fool the sanitizer with !important
in an experiment stylesheet or with other !important rule in the page really.
It's not clear why you'd do that, but it may be worth to just making that
function completely sound, so I did that and added a test for it.
Differential Revision: https://phabricator.services.mozilla.com/D13716
See D13472 for spec quotes and such. Other browsers don't allow
getting computed styles in disconnected subtrees and we agreed to follow suit
(it does make sense because when you're not on the flat tree it's not defined
what you're supposed to inherit from, specially in presence of Shadow DOM).
Also, it allows the style system to rely on the DOM being in a sane state.
Differential Revision: https://phabricator.services.mozilla.com/D13551
With same-compartment-realms, the Cu.import native is a cross-realm function so
we switch to its realm and ended up defining things on the wrong global.
Differential Revision: https://phabricator.services.mozilla.com/D13905
--HG--
extra : moz-landing-system : lando
An attribute for checking if the next gen local storage implementation is enabled is exposed via a new interface nsILocalStorageManager which should be used for any other local storage specific stuff.
This moves getting and setting the value of app.update.auto from nsUpdateService.js to UpdateUtils.jsm so nsUpdateService.js isn't loaded during startup
Changes the browser_policy_app_update_URL.js test to check the default pref for app.update.url since the default pref is read by app update
Fixes a NS_NOINTERFACE error in app update xpcshell tests for AppInfo not implementing nsIPlatformInfo
Differential Revision: https://phabricator.services.mozilla.com/D13285
--HG--
extra : moz-landing-system : lando
Currently, some "input" event dispatchers in our script dispatch "input" event
with UIEvent. This is completely wrong. For conforming to HTML spec, Event
is proper event. Additionally, for conforming to Input Events, InputEvent
is proper event only on <textarea> or <input> element which has a single line
editor.
For making us to maintain easier, this patch adds new API, "isInputEventTarget"
to MozEditableElement which returns true when "input" event dispatcher should
use InputEvent for the input element.
Finally, this makes some dispatchers use setUserInput() instead of
setting value and dispatching event by themselves. This also makes
us to maintain them easier.
Note that this does not touch "input" event dispatchers which dispatch events
only for chrome (such as URL bar, some pages in about: scheme) for making
this change safer as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D12247
--HG--
extra : moz-landing-system : lando
Move JSON dump loading and CanonicalJSON serialization to a worker to reduce impact on main thread
Differential Revision: https://phabricator.services.mozilla.com/D10064
--HG--
extra : moz-landing-system : lando
Move JSON dump loading and CanonicalJSON serialization to a worker to reduce impact on main thread
Differential Revision: https://phabricator.services.mozilla.com/D10064
--HG--
extra : moz-landing-system : lando
Since temporary permissions are only stored in the front-end side, we can't know whether we have
allowed page to autoplay or not without sending a request. Therefore, we want to notify the back-end
side when the temporary permissions changed.
Differential Revision: https://phabricator.services.mozilla.com/D7011
--HG--
extra : moz-landing-system : lando
Bug 1344926 integrated static themes more closely into the existing infra-
structure for lightweight themes and also intended the static theme's image data
to be persisted to disk as well.
While the headerURL image file is in fact successfully copied out of the
extension archive into the profile, the persist progress listener being used
isn't equipped to properly handle this case and therefore the success callback
is never executed.
As a result
- the callback passed to _persistImages in the LWTManager isn't executed,
either, although because setting the fallbackThemeData passes in an empty
callback anyway, no one noticed.
- the persist operation never actually completes, so subsequent calls to
currentThemeForDisplay() always return the original moz-extension:// image URI
and never the persisted file from the profile folder.
For Android we definitively require a working callback in order to be able to
forward the fixed-up theme data once the image data has been persisted, so the
persistProgressListener's logic is modified accordingly.
Additionally, because as far as the LWTManager is concerned, WE static themes
are only fallback themes and a call to LWTManager.currentTheme will therefore
never return a WE static theme, the LWTPersister's logic to check whether the
theme, whose files have just been successfully persisted, is still the current
theme, needs to be modified.
Differential Revision: https://phabricator.services.mozilla.com/D10729
--HG--
extra : source : 91b2a9224846ef9cc81f1afc9fcfcd1db278644b
extra : histedit_source : d8a47bba3563cb8eb0faf94a7c1f28ba2925d80c
See next commit for more info. The idea is to use E10SUtils.canLoadURIInRemoteType to detect
if a URI can load in a given E10SUtils process type. Having it to accept a nsIXULRuntime
process type, which will be mapped back to an E10SUtils process type, is unnecessary.
MozReview-Commit-ID: KeYkuRDyqXO
--HG--
extra : source : a8bba29ad2cb20239b87081f77cdf34249d3337b
extra : intermediate-source : 18f824674b76d87ed8cdaee516ad450c1c9b6496
extra : histedit_source : 3a0a8be23c1a5e749396d7aa8c7decbe152bc1db
We erroneously reset client IDs on Fennec to a canary client ID.
This is now detected and a new valid and random client ID is set.
This adds a new boolean attribute "wasCanary" to the `state.json` file
generated by ClientID.jsm.
Depends on D9544
Differential Revision: https://phabricator.services.mozilla.com/D9903
--HG--
extra : moz-landing-system : lando
Some events that actors need to listen to are chrome events which are not received by the listener in the window (even with mozSystemGroup = true).
Differential Revision: https://phabricator.services.mozilla.com/D8014
--HG--
extra : moz-landing-system : lando
This patch adds a messaging mechanism to actors that work like this:
If browser.fission.simulate is true, messages handled by ActorManagerChild will only be dispatched to an actor tied to a specific frame, specified either by its frameId (outerWindowId) or by its browsingContextId. Messages that lack the information about the destination frame will be considered meant for the top-level frame.
In addition, a sendMessage API is added to ActorChild that automatically adds the id information to the outbound message, making it easier for it to be handled in the parent.
The frameId support is to ease the transition of some code that is already using outerWindowIds. For new code, it is preferred to use the browsing context ids, together with bug 1496840
Differential Revision: https://phabricator.services.mozilla.com/D7933
--HG--
extra : moz-landing-system : lando
This fixes the addEventListener in ActorChild that I got wrong on bug 1490810, as it was still directly adding the events to the message manager, instead of going through the dispatcher (which can simulate the Fission process boundaries). ActorChild.addEventListener is meant for actors to add more events after they are constructed (that were not declared in nsBrowserGlue or ActorManagerParent)
Differential Revision: https://phabricator.services.mozilla.com/D7932
--HG--
extra : moz-landing-system : lando
This simply removes the content blocking section when TP is not enabled to avoid overpromising.
We may update this UI to alert the user that TP is off after the UX team comes back with a new design.
Differential Revision: https://phabricator.services.mozilla.com/D10071
--HG--
extra : rebase_source : 6cf70948a142309edf06da3a53874bde2d7372e5
See next commit for more info. The idea is to use E10SUtils.canLoadURIInRemoteType to detect
if a URI can load in a given E10SUtils process type. Having it to accept a nsIXULRuntime
process type, which will be mapped back to an E10SUtils process type, is unnecessary.
MozReview-Commit-ID: KeYkuRDyqXO
--HG--
extra : rebase_source : a3f94b45b96539a969d83e4c4c10ef6f16950fb3
extra : source : a8bba29ad2cb20239b87081f77cdf34249d3337b
Support for finding text in a page is now determined by a blacklist of locations, simplifying handling in multi-process mode and restoring the intended behavior.
Differential Revision: https://phabricator.services.mozilla.com/D8005
--HG--
extra : rebase_source : 129f3d4e3cdd3673251ed7a3cc58101dd3cb0c91
In case of loss of OS key store key, we should still allow users to go into the manage credit cards dialog and fill the numbers back in.
This is not the migration strategy, see Part III.
Differential Revision: https://phabricator.services.mozilla.com/D5083
--HG--
extra : rebase_source : dc710a2512b0d9b20e0fa74e641867525098eba2
extra : histedit_source : 4983a480565380ce4da6a0f099a5e4ae0e65797d
Given that the new store is always considered enabled, the not-enabled code
is now dead code. This patch removes them.
Differential Revision: https://phabricator.services.mozilla.com/D5717
--HG--
extra : rebase_source : d2940f77e26ba9f5c808eada5083df293d314214
extra : histedit_source : 29741eb6014489fcd179e90ee18ff876227baaf5
This patch morphs MasterPassword.jsm to OSKeyStore.jsm while keeping the same
API, as an adaptor between the API and the native API exposed as nsIOSKeyStore.idl.
Noted that OS Key Store has the concept of "recovery phrase" that we won't
be adopting here. The recovery phrase, together with our label, allow
the user to re-create the same key in OS key store.
Test case changes are needed because we have started asking for login in
places where we'll only do previously when "master password is enabled".
This also made some "when master password is enabled" tests invalid because
it is always considered enabled.
Some more test changes are needed simply because they previously rely on the
stable order of microtask resolutions (and the stable # of promises for a
specific operation). That has certainly changed with OSKeyStore.
The credit card form autofill is only enabled on Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D4498
--HG--
rename : browser/extensions/formautofill/MasterPassword.jsm => browser/extensions/formautofill/OSKeyStore.jsm
rename : browser/extensions/formautofill/test/browser/browser_creditCard_fill_master_password.js => browser/extensions/formautofill/test/browser/browser_creditCard_fill_cancel_login.js
extra : rebase_source : cabbd8cdec86e5b3965cf1c8b6e635b73b6c2095
extra : histedit_source : 65e71057104465553fefa1d0b293580efed53075
In case of loss of OS key store key, we should still allow users to go into the manage credit cards dialog and fill the numbers back in.
This is not the migration strategy, see Part III.
Differential Revision: https://phabricator.services.mozilla.com/D5083
--HG--
extra : moz-landing-system : lando
Given that the new store is always considered enabled, the not-enabled code
is now dead code. This patch removes them.
Differential Revision: https://phabricator.services.mozilla.com/D5717
--HG--
extra : moz-landing-system : lando
This patch morphs MasterPassword.jsm to OSKeyStore.jsm while keeping the same
API, as an adaptor between the API and the native API exposed as nsIOSKeyStore.idl.
Noted that OS Key Store has the concept of "recovery phrase" that we won't
be adopting here. The recovery phrase, together with our label, allow
the user to re-create the same key in OS key store.
Test case changes are needed because we have started asking for login in
places where we'll only do previously when "master password is enabled".
This also made some "when master password is enabled" tests invalid because
it is always considered enabled.
Some more test changes are needed simply because they previously rely on the
stable order of microtask resolutions (and the stable # of promises for a
specific operation). That has certainly changed with OSKeyStore.
The credit card form autofill is only enabled on Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D4498
--HG--
rename : browser/extensions/formautofill/MasterPassword.jsm => browser/extensions/formautofill/OSKeyStore.jsm
rename : browser/extensions/formautofill/test/browser/browser_creditCard_fill_master_password.js => browser/extensions/formautofill/test/browser/browser_creditCard_fill_cancel_login.js
extra : moz-landing-system : lando
* Change to isValidNumber to allow any number length in the range. This also removes 9 as a valid payment card number length
* Amend form autocomplete test for sensitive 9 digit numbers. We no longer consider them valid cc numbers, test for 19 digit numbers instead
* Fix intermittent issue in a session restore tests. It turns out Date.now().toString() can sometimes pass the Luhn algorithm and look like a valid credit card number. I believe this could lead to it being treated as sensitive data which is not saved and restored, failing the test
Differential Revision: https://phabricator.services.mozilla.com/D8271
--HG--
extra : moz-landing-system : lando
ProfileAge now returns a promise that resolves to an instance that has already
loaded its times.json. This makes multiple attempts to update data in times.json
safer.
Differential Revision: https://phabricator.services.mozilla.com/D8463
--HG--
extra : moz-landing-system : lando
* Change to isValidNumber to allow any number length in the range. This also removes 9 as a valid payment card number length
* Amend form autocomplete test for sensitive 9 digit numbers. We no longer consider them valid cc numbers, test for 19 digit numbers instead
* Fix intermittent issue in a session restore test. It turns out Date.now().toString() can sometimes pass the Luhn algorithm and look like a valid credit card number. I believe this could lead to it being treated as sensitive data which is not saved and restored, failing the test
Differential Revision: https://phabricator.services.mozilla.com/D8271
--HG--
extra : moz-landing-system : lando
Switching between menu options should maintain correct main action state when window sharing is requested.
Differential Revision: https://phabricator.services.mozilla.com/D7742
--HG--
extra : moz-landing-system : lando
For simplicity, we do not support remote-to-non-remote or non-remote-to-remote
nsIWebProgressListener persistence.
Differential Revision: https://phabricator.services.mozilla.com/D7936
--HG--
extra : moz-landing-system : lando
This patch removes linux64-jsdcov from the available builds on taskcluster along with any hacks used to run it. It also removes any 'coverage' entries that were added to skip tests.
Differential Revision: https://phabricator.services.mozilla.com/D7919
--HG--
extra : moz-landing-system : lando
This moves UAWidgetsChild.jsm from browser to toolkit so that
Fennec and Reftest could pick it up.
Differential Revision: https://phabricator.services.mozilla.com/D5085
--HG--
rename : browser/actors/UAWidgetsChild.jsm => toolkit/actors/UAWidgetsChild.jsm
extra : moz-landing-system : lando
If the pref browser.fission.simulate is true, the event dispatcher in ActorManagerChild will not dispatch events to actors that aren't associated with the same window as the event's target.
In addition, when that pref is on, the actors associated with sub-frames will have their content property bound to the correct content window, that might differ from the message manager's window (which is always related to the top level).
Then, in order to write Fission-compatible code, that specific actor will need to be declared with allFrames = true, meaning that it wants to be instantiated for every frame, and not just top-level ones
Differential Revision: https://phabricator.services.mozilla.com/D6358
--HG--
extra : moz-landing-system : lando
Pages that are whitelisted for displaying on about:about can be
autocompleted in the URL bar.
MozReview-Commit-ID: BYhWUImyiJH
Differential Revision: https://phabricator.services.mozilla.com/D3072
--HG--
extra : moz-landing-system : lando
have XHRs adjust content type of uploads per spec using the MIME Sniffing standard
Differential Revision: https://phabricator.services.mozilla.com/D5969
--HG--
extra : moz-landing-system : lando
Removing footerURL code , few of the lines are left , i am not sure how to delete them and what to use instead of them there.
Differential Revision: https://phabricator.services.mozilla.com/D5795
--HG--
extra : moz-landing-system : lando
Both nsISHEntry.URI and nsISHEntry isSubFrame are readonly, but also have a
setter. This is silly, so this patch removes the setter and makes them
modifiable.
The patch also renames nsISHEntry.setAsHistoryLoad() as setLoadTypeAsHistory(),
which makes it clearer that it modifies the loadType attribute.
--HG--
extra : rebase_source : 7772e2c1d90d4fd9f462f20c777d6eacc65801c5
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
This patch:
- removes GetTransactionAtIndex(), because getTransactionAtIndex() can be used
instead;
- renames a lot of things;
- updates some comments.
--HG--
extra : rebase_source : 845a1c1d5fe7f84eaa03db39a344d98fd5784afd
nsISHEntry.index is readonly, but if you pass `true` as getEntryAtIndex()'s
second argument, nsISHEntry.index will be modified. This is pretty gross.
This patch changes `index` so it's not readonly (because it's not!) and removes
getEntryAtIndex()'s second argument.
--HG--
extra : rebase_source : c519d77fcc1c3bda2f260b5888ce9cd0f6cfdab5
Because it's a wafer-thin wrapper around nsISHEntry that just complicates
things.
This patch leaves behind a combination of "entry" and "transaction"
terminology. I'll fix that in a subsequent patch.
--HG--
extra : rebase_source : ca15187447bf3d93c65ed3980ead5bca958471be
Automatic changes by ESLint, except for manual corrections for .xml files.
Differential Revision: https://phabricator.services.mozilla.com/D4439
--HG--
extra : moz-landing-system : lando
Two cases were hiding permanently failing tests. I've commented those out and
filed bug 1487431.
Differential Revision: https://phabricator.services.mozilla.com/D4680
--HG--
extra : rebase_source : 232fa6173de8844a9c47d59926ec8e39d0640ecd
- nsISHistoryInternal loses `rootTransaction`, and gains
GetTransactionAtIndex(). (The implementing class `nsSHistory` already
implemented a method by that method.)
- nsSHistory loses `mListRoot` in favour of `mTransactions`. It also loses
`mLength`, because `mTransactions` tracks the length itself.
- nsISHTransaction.{prev,next} are no longer needed.
- nsISHTransaction.create() is no longer needed, because all it does now is set
the SHEntry, and we can use SetSHEntry() for that.
Overall this deletes about 200 lines of code.
--HG--
extra : rebase_source : eac6334b653e04634baa86a0f4e3c8f07c06e560
This makes the about:privatebrowsing display "Content Blocking" instead
of "Tracking Protection" and makes the toggle flip the TP setting for PB
mode as well as the CB pref if it's turned off.
Differential Revision: https://phabricator.services.mozilla.com/D4395
--HG--
extra : moz-landing-system : lando
* Add cc-type as a valid field for credit card forms
* Add a select menu and new string for designating a card type in the add/edit form
* Enforce matching of cc-type to one of the list of supported network ids for Basic Card
* Expose the network ids list as CreditCard.SUPPORTED_TYPES
* Populate the cc-type options using a getCreditCardTypes util method passed into the EditCreditCard constructor
* Web Payment tests: verify cc-type picker is presented, populated as expected and selections received in the response
MozReview-Commit-ID: 9QyU1UwTRay
Differential Revision: https://phabricator.services.mozilla.com/D3830
--HG--
extra : rebase_source : 4ffffa97e845d727f1bfbcc88218992ed7d6c5a0
This makes it much easier to update existing consumers of
XPCOMUtils.enumerateCategoryEntries to use the category manager directly.
It also, unfortunately, requires updating existing category manager consumers
to use the Services getter in order to avoid ESLint errors.
Differential Revision: https://phabricator.services.mozilla.com/D4278
--HG--
extra : rebase_source : fb9fd9b21db80af472ff6250a2e9a35e8d538147
The AudibleAutoplayMediaOccurredObserver which I added in bug1476701 was incorrectly removed by bug1472491, it's used to notify audible autoplay event for the shield study and we should add it back.
Differential Revision: https://phabricator.services.mozilla.com/D3930
--HG--
extra : moz-landing-system : lando
nsSHEntry is the only class that instantiates those two interfaces, so the
separation is not useful. This lets us remove numerous pointless QIs.
--HG--
extra : rebase_source : 570b7ade669fb89a789184198bec9da186c5f1d3
This adds the basic framework for defining IPC actors which are lazily
instantiated for the appropriate frame loaders based on DOM events, message
manager messages, and observers. Actual actors are defined in follow-up
commits.
MozReview-Commit-ID: Jb6CWWW7v3v
--HG--
extra : rebase_source : 6c465c492ef423616346d70047c4fd4b074af303
This allows the JS to work in HTML documents, where whitespace is preserved. In XUL
documents, whitespace is ignored when parsing so text nodes are generally not returned.
The following changes were made, with manual cleanups as necessary (i.e. when firstChild actually
refers to a text node, or when firstChild is used in a loop to empty out an element):
firstChild->firstElementChild
lastChild->lastElementChild
nextSibling->nextElementSibling
previousSibling->previousElementSibling
childNodes->children
MozReview-Commit-ID: 95NQ8syBhYw
--HG--
extra : rebase_source : 186d805f7a2a56694dda9032aceac2dfe5424753
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : b4f0d4bf83c64851028c271d3fab3ebcb6fbcd3e
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : f0e8d229581ac5c0daa0e0454cb258746108e28d
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
All the C++ consumers already call the getter, so we can remove
nsIEditingSession from the docshell GetInterface method completely.
Differential Revision: https://phabricator.services.mozilla.com/D2668
--HG--
extra : moz-landing-system : lando
Add a build option that allows to relax the requirements in
SCOPE_APPLICATION and SCOPE_SYSTEM, individually or together, in an
opt-in manner.
--HG--
extra : rebase_source : ec6b317cca17493baa9cf72675e17a1309e35a94
While showing a doorhanger permisison prompt, if the user presses the ESC key
we call the secondary action callback, passing in whether any checkbox on
the popup notification was checked.
In the case of an autoplay-media permission prompt, we have a "remember"
checkbox, which is checked by default. So pressing ESC means the user will
remember a "block" result for the current site.
We believe that users don't expect pressing ESC to result in a remembered
decision, they expect pressing ESC to avoid making a decision. So we want to
ignore the checkbox when ESC is pressed for autoplay-media.
So this patch adds a new PopupNotification behaviour which reports the source
of event which caused the action callback to be called. This enables the ESC
key press to ignore storing a permission.
Note: the change here to not store a permission on ESC press applies to all
permissions, not just autoplay-media.
MozReview-Commit-ID: IUWFN8LG9VF
--HG--
extra : rebase_source : b004bc211177a7bfb6dcea563d75db9a6750b214
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
This is an optimization that reduces the memory usage of the registeredUrls list (as it will use shared data among all processes), and makes the Register/Unregister messages unecessary since the changes in sharedData are automatically propagated to all running processes.
The flush() is unfortunately needed to force the propagation in this case, otherwise it would propagate on the next idle tick, and that is not enough to make sure that the RemotePageManager works for the first about:newtab created when starting Firefox
MozReview-Commit-ID: JG3na0XXWA2
--HG--
extra : rebase_source : 1db486512363fc853293ea0ef35f0be8aac882e2
The language parameter of mozIPersonalDictionary is unused, so we should remove
this from parameter. Then, no one uses mLanguage member of mozHunspell now.
Differential Revision: https://phabricator.services.mozilla.com/D2349
--HG--
extra : moz-landing-system : lando
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : 9c400bed3c9d29a186fc987c9bd0ffceb37bfd94
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : fbfbcf7608efbfb35c9be4018ff0f4e70b2768d2
This also avoids us doing main thread sync io.
MozReview-Commit-ID: KR0p7eeu1sj
Differential Revision: https://phabricator.services.mozilla.com/D2117
--HG--
extra : moz-landing-system : lando
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : b15f75e39d04c8485b4eb63416fd1f1e4175fafe
getCssPath and getXPath will need to reuse the same logic as findCssSelector
to handle shadowDOM support.
This patch moves the methods next to findCssSelector, in toolkit's css-selector.js
to avoid duplicating logic between devtools/ and toolkit/
The content of the methods is stricltly the same, except for the Node global
not available in css-selector.js. Instead we use `ele.ownerGlobal.Node` here.
MozReview-Commit-ID: J0KuORWLUoO
--HG--
extra : rebase_source : 26a1801670e5554577f0f77b62667527f7b497bb
This is a follow-up to the changes made in Bug 1449968.
It makes more sense to preserve getRootBindingParent from shadowdom
logic because:
- getBindingParent for a node in a shadow root returns the host
component, so it was weird that getRootBindingParent would
return a node lower in the hierarchy
- getRootBindingParent is currently duplicated between toolkit
and devtools, and this made the implementations inconsistent
MozReview-Commit-ID: LNVEY8TzUKI
--HG--
extra : rebase_source : 4ae908bc9dfb2bbc951e9fda39049eb150a1df86
getCssPath and getXPath will need to reuse the same logic as findCssSelector
to handle shadowDOM support.
This patch moves the methods next to findCssSelector, in toolkit's css-selector.js
to avoid duplicating logic between devtools/ and toolkit/
The content of the methods is stricltly the same, except for the Node global
not available in css-selector.js. Instead we use `ele.ownerGlobal.Node` here.
MozReview-Commit-ID: J0KuORWLUoO
--HG--
extra : rebase_source : d6fab834be4fb6ad9ba1cd73acf960cf0fe0d4d5
This is a follow-up to the changes made in Bug 1449968.
It makes more sense to preserve getRootBindingParent from shadowdom
logic because:
- getBindingParent for a node in a shadow root returns the host
component, so it was weird that getRootBindingParent would
return a node lower in the hierarchy
- getRootBindingParent is currently duplicated between toolkit
and devtools, and this made the implementations inconsistent
MozReview-Commit-ID: LNVEY8TzUKI
--HG--
extra : rebase_source : 4ae908bc9dfb2bbc951e9fda39049eb150a1df86
This lets us use Services.xulStore instead of requiring
Cc["@mozilla.org/xul/xulstore;1"].getService(Ci.nsIXULStore);
MozReview-Commit-ID: 2eXifCPhlGs
--HG--
extra : rebase_source : c65b9395cc192d05d1a348cfbf92f7f59d41dc8f
We have 2 different LoadType enums with two different values, which
have to be converted between depending on whether we're going to/from
LoadInfo/nsISHEntry/etc. We should be able to just use the same enum
everywhere and not have to deal with conversion, especially since we
don't have any type safety around the enum.
MozReview-Commit-ID: 2t9vVGLpOte
The test was incorrect and the timestamp should be milliseconds, not microseconds.
MozReview-Commit-ID: 2d79r6PHH4Z
--HG--
extra : rebase_source : edd97899f0646f2cae2fbf119206ec470a6b97a0
We will apply the URI_CAN_LOAD_IN_PRIVILEGED_CHILD flag to Activity Stream about: pages instead of hardcoding the URLs in a Set.
MozReview-Commit-ID: F6AGmsKs1SR
--HG--
extra : rebase_source : e0435776b7bd390a2a62190ba6c72d4d312538d1
A hidden preference matching "browser.download.manager.alertOnEXEOpen" is kept, but is renamed in order to recover cases where the checkbox was used accidentally.
This also cleans up duplicate unused strings in the "browser" folder.
MozReview-Commit-ID: GyccRiyoVGs
--HG--
extra : rebase_source : 8211ad1c94894535b2b98dde0549d7ab52a879b0