Differential Revision: https://phabricator.services.mozilla.com/D176949

Bug 1819570 - P5 Let netmonitor to watch stack trace events on nsIWorkerChannleInfo. r=jdescottes,devtools-reviewers

Depends on D174443

Differential Revision: https://phabricator.services.mozilla.com/D174444

After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor watches channels and NetEvents, stack traces are only caught in the content process.
That means PFetch should notify the netmonitor about the stack trace of the fetch at the proper moment.

In original fetch steps, FetchDriver would notify the netmonitor the fetch stack trace at
https://searchfox.org/mozilla-central/rev/cdddec7fd690700efa4d6b48532cf70155e0386b/dom/fetch/FetchDriver.cpp#834

When PFetch is enabled, PFetch needs also to propagate this notification back to the content process.

Depends on D174442

Differential Revision: https://phabricator.services.mozilla.com/D174443

Bug 1819570 - P3 using nsILoadInfo.WorkerAssociatedBrowsingContext for netmonitor. r=jdescottes,devtools-reviewers

After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor also watches the channels in the parent process, the created channel still loses the BrowsingContext information for netmonitor to connect the network event and the channel.

Depends on D174441

Differential Revision: https://phabricator.services.mozilla.com/D174442

Bug 1819570 - P2 Save worker's associated BrowsingContextID in channel's LoadInfo for the netmonitor. r=necko-reviewers,valentin

After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor also watches the channels in the parent process, the created channel still loses the BrowsingContext information for netmonitor to connect the network event and the channel.

In P1, https://phabricator.services.mozilla.com/D174249, we propagate the BrowsingContext ID through PFetch.
In this patch, we need to save it in channel's LoadInfo for netmonitor.

In order not to confuse with nsILoadInfo's BrowsingContextID, we create a new attribute WorkerAssociatedBrowsingContextID in nsILoadInfo.

Depends on D174249

Differential Revision: https://phabricator.services.mozilla.com/D174441

Bug 1819570 - P1 Propagate worker's assocaited BrowsingContextID through PFetch to the parent process. r=asuth

After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor also watches the channels in the parent process, the created channel still loses the BrowsingContext information for netmonitor to connect the network event and the channel.

This patch is the first part to propagte the worker's associated BrowsingContextID to the parent process through PFetch.

Differential Revision: https://phabricator.services.mozilla.com/D174249

Differential Revision: https://phabricator.services.mozilla.com/D176980

1) This patch cleanups the styling for blackboxing
- Ignored sources in the source tree are colored out and the icoon colors are consistent.
- Source content for ignored sources are also colored out.
- Ignored lines are colored out.
- The tab content for ignored sources are also abit lighter.

2) Also added tests to assert the lines in the sources are styled correcty
Thanks

Differential Revision: https://phabricator.services.mozilla.com/D173688

Bug 1824698 - [devtools] Update blackbox context menu labels after a blackbox r=ochameau,devtools-reviewers

Differential Revision: https://phabricator.services.mozilla.com/D174391

Bug 1824698 - [devtools] Add tests for all blackbox context menu items r=devtools-reviewers,ochameau

Tests the blackbox context menu items on the Editor, Editor Gutter and the Source Tree.

Differential Revision: https://phabricator.services.mozilla.com/D173686

Bug 1677844 - Let getAnimations() return scroll animations with null timeline. r=webidl,smaug,emilio

This is a tentative way to avoid any timeout in WPT because other
brower vendors may expect getAnimations() works for scroll animations.

The original implementation is error-prone because the user can use the
declarative way to create a CSS animation associated with the document-timeline,
and then changes animation-timeline property to any other scroll-timeline.
If the user calls getAnimations() before changing its style, we still expose
the Animation objects in JS and may crash or have other unexpected bahaviors
if the user tries to access Animation.timeline.

Besides, another benefit of this patch is that we can use other Web Animation
APIs for scroll animations in WPT, e.g. Animation.ready.

Differential Revision: https://phabricator.services.mozilla.com/D176966

Differential Revision: https://phabricator.services.mozilla.com/D176165

Backed out 6 changesets (bug 1825611, bug 1825411, bug 1828373) for failures on /browser_general.js. CLOSED TREE

Backed out changeset fa9772a45927 (bug 1825411)
Backed out changeset 51f495933300 (bug 1828373)
Backed out changeset 74462e3c7265 (bug 1825611)
Backed out changeset 683910281b5d (bug 1825611)
Backed out changeset 7e2ffdd02a98 (bug 1825611)
Backed out changeset 920bae37ff3e (bug 1825611)

