As per spec, see https://drafts.csswg.org/css-color-adjust/#color-scheme-effect:
> In order to preserve expected color contrasts, in the case of embedded
> documents typically rendered over a transparent canvas (such as
> provided via an HTML iframe element), if the used color scheme of the
> element and the used color scheme of the embedded document’s root
> element do not match, then the UA must use an opaque canvas of the
> Canvas color appropriate to the embedded document’s used color scheme
> instead of a transparent canvas.
After bug 1782596 we were using the preferred rather than used
color-scheme, which is the right thing to do for prefers-color-scheme,
but not for the canvas background.
Differential Revision: https://phabricator.services.mozilla.com/D155831
The ColorSchemeMode::Preferred change doesn't make a difference (that
is, always use the preferred one), since when we only propagate from
top's embedder the embedder is chrome, which always has the preferred
color-scheme.
Differential Revision: https://phabricator.services.mozilla.com/D154931
By making image loading in <embed> and <object> behave more like when
an <iframe> loads an image, we can make sure that the synthetic
document generated is process switched if the image is cross
origin. This is done by making image loading in nsObjectLoadingContent
follow the document loading path.
We also make sure that we pass the image size back to the embedder
element to not get stuck with the intrinsic size.
To avoid named targeting being able to target these synthetic
documents, as well as showing up in `Window.frames` and being counted
in `Window.length`, we keep a filtered list of non-synthetic browsing
contexts for that use-case.
This feature is controlled by two prefs:
* browser.opaqueResponseBlocking.syntheticBrowsingContext
This triggers the creation of synthetic documents for images loaded
in <object> or embed.
* browser.opaqueResponseBlocking.syntheticBrowsingContext.filter
This turns on the filtering of synthetic browsing contexts in named
targeting, `Window.length` and `Window.frames`.
Differential Revision: https://phabricator.services.mozilla.com/D148117
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
ContainSizeAxes::ContainSize and ContainSizeAxes::ContainIntrinsicSize
were just using 0 for the axes with size containment, now they will take
contain-intrinsic-width and contain-intrinsic-height into account.
The WritingMode parameter is replaced with a nsIFrame from which the
properties are retrieved.
There are various places that aren't currently using these functions, so
the effect of this patch is rather minimal, but some cases of the new
test are now passing.
Differential Revision: https://phabricator.services.mozilla.com/D152355
This patch does not impact behavior; it's just formatting changes.
This patch was automatically generated by the following command:
./mach clang-format -p layout
Differential Revision: https://phabricator.services.mozilla.com/D145163
This allows popups and sidebars to use the chrome preferred
color-scheme.
This moves the responsibility of setting the content-preferred color
scheme to the appropriate browsers to the front-end (via tabs.css).
We still return the PreferredColorSchemeForContent() when there's no
pres context (e.g., for display:none in-process iframes). We could
potentially move a bunch of the pres-context data to the document
instead, but that should be acceptable IMO as for general web content
there's no behavior change in any case.
Differential Revision: https://phabricator.services.mozilla.com/D142578
In bug 1731929 we added this value, here we give it the value we want for child processes. I think the code comments should explain it.
Differential Revision: https://phabricator.services.mozilla.com/D126629
Not sure we even need this anymore but just doing this so I can finish the fission audit.
Added way back in bug 588407.
This shouldn't actually be any behaviour change: anything that is IsRootContentDocumentInProcess but not IsRootContentDocumentCrossProcess should be a oop if with fission (unless I'm missing a case), so we will never hit this code path, we'll hit the remote iframe path above.
Differential Revision: https://phabricator.services.mozilla.com/D124277
As those don't have the same incremental reflow issues as root paginated
documents, and we do need this for remote iframes to update their
viewport.
Differential Revision: https://phabricator.services.mozilla.com/D119104
As those don't have the same incremental reflow issues as root paginated
documents, and we do need this for remote iframes to update their
viewport.
Differential Revision: https://phabricator.services.mozilla.com/D119104
