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
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.
Depends on D119103
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.
Depends on D119103
Differential Revision: https://phabricator.services.mozilla.com/D119104
This patch doesn't change behavior; GetCrossDocParentFrameInProcess() is just a
wrapper for GetCrossDocParentFrame(), which is what we were calling before.
The "InProcess" version of this API (which we're migrating to in this patch) is
used to annotate GetCrossDocParentFrame() callsites that have been vetted as
being OK with the fact that this API returns null at the boundary of a
cross-origin iframe, if fission is enabled.
In this patch, the two calls that I'm migrating are inside of
EndSwapDocShellsForViews, which gets called when a tab is dragged between
windows. I'm annotating these two calls as OK, because:
- the first call is about maintaining the NS_FRAME_IN_POPUP state, which is
used for things like the menulist-dropdown popup. This bit doesn't need to
be propagated across process boundaries.
- the second call is about propagating a "needs-paint" notification up to
ancestor documents. I think we already handle paint invalidation for
cross-process iframes properly, independent of the explicit invalidation that
we're doing here.
Differential Revision: https://phabricator.services.mozilla.com/D108704
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
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
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
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
