Use subject principal as triggering principal in <img> "src" attribute.
Also get rid of the `BeforeMaybeChangeAttr`/`AfterMaybeChangeAttr` dance:
It makes more logical sense for these effects to happen _after_ the
attribute has actually been changed.
The imgLoader code consistently uses the term `loadingPrincipal` for
the principal that is called the `triggeringPrincipal` everywhere else.
This aligns the naming to avoid confusion in later changes.
In order to tailor certain security checks to the caller that is
attempting to load a particular piece of content, we need to be able to
attach an appropriate triggering principal to the corresponding requests.
Since most HTML content is loaded based on attribute values, this means
capturing the subject principal of the caller who sets those attributes,
which in turn means we need to make it available to `AfterSetAttr` hooks
on all relevant element types.
We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a
loading principal currently retrieve it from the context node.
Since no current callers require the principal to be the loading
principal, and some already expect it to be the triggering principal
(which there's currently no other way to retrieve), a choice was made
to pass the triggering principal whenever possible, but use the loading
principal to determine the origin URL.
See: https://github.com/whatwg/fetch/issues/274#issuecomment-2841053461
Considering the ubiquitous nature of gif, jpg, png, mp4, avi, etc. those
are left out, leaving just jxl, webp, x-matroska (mkv) and webm as
explicitly mentioned supported formats for conneg.
Note: it's not clear where network.http.accept.image is used in practice
because our normal place to use the image override (imgloader) uses
a different pref (image.http.accept).
Relying on the implicit conversion by `::FromContent` doesn't work for
us because we inherit that from `nsGenericHTMLElement` and isn't specific
to `HTMLAreaElement`, so it would accept other elements.
This also updates the Attribute changed event handler to exclude `<a>`
elements and cleans up an unused variable from the old code.
This was part of the HTML4 standard but only ever implemented by Mozilla
and removed again in HTML5 due to lack of adoption. Retaining this could
cause web compat issues and unspecified behavior in the layout engine.
In the modern era of user-customizable Quick Access sidebars on every file
dialog, navigating via `.lnk` files is considerably less useful than it
was twenty years ago.
Disable link-following in file-open dialogs by default, to prevent any of
the usual security issues involving symlink smuggling.
Allow overriding this behavior via a pref, for users who want to trade off
this security issue for convenience of being able to follow links inside
file dialogs (older OSes and established user workflows).
Note: File Save dialogs have a set of more nuanced guards against link
smuggling and protected file access; this change doesn't affect that.
This allows for two-location color stops (`color x% y%`) which is shorthand
for `color x%, color y%` where both colors are equal. (pct/length accepted)
See code comment for the reason it's implemented the way it is.
Resolves#2720
nsCaseInsensitiveCStringComparator ought to be cheap to construct, but
the object actually has a vtable to install and whatnot. So it's
beneficial to pull the construction of it outside of the headers loop.
The entries in mMethods and mHeaders aren't sorted in any special way,
so we can remove expired entries using UnorderedRemoveElementAt, which
is faster than RemoveElementAt.
Make all users of the various *CompileOptions classes #include "js/CompileOptions.h"
so that nothing but that file has to know about these classes having a
JS_PUBLIC_API on them, that would have to be present in forward-declarations.
Instead, require users to do so. This is a minor translation-unit size
improvement for anyone who never has to use SourceBufferHolder other than
by reference.
