Almost none of the prompts that we are currently showing still get dismissed, which messes up our
measurements in this probe. Most of them are persistent now, which means that we should record when
they get removed instead of dismissed to receive meaningful data. This patch does that.
Differential Revision: https://phabricator.services.mozilla.com/D26944
--HG--
extra : moz-landing-system : lando
Includes an otherwise-automated change to test_jsctypes.js that required an
expectation change in test_ctypes.xul.
Differential Revision: https://phabricator.services.mozilla.com/D27449
--HG--
extra : moz-landing-system : lando
Result of running:
$ mach eslint -funix toolkit/ | sed -Ee 's/:.+//' - | xargs sed -E \
-e 's/throw ((["`])[^"]+\2);/throw new Error(\1);/g' \
-e 's/throw ((["`])[^"]+\2 \+ [^ ";]+);/throw new Error(\1);/g' \
-e 's/throw \(/throw new Error(/g' -i
...and then reverting a couple of places where comments were touched,
as well as changes to toolkit/components/ctypes/tests/unit/test_jsctypes.js
that required expectation changes to
toolkit/components/ctypes/tests/chrome/test_ctypes.xul
Differential Revision: https://phabricator.services.mozilla.com/D27448
--HG--
extra : moz-landing-system : lando
Since we rarely touch this code, I took the liberty of changing this to a JS class
and fix the contrast ratio calculations to actually conform to the WCAG spec,
instead of using arbitrary constants.
I changed the `isBright` getter to `useBrightText`, because that is more apt;
we're usually looking for an answer to 'should I use white text on this background?',
instead of looking for an arbitrary threshold to classify a color as being bright.
I updated the tests to cover more of this and clarified the assertion messages as
well.
Differential Revision: https://phabricator.services.mozilla.com/D26097
--HG--
extra : moz-landing-system : lando
We do not need to handle onProgressChange64 notifications since the TabChild's
web progress events are filtered through an nsBrowserStatusFilter, which
truncates onProgresChange64 event values to 32-bit integers and then calls
onProgressChange.
Differential Revision: https://phabricator.services.mozilla.com/D25649
--HG--
extra : moz-landing-system : lando
Now that we have access to the RemoteWebProgress from the TabParent and can
construct RemoteWebProgress and RemoteWebProgressRequests in C++, we can
reconstruct the RemoteWebProgress and RemoteWebProgressRequest in the TabParent
instead of RemoteWebProgressManager. This improves the API for nsIBrowser and
RemoteWebProgressManager, removing the need for the
`callWebProgressContentBlockingEventListeners` method in both. It also means we
won't need to implement `callWebProgress*Listeners` for methods on nsIBrowser
and RemoteWebProgressManager for all other nsIWebProgress events.
Differential Revision: https://phabricator.services.mozilla.com/D24942
--HG--
extra : moz-landing-system : lando
The RemoteWebProgressManager is now implemented in terms of a
nsIWebProgressListener. This paves the way for reconstructing the
nsIWebProgress and nsIRequest passed to the event handlers in C++ instead of in
JS and will alllow for a cleaner overall design.
While here, I also cleaned up RemoteWebProgressManager to use the class
syntactic sugar.
Differential Revision: https://phabricator.services.mozilla.com/D24941
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
It only works with "persisted" theme images, which no longer exist.
Differential Revision: https://phabricator.services.mozilla.com/D25451
--HG--
extra : rebase_source : 8d32e4ceb48ec8bde68e8b42dcf4e2f11c9d60fd
extra : histedit_source : 0bcbae928b6e1517eace567d1e00afc60321ea3c
Some extensions want to implement about: pages and we want those pages to be loaded in the extension process, not in the web content process, so that:
1) a compromised web process won't get access to the about: page content
2) the extension page can use all the APIs that extension pages normally get, instead of only content script APIs.
Post-Fission we will need to know which extension process to choose.
Differential Revision: https://phabricator.services.mozilla.com/D24989
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
When an extension requests access to the request body of a request,
`nsConverterInputStream` is used to parse the input streams that make up
a request body. These input streams are later (re)used to upload the
form data to the original destination (server).
`nsConverterInputStream`'s destructor does however close the input
streams, which results in data loss when the object is garbage-collected
before the upload completes.
This patch fixes the issue by explicitly nulling the underlying stream
before returning from the form parser.
Differential Revision: https://phabricator.services.mozilla.com/D24539
--HG--
extra : moz-landing-system : lando
This commit wraps just enough of the mozStorage API to support the
bookmarks mirror. It's not complete: for example, there's no way
to open, clone, or close a connection, because the mirror handles
that from JS. The wrapper also omits shutdown blocking and retrying on
`SQLITE_BUSY`.
This commit also changes the behavior of sync and async mozStorage
connections. Async (`mozIStorageAsyncConnection`) methods may be called
from any thread on any connection. Sync (`mozIStorageConnection`)
methods may be called from any thread on a sync connection, and from
background threads on an async connection. All connections now QI
to `mozIStorageConnection`, but attempting to call a sync method on
an async connection from the main thread throws.
Finally, this commit exposes an `OpenedConnection::unsafeRawConnection`
getter in Sqlite.jsm, for JS code to access the underlying connection.
Differential Revision: https://phabricator.services.mozilla.com/D20073
--HG--
extra : moz-landing-system : lando
Replaced instances of callers in both C++ and JS files to query the state from the principal directly.
Differential Revision: https://phabricator.services.mozilla.com/D22532
--HG--
extra : moz-landing-system : lando
Otherwise you see font changes when hovering, which is not really desirable.
Differential Revision: https://phabricator.services.mozilla.com/D24116
--HG--
extra : moz-landing-system : lando
Otherwise you see font changes when hovering, which is not really desirable.
Differential Revision: https://phabricator.services.mozilla.com/D24116
--HG--
extra : moz-landing-system : lando
This centralizes the checks for system shortcuts into ShortcutUtils.jsm, so
they can be checked for in the add-on shortcut assignment UI. It also
introduces a mechanism for skipping the system event handler if it is already
being handled by the shortcuts UI.
Differential Revision: https://phabricator.services.mozilla.com/D17586
--HG--
extra : moz-landing-system : lando
This renames the pref to the pattern chosen for all of the Fission work, and also breaks
down the pref into two separate ones to have a more fine-grained control of the simulation.
Differential Revision: https://phabricator.services.mozilla.com/D22579
--HG--
extra : moz-landing-system : lando
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
Robert Helmer
Coroiu Cristina
Myk Melez
Razvan Maries
Johann Hofmann
Rob Wu
Ian Moody
Brian Grinstead
Felipe Gomes
Mike Conley
meandave
Mike de Boer
Barret Rennie
Andreea Pavel
Sebastian Hengst
Tim Nguyen
Eden Chuang
Kris Maglione
Liang-Heng Chen
Mark Banner
Christoph Kerschbaumer
Matthew Noorenberghe
Cosmin Sabou
monmanuela
Lina Cambridge
sakshaat
Gijs Kruitbosch
Adam Gashlin
Emilio Cobos Álvarez
Brindusan Cristian
Thomas Wisniewski
Alex Gaynor
Gurzau Raul
Mark Striemer
Sylvestre Ledru
Ciure Andrei
Brad Werth
Alphan Chen
Tarek Ziadé
Marco Bonardo
Boris Zbarsky
Jonathan Kingston
Chris Pearce
Dão Gottwald
Dorel Luca
ui.manish
Magnus Melin
Narcis Beleuzu
Csoregi Natalia
Valentin Gosu
Nika Layzell
Bogdan Tara
Thomas Nguyen
shindli
arthur.iakab
Noemi Erli
Neil Deakin
Masayuki Nakano
edward.i.wu
Dave Townsend
Paolo Amadini
Ehsan Akhgari
Andreas Tolfsen
Aaron Klotz
Andrew Swan
Zibi Braniecki
alwu
Jared Wein
Timothy Guan-tin Chien
Makoto Kato
Jan de Mooij
Matt Howell
Shane Caraveo
Botond Ballo
Jan Varga
Robert Strong
Tom Schuster
Mathieu Leplatre
Jan Henning
vinoth