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
When the iframe is inside a scaled container, the offset to the reference frame
needs to be scaled.
This change fixes both a rendering issue (bug 1682197) and a hit-testing issue
(bug 1682200) altogether for non WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D100218
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
As there's no incremental reflow for non-print documents, we can't rely
on FinishReflow getting called.
Not ultra-pretty, better ideas welcome.
Differential Revision: https://phabricator.services.mozilla.com/D96790
CSSPixel::ToAppUnits() requires computation at runtime. Since most of
the layout computations require `nscoord`, this patch defines extra
intrinsic sizes in app units.
Differential Revision: https://phabricator.services.mozilla.com/D96258
This patch moves the preferred aspect-ratio calculation from each
replaced elements' GetIntrinicRatio() into GetAspectRatio(), because
they share the same logic.
For nsImageFrame, the cached mIntrinsicRatio now stores only the image's
intrinsic ratio, not considering the aspect-ratio property.
This patch fixed "object-fit:contain" for canvas, image because
GetIntrinicRatio() no longer considers aspect-ratio. This also fixed
replaced elements' size when both "aspect-ratio:<ratio>" and
"contain:size" is specified.
This also makes us pass some of the aspect-ratio tests because we change
GetIntrinicRatio() into GetAspectRatio() in
nsLayoutUtils::IntrinsicForAxis() in Part5, which is used by nsBlockFrame
(via nsLayoutUtils::IntrinsicForContainer) to implement GetMinISize().
Differential Revision: https://phabricator.services.mozilla.com/D91229
For now, GetAspectRatio() is just an alias for GetIntrinicRatio(). In
Part 7, we're going to have GetAspectRatio() consider aspect-ratio
property so that each replaced elements only need to report their
intrinsic ratio via GetIntrinicRatio(). Non-replaced element can also
call GetAspectRatio() to get the ratio suitable to calculate layout
size.
As of this patch, all the replaced elements'
GetIntrinsicRatio() (including nsImageFrame::mIntrinsicRatio) consider
aspect-ratio properties (added in bug 1639963). This is wrong, because
it affects replaced element's content ratio. So we adapt only callers
[1] involving the computation of the frame's external sizes to retain
the behavior after Part 7.
This change shouldn't change behavior.
[1] Exceptions include 1) a caller in nsIFrame::ComputeSize() checking
the frame has no intrinsic ratio; 2) other frame classes implementing
nsIFrame::GetIntrinsicRatio() by calling their parent's
GetIntrinicRatio(). nsSubDocumentFrame::GetIntrinicRatio() is an
example.
Differential Revision: https://phabricator.services.mozilla.com/D91227
