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
This works, though probably we want to do some follow-up tweaks, like
the adding of the onload blocker and so on, so that we can avoid the
UpdateDimensions hack.
We may also want a PrintObject in the nsPrintJob tree, perhaps...
Differential Revision: https://phabricator.services.mozilla.com/D90310
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
When <object> targets to a svg image, we use nsSubDocumentFrame. The
intrinsic ratio should be overridden by aspect-ratio while computing
its size on this frame.
This update in nsSubDocumentFrame also works in iframe.
Differential Revision: https://phabricator.services.mozilla.com/D79362
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
This patch is generated by using my editor's rename functionality.
In the next patch, `nsIFrame::` prefix is going to be removed manually
from all the ChildLists() calls.
Differential Revision: https://phabricator.services.mozilla.com/D75893
This avoids a bunch of ugly casts and void pointers, without much overhead
(unlike std::function or such).
Differential Revision: https://phabricator.services.mozilla.com/D68182
--HG--
extra : moz-landing-system : lando
parser/htmlparser/tests/crashtests/515533-1.html most cleanly creates this crash if you repeat it many times.
It contains an iframe to a local file (so it's a same process iframe). The document in the iframe has an inline script that does
window.location.replace("data:text/plain,");
since crashtests have the pref browser.tabs.remote.dataUriInDefaultWebProcess set (to get more testing of fission) this makes the iframe now in a different process from it's parent.
When the bug happens we create the retained nsDisplaySubDocument before the process change, the document inside the iframe has a presshell, and importantly, it does not yet have a root frame. Then the remoteness change happens on the iframe, ResetFrameLoader is called on the nsSubDocumentFrame to remove the old frame loader. So now the nsSubDocumentFrame can't find a presshell (either via views or the frameloader).
The reason that the document in the iframe not having a root frame when the nsDisplaySubDocument is created is important is because if we had a root frame then the root frame would be the mFrame of the nsDisplaySubDocument and when the root frame got destroyed for the remoteness change that frame destruction would make sure that the nsDisplaySubDocument cannot be re-used. The nsSubDocumentFrame sticks around though, so the nsDisplaySubDocument doesn't think anything changed.
Differential Revision: https://phabricator.services.mozilla.com/D65888
--HG--
extra : moz-landing-system : lando
The existing code just clipped to a rect. We need to do the same clipping that the non-remote code path does which also handles border radius.
The existing code is the from initial implementation of nsDisplayRemote in https://hg.mozilla.org/mozilla-central/rev/85d06279c8358a8e1c883aa670a20212b1039a90 so I suspect that clipping to the inner view bounds instead of the frame content box is not an important difference.
Differential Revision: https://phabricator.services.mozilla.com/D62180
--HG--
extra : moz-landing-system : lando
The existing code just clipped to a rect. We need to do the same clipping that the non-remote code path does which also handles border radius.
The existing code is the from initial implementation of nsDisplayRemote in https://hg.mozilla.org/mozilla-central/rev/85d06279c8358a8e1c883aa670a20212b1039a90 so I suspect that clipping to the inner view bounds instead of the frame content box is not an important difference.
Differential Revision: https://phabricator.services.mozilla.com/D62180
--HG--
extra : moz-landing-system : lando
There are two distinct fixes in this patch.
1) Fix the rect we pass to EffectsInfo for both webrender and non-webrender case. The rect needs to be in coordinates of the subdocument but it was including the border/padding of the containing iframe. I also intersected it with the content rect so it doesn't extend outside of the subdocument, this doesn't fix anything AFAIK. I didn't track what caused this, it was likely in the first iteration of this code.
2) For webrender we double included the content rect offset in the rect we passed to PushIFrame because GetContentRectLayerOffset already includes that offset. This part is a regression from bug 1406715.
Differential Revision: https://phabricator.services.mozilla.com/D60208
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
The issues fall into these categories:
- Files that used StaticPrefs::layout_XYZ() API or gfxVars::XYZ that needed an
include. (Addressed by adding the missing include.)
- Files that use mozilla::dom::XYZ or mozilla::gfx::XYZ without qualifying the
namespace & without a 'using' decl. (Addressed by adding "using".)
- A few other includes for types/inlines that were used without their header.
Depends on D50162
Differential Revision: https://phabricator.services.mozilla.com/D50163
--HG--
extra : moz-landing-system : lando
Ting-Yu Lin
Emilio Cobos Álvarez
Cameron McCormack
Boris Chiou
Glenn Watson
Kagami Sascha Rosylight
Simon Giesecke
Kartikaya Gupta
Nika Layzell
Miko Mynttinen
Botond Ballo
Daniel Varga
Dorel Luca
Csoregi Natalia
Timothy Nikkel
Hiroyuki Ikezoe
Bogdan Tara
jeffin143
Gabriele Svelto
Kirk Steuber
Daniel Holbert
Matt Woodrow