According to step 15 of [1], request’s destination is used in an
implementation-defined manner to set the internal priority but we
currently always use the preferences corresponding to the adjustments
of the global fetch API.
This patch handle destinations corresponding to CSP directives
"font-src", "script-src", "style-src", "img-src" and "media-src" [2]
specially by respectively using the adjustment preferences named
"link-preload-font", "link-preload-script", "link-preload-style"
"images" and a new preference "media".
Special handling of these destinations is motivated by the fact that
they are mentioned explicitly on [3]. For "media" we choose preferences
following the suggestions from that article (i.e. media is low
priority). However, for now we don't change the default value and make
sure fetchpriority=high/low preserves the invariants tested by
fetchpriority-adjustments.html
[1] https://fetch.spec.whatwg.org/#concept-fetch
[2] https://fetch.spec.whatwg.org/#destination-table
[3] https://web.dev/articles/fetch-priority?hl=en#browser_priority_and_fetchpriority
Differential Revision: https://phabricator.services.mozilla.com/D208467
According to step 15 of [1], request’s destination is used in an
implementation-defined manner to set the internal priority but we
currently always use the preferences corresponding to the adjustments
of the global fetch API.
This patch handle destinations corresponding to CSP directives
"font-src", "script-src", "style-src", "img-src" and "media-src" [2]
specially by respectively using the adjustment preferences named
"link-preload-font", "link-preload-script", "link-preload-style"
"images" and a new preference "media".
Special handling of these destinations is motivated by the fact that
they are mentioned explicitly on [3]. For "media" we choose preferences
following the suggestions from that article (i.e. media is low
priority). However, for now we don't change the default value and make
sure fetchpriority=high/low preserves the invariants tested by
fetchpriority-adjustments.html
[1] https://fetch.spec.whatwg.org/#concept-fetch
[2] https://fetch.spec.whatwg.org/#destination-table
[3] https://web.dev/articles/fetch-priority?hl=en#browser_priority_and_fetchpriority
Differential Revision: https://phabricator.services.mozilla.com/D208467
This uses the warn macro for promotion errors. It's not clear this will
be useful for web authors, but hopefully it's useful for Firefox
developers.
This has the potential to be very spammy. I need ideas on how to limit
the reporting to new or interesting errors.
Differential Revision: https://phabricator.services.mozilla.com/D212340
Media Capabilities has been shipped as a standard feature long enough,
it's no need to guard it by the preference anymore.
Differential Revision: https://phabricator.services.mozilla.com/D212322
This helps accumulate RDP packets related to resources being available/updated/destroyed
and emit less and larger RDP packets instead or more and smaller.
This appears to reduce the overhead of DevTools transport and JSWindowActor layers.
The issue in browser_markup_events_toggle.js is interesting.
It highlights that a resource notified before a call to WatcherActor.watchResources,
may be emitted during the call to watchResources.
This makes ignoreExistingResources flag a bit brittle as that resource should be
considered as an existing/past one.
We should probably flush past resource and probably introduce a more explicit
way of handling "existing" resources on the server side.
The fix in document-events.js relates to failures in browser_net_offline_mode.js.
This test was passing thanks to late dom-complete event emitted on the previous WindowGlobal.
Surprisingly, when reloading the page in offline mode, the previous, already existing WindowGlobal
triggered the WebProgressListener and we were emitting dom-complete event.
Because of throttling, this resource is no longer transfered to the client as the related target
actor is already destroyed on reload.
But at the end, the issue was the missing dom-interactive and dom-complete events for the error page.
Regarding browser_net_ws-sse-persist-columns.js, it looks like this test was properly waiting
for the WebSocket table to update. We were really lucky it was working without frequent intermittent!
Similarly to the client side, DOCUMENT_EVENT's will-navigate is special
and has to be emitted synchronously in order to prevent clearing things out of order.
This is also true for NETWORK_EVENT_STACKTRACE which is expected to be received
*before* related NETWORK_EVENT. NETWORK_EVENT_STACKTRACE is fired from the content
process while NETWORK_EVENT is fired from the parent process.
For now, it is easier to synchronously emit those resources rather than trying
to do cross process coordination.
We may revisit this choice once we start doing throttling from the parent process
and may be once D143409 lands.
About browser_resources_clear_resources.js, it is surprising it wasn't already failing.
Differential Revision: https://phabricator.services.mozilla.com/D197772
Media Capabilities has been shipped as a standard feature long enough,
it's no need to guard it by the preference anymore.
Differential Revision: https://phabricator.services.mozilla.com/D212322
This changes where the IsUpgradeDowngradeEndlessLoop check triggers.
Before this patch, it triggered during the redirect caused by the https
upgrade. With this patch, it triggers during the downgrade for http
redirects. META and JS redirect are still detected during upgrade.
This should be fixed as a follow up (See Bug 1896691).
Downgrade in this context means same url, except with the scheme http
instead of https.
Different query parameters normally lead to different responses by web servers.
Don't consider the '#ref' part of the uri, because it doesn't get send to
the server and therefore can't change the server response.
We can't use the redirect chain anymore, because the query parameters
are trimmed since Bug 1715785.
This also removes the config option dom.security.https_only_check_path_upgrade_downgrade_endless_loop,
because it adds unnecessary complexity. Removing it for this patch is
easier.
https-only, https-first and httpssvc_https_upgrade tests had to be
modified, because they depended on the incorrect handling of query
strings in loop detection.
Differential Revision: https://phabricator.services.mozilla.com/D193672
This fixes the fuzzer-found assertion reported in bug 1899840, as well as the real-world
website hangs reported in bug 1900169.
In addition, it adds a pref (layout.css.intrinsic-size-first-letter.enabled) that gates
the new functionality during intrinsic size computation. This gives us a way to easily
disable it in the event of other regressions showing up.
Also add the testcase from 1899840 as a wpt crashtest.
Differential Revision: https://phabricator.services.mozilla.com/D212699
This uses the warn macro for promotion errors. It's not clear this will
be useful for web authors, but hopefully it's useful for Firefox
developers.
This has the potential to be very spammy. I need ideas on how to limit
the reporting to new or interesting errors.
Differential Revision: https://phabricator.services.mozilla.com/D212340
This changes where the IsUpgradeDowngradeEndlessLoop check triggers.
Before this patch, it triggered during the redirect caused by the https
upgrade. With this patch, it triggers during the downgrade for http
redirects. META and JS redirect are still detected during upgrade.
This should be fixed as a follow up (See Bug 1896691).
Downgrade in this context means same url, except with the scheme http
instead of https.
Different query parameters normally lead to different responses by web servers.
Don't consider the '#ref' part of the uri, because it doesn't get send to
the server and therefore can't change the server response.
We can't use the redirect chain anymore, because the query parameters
are trimmed since Bug 1715785.
This also removes the config option dom.security.https_only_check_path_upgrade_downgrade_endless_loop,
because it adds unnecessary complexity. Removing it for this patch is
easier.
https-only, https-first and httpssvc_https_upgrade tests had to be
modified, because they depended on the incorrect handling of query
strings in loop detection.
Differential Revision: https://phabricator.services.mozilla.com/D193672
Data classification note:
This patch extends the telemetry introduced in https://phabricator.services.mozilla.com/D211194.
The metrics that are still under Category 2 “Interaction data”.
The metrics measure the user interaction with the certificate compression decoders.
In this patch we check how often the users were using the certificate compression feature using the brotli decoder and what's the performance gain (amount of bytes saved during the TLS handshake).
Differential Revision: https://phabricator.services.mozilla.com/D210011
This patch enables advertisement and decoding using zlib encoding algorithm the certificates during the TLS connection for Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D203909
By default, it is disabled by pref gfx.canvas.remote.recycle-used-data-surface = false.
Add a capability to reuse used DataSourceSurface that was previously used for storing converted video data.
Add argument gfx::DataSourceSurface* aSurface to TextureHost::GetAsSurface(). aSurface may be used as returned DataSourceSurfacefi the TextureHost supports it.
Differential Revision: https://phabricator.services.mozilla.com/D212608
This uses the warn macro for promotion errors. It's not clear this will
be useful for web authors, but hopefully it's useful for Firefox
developers.
This has the potential to be very spammy. I need ideas on how to limit
the reporting to new or interesting errors.
Differential Revision: https://phabricator.services.mozilla.com/D212340
Frédéric Wang
Kagami Sascha Rosylight
pstanciu
Harshit Sohaney
Gregory Pappas
edgul
Luke Warlow
Nicolas Silva
Iulian Moraru
Helena
Henrik Skupin
Brad Werth
alwu
Tamas Szentpeteri
Alexandre Poirot
sotaro
Ryan Hunt
Manuel Bucher
Jonathan Kew
Sean
Greg Stoll
Sandor Molnar
Malte Juergens
Emilio Cobos Álvarez
Anna Weine
Cristina Horotan