The original patch had caused some assertions so I rewrote it. This now puts
all untracked top-level requests on the new list while they are being compiled
so handles preload requests too.
Differential Revision: https://phabricator.services.mozilla.com/D119386
There are parse tasks present when the JS engine is being shut down that have
finished but haven't had their results collected by the embedding. This
shouldn't happen, and I think it's happening here because we're leaking a
JSRuntime (we cancel these when we shut down a runtime).
There's a comment that says this isn't necessary but cancelling outstanding
compile requests in ScriptLoader::Destroy fixes this problem on try. I don't
understand well enough to know what's going wrong with the current approach but
this fixes both the crash and the leak.
Differential Revision: https://phabricator.services.mozilla.com/D119315
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
Port Bug 1601256 to dialogs/permissions.js. Unfortunately these files forked even though they are very similar. This leads to bugs like this being introduced.
Differential Revision: https://phabricator.services.mozilla.com/D118888
Removing the following vars from common.inc.css
- `--in-content-button-border-radius`
- `--in-content-button-horizontal-padding`
- `--in-content-button-vertical-padding`
Differential Revision: https://phabricator.services.mozilla.com/D119190
Port Bug 1601256 to dialogs/permissions.js. Unfortunately these files forked even though they are very similar. This leads to bugs like this being introduced.
Differential Revision: https://phabricator.services.mozilla.com/D118888
In Bug 1717600 we introduced the monitoring of performance for ff using clang-trunk toolchain,
we did this for mozilla-central and mozilla-beta, but after analyzing further the problem we
don't have to run it on beta since we can compare the graph of ff built with clang-trunk against
clang official and if the slopes of the two graphs have the same degrees this means that there
is no perf regression caused.
Differential Revision: https://phabricator.services.mozilla.com/D118814
The mozSubdialogReady was being set inside of sanitize.xhtml in
its load event handler, which would be scheduled to run AFTER the
SubDialog _onLoad handler (which is what awaits mozSubdialogReady).
The only reason this wasn't more obvious is because the first time
the dialog is opened, the SubDialog _onLoad handler awaits
translation of the document, which gives sanitize.xhtml a chance
to run its load event handler and set the mozSubdialogReady.
Subsequent opens of the dialog wouldn't need to re-run translation
due to document caching, and so the mozSubdialogReady wouldn't
be waited for, resulting in incorrect dialog layout.
Depends on D119329
Differential Revision: https://phabricator.services.mozilla.com/D119330
These handlers and markup were only ever relevant when opening the
dialog in an old-style modal. Now that we're opening the dialog as
a SubDialog, these conditions can be cleaned up.
Depends on D117567
Differential Revision: https://phabricator.services.mozilla.com/D119329
We enable this mitigation by default because:
- The alternate UX is about:blank or corrupted content. That's never good.
- We want to make sure that our test coverage handles this mitigation because
it's want we want to ship.
However, we do explicitly disable it for all ServiceWorker WPT's via
`__dir__.ini` directive at the root of the service-workers test tree.
This is motivated by the
`/service-workers/service-worker/update-recovery.https.html` test which
intentionally tests a broken ServiceWorker being able to be updated. It
explicitly tests that the intercepted broken iframe shouldn't successfully
load, but our mitigation makes it load, which breaks the test.
Depends on D111845
Differential Revision: https://phabricator.services.mozilla.com/D111993
This test was disabled for parent-intercept by bug 1470266 when parent
intercept was still in-progress. Since the landing of worker remoting
and related cleanups, I think we're generally good here and I was able
to locally get this to pass under "--verify". Also, this test is
actively relevant to the fixes we're making here on bug 1503072.
Differential Revision: https://phabricator.services.mozilla.com/D111844
The crash is caused by the infinite loop to delete unnecessary ranges.
The `i` is always equals or larger than `0` due to unsigned. So, if
`Selection::RangeCount()` is `0`, `i` can be `UINT32_MAX`.
Instead, we can use `nsTArray<RefPtr<RangeItem>>::TruncateLength()`.
Differential Revision: https://phabricator.services.mozilla.com/D119564
Until fixing bug 1686012, clipboard in the headless mode does not support
"text/html" flavor. Therefore, the `waitForClipboard` in the test does not
get expected value as `aData` in the first callback.
So, it should request `text/unicode` in the headless mode.
Depends on D119483
Differential Revision: https://phabricator.services.mozilla.com/D119484
With the change of bug 1716863, it retrieves editing host, but it's `nullptr`
if there is no `<body>` element in XHTML document. The root cause should be
fixed in bug 1697989, but for now, we should allow it only in XHTML document
for safer regression fix.
Differential Revision: https://phabricator.services.mozilla.com/D119483
On some systems, uint_fast8_t may be as big as size_t! So the `static_assert(sizeof(aIndex) < sizeof(size_t))` could fail there. The better test here is to check for the expected type (uint_fast8_t).
Now, since uint_fast8_t can be bigger than 8 bits, we may as well choose it for variant sizes greater than 255, up to UINT_FAST8_MAX.
(The added parentheses help clang-format distinguish '<' for tests vs for templates.)
Differential Revision: https://phabricator.services.mozilla.com/D119574