Backed out 13 changesets (bug 1831040, bug 1829814, bug 1831046, bug 1831039, bug 1781201, bug 1829819, bug 1830887) for causing failures on test_upgrade_add_index.html. CLOSED TREE

Backed out changeset 0c3955157c7b (bug 1830887)
Backed out changeset 4f0b25db66d8 (bug 1831040)
Backed out changeset c503469bc048 (bug 1829814)
Backed out changeset 1a3dbef50207 (bug 1829819)
Backed out changeset 2c78a126281e (bug 1831046)
Backed out changeset 37aede27e09d (bug 1831039)
Backed out changeset bafee1f02404 (bug 1781201)
Backed out changeset 11c291dd3fb0 (bug 1781201)
Backed out changeset 2b8747b30bba (bug 1781201)
Backed out changeset 2b8e694fbfb9 (bug 1781201)
Backed out changeset e4ac26a5b071 (bug 1781201)
Backed out changeset a3ae636a90fe (bug 1781201)
Backed out changeset 236d1112bc5b (bug 1781201)

Differential Revision: https://phabricator.services.mozilla.com/D176093

Differential Revision: https://phabricator.services.mozilla.com/D176202

Differential Revision: https://phabricator.services.mozilla.com/D175196

Differential Revision: https://phabricator.services.mozilla.com/D175195

Differential Revision: https://phabricator.services.mozilla.com/D175194

Differential Revision: https://phabricator.services.mozilla.com/D175193

Differential Revision: https://phabricator.services.mozilla.com/D177095

Backed out changeset 8700c08f79f5 (bug 1828496)
Backed out changeset 02b78967c120 (bug 1828496)
Backed out changeset 7fa70275b7b1 (bug 1828496)
Backed out changeset bb6078e71f86 (bug 1828496)
Backed out changeset bfe814423962 (bug 1828496)
Backed out changeset fe7b04fa7511 (bug 1828496)
Backed out changeset 3d940e8bdb54 (bug 1828496)
Backed out changeset ff9e9c9054cc (bug 1828496)
Backed out changeset 5ec1344315a8 (bug 1828496)
Backed out changeset 8a6d13c9e6d2 (bug 1828496)

Differential Revision: https://phabricator.services.mozilla.com/D176884

Differential Revision: https://phabricator.services.mozilla.com/D177097

Differential Revision: https://phabricator.services.mozilla.com/D177099

This bypasses a very confusing issue where someone, somewhere seems to be
assuming that sizeof(JSRuntime) fits in a uint16_t. Or something like that.
Just adding dead space to it to push it over that boundary causes a leak
in a test. In any case, this works us toward something we might want to do
anyway, which is to lazily instantiate the MegamorphicSetPropCache in order
to save memory when it's not used. I didn't do the same change for the
MegamorphicCache (the get-handling one), because it is accessed from C++
even in hot cache hit paths, where obviously we can't bake pointers to it
into the binary, so there's a slightly plausible case that the extra
pointer dereference could matter.

Differential Revision: https://phabricator.services.mozilla.com/D177053

Differential Revision: https://phabricator.services.mozilla.com/D176448

Differential Revision: https://phabricator.services.mozilla.com/D176430

This is pretty hard to hit. I actually wasn't able to make a cleaner testcase
than the one I edited, which needs JS_GC_ZEAL=IncrementalMultipleSlices to
get hit. In any case, this is an existing correctness issue with megamorphic
SetElem in Ion, and becomes an issue with megamorphic SetProp with the patch
stack under this.

Differential Revision: https://phabricator.services.mozilla.com/D176429

Differential Revision: https://phabricator.services.mozilla.com/D176110

Differential Revision: https://phabricator.services.mozilla.com/D175682

Differential Revision: https://phabricator.services.mozilla.com/D175681

Differential Revision: https://phabricator.services.mozilla.com/D175680

Differential Revision: https://phabricator.services.mozilla.com/D175679

Differential Revision: https://phabricator.services.mozilla.com/D175678

Depends on D176881

Differential Revision: https://phabricator.services.mozilla.com/D177082

Differential Revision: https://phabricator.services.mozilla.com/D176196

Differential Revision: https://phabricator.services.mozilla.com/D176195

Backed out changeset d59210a65575 (bug 1482983) for failures on test_ext_webrequest_frameId.html. CLOSED TREE

This finally uses the storage origin for anything which goes to disk.

Differential Revision: https://phabricator.services.mozilla.com/D176881