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
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
This should pretty much match our non-fission behavior. I found the
original approach of keeping the frameloader from nsSubDocumentFrame
quite hard to get green on try unfortunately, because among other
things, the new frameloader wouldn't get the right viewport sizes /
position / etc.
Differential Revision: https://phabricator.services.mozilla.com/D121198
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
This avoids a problem where we receive the IPC message from the child
with updated intrinsics before an <embed> or <object> has had its frame
constructed in the parent, and drop the update.
Differential Revision: https://phabricator.services.mozilla.com/D99304
Also combine the border and padding arguments for
nsContainerFrame::ComputeSizeWithIntrinsicDimensions(), too. This method
is used as a helper to implement ComputeSize() for various replaced
elements. Its callers are all within nsIFrame's derived classes'
overridden methods, so I'm not bothering to convert them in a separate
patch.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D90064
In the next part, I'm going to use ComputeSizeFlags as the arguments in
some ReflowInput's methods. Because nsIFrame.h includes ReflowInput.h,
to solve the circular dependency, ComputeSizeFlags needs to be moved to
somewhere else.
Also, revise the document for ComputeSizeFlag. The rest of the patch is
just dropping `nsIFrame::` and adding `mozilla::` as needed.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D89542
In order to apply Automatic content-based minimum sizes, we have to know
the content size on the block axis. We cannot get the content size until
we finish the reflow of the child frames. So we have to keep a flag
which indicates the size of the ratio-dependent axis is overrideen by
aspect-ratio in ReflowInput.
We will set the correct return value in the next patch, For now, we
always return AspectRatioUsage::None.
Differential Revision: https://phabricator.services.mozilla.com/D79335
WR handles snapping of primitives and clips, and prefers the input
data to be exact floats. This fixes an inconsistency between the
clip and bounds of iframes in WR when there is a fractional
device-pixel ratio set.
Differential Revision: https://phabricator.services.mozilla.com/D85219
Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
nsDisplayRemote no longer has any direct ties to RenderFrame and should
be moved to nsSubDocumentFrame.cpp where it's actually used/created.
Differential Revision: https://phabricator.services.mozilla.com/D33563
--HG--
extra : rebase_source : ae2e03108820bd14b5f2771da17cabfd95706f94
extra : source : b301161ab461cd46cea3f91749896686c50e9b9f
extra : histedit_source : 1c80f83d26734e56bd6353f0a50dcbc4bf894b4b
Code outside of BrowserParent should just get the LayersId from a getter
and not worry about RenderFrame.
Differential Revision: https://phabricator.services.mozilla.com/D33562
--HG--
extra : rebase_source : 63f9f9680a7cb16a18d9e56999e02a124aa63429
extra : source : e86839ca63260b09184755c98890fa8abf371530
extra : histedit_source : 34333f5f78ecf9b4f3e12c6175a6e81724a41fb2
This happens in one test on try server that has some iframes that navigate.
I audited everywhere else that we change the view tree, this seems like the only place it can happen.
Differential Revision: https://phabricator.services.mozilla.com/D31399
--HG--
extra : moz-landing-system : lando
This happens in one test on try server that has some iframes that navigate.
I audited everywhere else that we change the view tree, this seems like the only place it can happen.
Differential Revision: https://phabricator.services.mozilla.com/D31399
--HG--
extra : moz-landing-system : lando
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
--HG--
extra : moz-landing-system : lando
