Filters out empty categories when ChromeUtils.requestPerformanceMetrics() is called.
This test also:
- adds more test coverage
- uses the worker windowId when it has no linked window.
- properly walk to the worker parent
MozReview-Commit-ID: 3UH9a0UtVmx
--HG--
extra : rebase_source : 337b95466c7e7a30f881e881358d3b8d290f8f5b
We're changing the counters behavior since they are not notifications anymore.
In the new behavior they don't get reset when they are retrieved,
so we can have several consumers via the promise.
If the values overflow, we let the wrapping occur (unsigned values).
MozReview-Commit-ID: 1adkszScYo4
--HG--
extra : rebase_source : cd554ad4cfa643b09f75bb07e38b5d35e08cf470
- modifies how we get the top window id, adds isTopLevel
- renames pwid to windowId, worker to isWorker
- removes the wid field
- uses the url in case the host is empty
It also fixes PerformanceInfoDictionary.host type
MozReview-Commit-ID: 4AzO3UnJ2LM
--HG--
extra : rebase_source : 5dee8a650064fd45e7a9e694c2593d517f74d766
This ChromeUtils API now returns a promise that gets resolved once all the data
has been collected via IPDL and the main process. The existing notification
design and its related XPCOM classes are removed.
MozReview-Commit-ID: CYKukBOC8yh
--HG--
extra : rebase_source : 1e27524726ace0bfed5297d48af8be268c5b4945
The idea with this patch is that style code will first call
InlineStyleDeclarationWillChange before style declaration has changed, and SetInlineStyleDeclaration once it has changed.
In order to be able to report old attribute value, InlineStyleDeclarationWillChange reads the value and also calls AttributeWillChange (so that DOMMutationObserser can grab the old value). Later SetInlineStyleDeclaration passes the old value to
SetAttrAndNotify so that mutation events and attributeChanged callbacks are handled correctly.
Because of performance, declaration can't be cloned for reading the old value. And that is why the recently-added callback is used to detect when declaration is about to change (bug 1466963 and followup bug 1468665).
To keep the expected existing behavior, even if declaration isn't changed, but just a new declaration was created (since there wasn't any), we need to still run all these
willchange/set calls. That is when the code has 'if (created)' checks.
Since there are several declaration implementation and only nsDOMCSSAttributeDeclaration needs the about-to-change callback, GetPropertyChangeClosure is the one to initialize the callback closure, and the struct which is then passes as data to the closure.
Apparently we lost mutation event testing on style attribute when the pref was added, so test_style_attr_listener.html is modified to test both pref values.
--HG--
extra : rebase_source : 9e605d43f22e650ac3912fbfb41abb8d5a2a0c8f
Now uses StaticPrefs instead of DOMPrefs, and how we count dispatches for Workers.
MozReview-Commit-ID: DTumwcI5bG
--HG--
extra : rebase_source : 0cf5312e714fb260c01df647b2cd1fcc28ffc415
Generalizes NetworkActivity so it can be used for sockets but also disk files.
The host/port data becomes a single location string prefixed with socket://
or file:// and we're not using the FD as the identifier anymore.
IOActivityMonitor is now used in three places:
- nsFileStreams for plain files
- TelemetryVFS for sqlite files
- nsSocketTransport & nsUDPSocket for UDP & TCP sockets
MozReview-Commit-ID: GNu5o400PaV
--HG--
rename : netwerk/base/NetworkActivityMonitor.cpp => netwerk/base/IOActivityMonitor.cpp
rename : netwerk/base/NetworkActivityMonitor.h => netwerk/base/IOActivityMonitor.h
rename : netwerk/base/nsINetworkActivityData.idl => netwerk/base/nsIIOActivityData.idl
extra : rebase_source : 55a1c51b261ffbe16f88671d55445d1b0d9106b6
Disable NetworkGeolocationProvider.js request cache for test cases that change the geo.wifi.uri. The cache does not remember from which location service the cached request came from and we expect different results when we change the provider URL (geo.wifi.uri).
MozReview-Commit-ID: 7SbhBOkek4H
--HG--
extra : rebase_source : 2ce410953eaa76e259472397163c304621449a61
extra : source : 058acdfc4d995120d0d2ed34c60b6151ce670d63
We expose the relevant APIs on textarea and input elements anyway
(chromeonly). The QIs will throw on a non-input or non-textarea element, but
none of these consumers expect that to happen.
These tests ensures the feature interacts well with our setup in XUL.
They work when bug 1460815 was implemented so they sits in its own changeset.
MozReview-Commit-ID: Ia08tAewZyN
--HG--
extra : rebase_source : b7ee577efc5cb5cc573cb07df2cfeeb0a9c88699
extra : source : c142c5c69a04c86f192526f8324a0278cbb721ba
nsContentUtils::NS_NewXULOrHTMLElement will call into
CustomElementRegisty::RegisterCallbackUpgradeElement, which keeps
the newly created element, allowing RunCustomElementCreationCallback
to upgrade them after the callback runs.
It is unclear if this changes the order of constructor executions,
but even so it should not affact our use case.
MozReview-Commit-ID: LWTn7B35aBv
--HG--
extra : rebase_source : 15382431f34dd887c14142ff47337e8d1eec74ef
extra : source : 47058a61951c2974514e41e316e5370cfa4f9d8b
This would help in the case where it is safe to run script in-place and
the CustomElementDefinition is available before the function exits.
This fixes the tests changed.
MozReview-Commit-ID: Ays91W94WZm
--HG--
extra : rebase_source : 6b0f1f90de9a6bfd7db577f1fb0e76564c3627e7
extra : source : 47c62a1e2f268e1be24c3fddfc006c3ad45ba4ac