If the embedding element uses `object-fit`, then that indicates it's precisely
positioning and/or sizing the embedded SVG document's viewport to fit inside
the embedding element's content area. So, when the internal SVG viewBox
changes, then the embedding element needs to redo that positioning/sizing. For
now, this specifically requires a reflow (and in particular, the nsViewManager
adjustments at the end of nsSubDocumentFrame::Reflow).
Differential Revision: https://phabricator.services.mozilla.com/D37910
--HG--
extra : moz-landing-system : lando
This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
Since scroll position restoration is absolute, and we'll lose it as soon as we
apply any adjustment or do any other sort of scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D37941
--HG--
extra : moz-landing-system : lando
This reduces a bit of code complexity, fixes bugs where we weren't
reflowing enough, and optimizes additional cases that we couldn't
optimize in the past.
Co-authored-by: Chris Pearce <cpearce@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Differential Revision: https://phabricator.services.mozilla.com/D37610
--HG--
extra : moz-landing-system : lando
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Co-authored-by: Chris Pearce <cpearce@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D37609
--HG--
extra : moz-landing-system : lando
Currently items are painted with a context that has a transform of
-mLayerBounds.TopLeft(). This means that if TopLeft() changes the commands
will be in the wrong place because the -TopLeft() offset is baked into the
recording.
I don't think we've ever needed to support painting without this transformed
baked in so there were some infrastructure changes that needed to be made to
make this possible. Most of the problems come from the use of
gfxContext::GetClipExtents which expose the bounds of the underlying surface.
The biggest of these was fixed by the CreateClippedDrawTarget rewrite. The rest
should be handled by ensuring that the DrawTarget has bounds that are at least
as big as the union of the individual item bounds. i.e. GetClipExtents should
never intersect with bounds of the item.
This change has a couple of parts:
1. Store mLayerBounds.TopLeft() in the recording so that it will be subtracted
during replay
2. Use mLayerBounds as the Rect of the RecordingDrawTarget
3. Don't include mLayerBounds.TopLeft() in the transform during recording.
4. Adjust the dirty rect by recordingOrigin before we use it as a clip so that
it stays in the right place.
5. In PaintContainerItem the bounds parameter of PushLayer is in device space
so we need to account for the shift in the location of device space in the
DrawTargetRecording.
Differential Revision: https://phabricator.services.mozilla.com/D37513
--HG--
extra : moz-landing-system : lando
Since people like to get wrong attribute values on their images (see the
regressions from bug 1547231).
Differential Revision: https://phabricator.services.mozilla.com/D37936
--HG--
extra : moz-landing-system : lando
This position is only invalidated from FrameLayerBuilder, that's not a very good
signal.
This would get out of sync when using WebRender, and APZ messages will send
sub-pixel scroll positions that will get wrongly adjusted, causing small scroll
offsets which scroll anchoring would incorrectly try to correct, which is the
ultimate cause of the jittering.
Differential Revision: https://phabricator.services.mozilla.com/D37875
--HG--
extra : moz-landing-system : lando
As far as I can tell, the intermittent suite_start failures are due to
stdout/stderr output interleaving -- a known issue for reftest logging,
without a clear way forward. Let's work around it the same way we did
on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D37023
--HG--
extra : moz-landing-system : lando
Inheriting block-size is just plain wrong in presence of calc or percentages.
The layout without these rules also matches other browsers, so I see no reason
not to do this.
Differential Revision: https://phabricator.services.mozilla.com/D37746
--HG--
extra : moz-landing-system : lando
As described in https://bugzilla.mozilla.org/show_bug.cgi?id=1562122#c5,
this precomputed argument is not our children's block-size, but is the
block-end edge of children because aState.mBCoord is initialized as our
border-padding block-start in BlockReflowInput's constructor.
I also delete the sentence "The final block-size that is used in
aMetrics will be set ..." because this is the implementation details of
this function, and is likely to become inaccurate after considering the
block split by column-span.
Depends on D37625
Differential Revision: https://phabricator.services.mozilla.com/D37626
--HG--
extra : moz-landing-system : lando
Because aStatus is also used as an output argument, caching aStatus as
our children's reflow status can and make the logic that morphs aStatus
to our reflow status easier to follow. And this helps the patch I'm
going to add for computing the block-size for column-span split.
Depends on D37624
Differential Revision: https://phabricator.services.mozilla.com/D37625
--HG--
extra : moz-landing-system : lando
We usually use reference to manipulate nsReflowStatus like in Reflow().
The documentation for aStatus needs edit, and is done in next part.
Depends on D37623
Differential Revision: https://phabricator.services.mozilla.com/D37624
--HG--
extra : moz-landing-system : lando
ComputeFinalBSize() doesn't need to modify the final inline-size, so we
don't need to pass the entire LogicalSize into it.
Also, aReflowInput.AvailableBSize() is used multiple times. Cache it to
shorten some statements.
Differential Revision: https://phabricator.services.mozilla.com/D37623
--HG--
extra : moz-landing-system : lando
And remove some of the ::placeholder and ::cue hacks where we need to use
!important to make the property not apply for content but apply on UA sheets.
The comment about the white-space property was wrong, we don't enforce it with
!important in the UA stylesheets for <input> (we do for <textarea> though), so
I've kept the flag since it really applies.
Differential Revision: https://phabricator.services.mozilla.com/D37717
--HG--
extra : moz-landing-system : lando
Inheriting block-size is just plain wrong in presence of calc or percentages.
The layout without these rules also matches other browsers, so I see no reason
not to do this.
Differential Revision: https://phabricator.services.mozilla.com/D37746
--HG--
extra : moz-landing-system : lando
Looks like some users use it, and it's not too much effort to support. This is
somewhat simpler, and IMO better than what existed before bug 1514655 because:
* It doesn't regress bidi rendering when the pref is disabled (before, the pref
would prevent plaintext.css from applying altogether).
* It's consistent with the way view-source docs work.
* It doesn't use non-standard stylesheet APIs to toggle the stylesheet
(bug 1260720).
Differential Revision: https://phabricator.services.mozilla.com/D37742
--HG--
extra : moz-landing-system : lando
Looks like some users use it, and it's not too much effort to support. This is
somewhat simpler, and IMO better than what existed before bug 1514655 because:
* It doesn't regress bidi rendering when the pref is disabled (before, the pref
would prevent plaintext.css from applying altogether).
* It's consistent with the way view-source docs work.
* It doesn't use non-standard stylesheet APIs to toggle the stylesheet
(bug 1260720).
Differential Revision: https://phabricator.services.mozilla.com/D37742
--HG--
extra : moz-landing-system : lando
Since that means that we won't suppress them when switching display back (since
we have no frame to pull the old style from).
We may want to match Chrome more exactly and don't do this any time `display`
changes (which if I'm reading their code correctly is what they do...).
But for now I've done the minimal thing and added a test.
Differential Revision: https://phabricator.services.mozilla.com/D38094
--HG--
extra : moz-landing-system : lando
We don't need to treat a details frame as if it has multiple content
insertion points in order to reframe it. We can just put the logic into
WipeContainingBlock().
The reftests layout/reftests/details-summary/dynamic-add-*.html also
cover adding <summary> into a <details> in various situations.
Differential Revision: https://phabricator.services.mozilla.com/D36529
--HG--
extra : moz-landing-system : lando
According to this resolved spec issue:
https://github.com/w3c/csswg-drafts/issues/2140,
we retire the 3-valued <position> on
1. `object-position`
2. `perspective-origin`,
3. `mask-position`
4. `circle()` and `ellipse()`
, but still keep the support for `background-position`.
Besides, I simply run this python script to generate the .ini file:
```
s = sys.argv[1] + ".ini"
with open(s, "w") as f:
f.write('[{}]\n'.format(sys.argv[1]))
f.write(' expected: FAIL\n')
f.write(' bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1559276\n')
```
Differential Revision: https://phabricator.services.mozilla.com/D37126
--HG--
extra : moz-landing-system : lando
Update the existing reftests to not use 3 valued syntax.
I run the script to update the syntax in
`layout/reftests/w3c-css/submitted/images3/*`,
`layout/reftests/w3c-css/submitted/masking/*`,
`layout/reftests/xul/*`, and
`layout/reftests/webm-video/*`:
```
function rename() {
find layout/reftests/\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.html" -or\
-name "*.xul" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename "object-position: top 3px center" "object-position: top 3px left 50%"
rename "object-position: center right 25%" "object-position: top 50% right 25%"
```
For `layout/reftests/svg/svg-integration/clip-path/*`, I just manually
update them.
Differential Revision: https://phabricator.services.mozilla.com/D37125
--HG--
extra : moz-landing-system : lando
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--HG--
extra : moz-landing-system : lando
Also move the impl to the .cpp file to avoid expensive rebuilds when it
is modified.
Differential Revision: https://phabricator.services.mozilla.com/D37589
--HG--
extra : moz-landing-system : lando
This is the easy fix.
The hard fix (outlined in the comment) would be nice, but I don't think this bug
alone justifies it.
Differential Revision: https://phabricator.services.mozilla.com/D38184
--HG--
extra : moz-landing-system : lando
The referrerInfo in SheetLoadData and StyleSheetInfo should be
different. One is used to load a style sheet and the other is used to
load resources referenced by a style sheet.
Differential Revision: https://phabricator.services.mozilla.com/D36477
--HG--
extra : moz-landing-system : lando
This will have two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
It wasn't working because it was testing inline size == NS_UNCONSTRAINEDSIZE
rather than block size, so it was taking always the reflow path.
The attached test is on par with the vertical-lr / horizontal-tb cases with
this patch, but takes way over 10s without it.
Differential Revision: https://phabricator.services.mozilla.com/D37437
--HG--
extra : moz-landing-system : lando
This is a weird pref.
First, it is VarCached into two different global variables, one in
nsSubDocumentFrame.cpp, and the other in nsView.cpp.
Second, the pref is not defined by default. When the VarCache variables are
initialized they are therefore set to the default value provided to the
`AddBoolVarCache()` call, which in both cases is `true`. This semantics isn't
possible with `StaticPrefs`, so the patch defines the pref as true by default.
Differential Revision: https://phabricator.services.mozilla.com/D37204
--HG--
extra : moz-landing-system : lando
NOTE: This test relies on our wrong behavior that Element.scrollIntoView works
across the cross-origin document boundaries, which is bug 1561754. So once
after we make 'Find in page' work in fission world (bug 1553384), we should
revise this test.
Differential Revision: https://phabricator.services.mozilla.com/D36137
--HG--
extra : moz-landing-system : lando
browserElement_ScrollEvent.js is affected by this change. Before this change
the document for iframe mozbrowser was not considered as the root content
document, but after this change, it's considered as the root content document.
Given the nature of iframe mozbrowser, I believe it's the right behavior.
The browser mochitest in this commit fails without this change since
the minimum-scale size is used in the out-of-process iframe so that the visual
viewport size gets 3x bigger than the expected size.
Differential Revision: https://phabricator.services.mozilla.com/D36547
--HG--
extra : moz-landing-system : lando
Before this patch, we would use fallback for all border images. Now for
all but vector images we will use the WebRender border images
primitives. Vector images are an exception because the fallback is
clever in that it upscales the vector image and clips to only draw the
region it requires. This avoids artifacting but to do something similar
for WebRender as it is currently defined, we would increase our CPU and
memory footprint as we would need to produce the entire vector image
upscaled, not just the parts we need. In the future we should change
WebRender to accept different image resources for each of the segments.
Differential Revision: https://phabricator.services.mozilla.com/D37093
When window is resized, the cue would usually be zoomed in or out automatically with the video and keep its relative position to video.
However, if video is being applied the explicit percentage value on its 'width' or 'height', we have to recompute cue's position in this situation, because the width or height of the video would be scaled again after applied the first size scaled which is caused by resizing.
Differential Revision: https://phabricator.services.mozilla.com/D36138
--HG--
extra : moz-landing-system : lando
Without the change a green rectangle in each reftest in this commit covers whole
screen.
Differential Revision: https://phabricator.services.mozilla.com/D37328
--HG--
extra : moz-landing-system : lando
This makes us pass web platform test contain-layout-baseline-004.html (i.e. it
makes us treat that test's 'contain:layout' table-cell as having no baseline,
so we align its bottom edge with the other cell's actual baseline, as the test
expects).
This is required by the spec text at [1] which excludes most table parts but
includes table cells, and says "the containing element is treated as having no
baseline".
[1] https://drafts.csswg.org/css-contain/#containment-layout
Differential Revision: https://phabricator.services.mozilla.com/D37118
--HG--
extra : moz-landing-system : lando
I missed in bug 1487216 that the pres arena memory reporting assumes that the
entry indices are frame class ids, which means that we're reporting some display
list arena entries as frames, which is obviously wrong.
Cleanup a bit nsPresArena to remove the custom id concept, and report also
individual display item type memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D35368
--HG--
extra : moz-landing-system : lando
As far as I can tell, the intermittent suite_start failures are due to
stdout/stderr output interleaving -- a known issue for reftest logging,
without a clear way forward. Let's work around it the same way we did
on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D37023
--HG--
extra : moz-landing-system : lando
Due to the sheer number of tests that exhibit a random fuzz with maxDifference=1
and maxDifference=2 with WR on Android, it's easier to just tweak the harness
to autofuzz these away. This adds machinery to do so, and also adds a new
annotation that can be used to disable the autofuzzing on specific tests.
Depends on D36794
Differential Revision: https://phabricator.services.mozilla.com/D36796
--HG--
extra : moz-landing-system : lando
The sideways-rl test is fuzzy (even without webrender) because we get a 1px discrepancy
in baseline positioning for the rotated text; presumably the rotation done by sideways-rl
and that done by CSS transform end up rounding the center of rotation differently. That's
probably a bug we should fix, although offhand I'm not sure which is more correct; anyhow,
it's a separate issue from the bug here.
When WebRender is enabled, the test/reference difference is much greater because many of
the glyphs are wildly misplaced, not just shifted by 1px, so it still fails despite the
fuzzy() annotation.
Differential Revision: https://phabricator.services.mozilla.com/D36793
--HG--
extra : moz-landing-system : lando
We should also check IsRootContentDocumentCrossProcess instead of
IsRootContentDocument there, it will be fixed in bug 1562505.
The test case in this commit is almost copied-n-pasted from
helper_scroll_into_view_bug1516056.html.
Differential Revision: https://phabricator.services.mozilla.com/D36556
--HG--
extra : moz-landing-system : lando
(The single line that made them active was commented out in the previous patch.)
Differential Revision: https://phabricator.services.mozilla.com/D36425
--HG--
extra : moz-landing-system : lando
This simplifies dealing with frames that are pushed/pulled between
continuations during reflow, allows us to avoid the complexity of the
fix to 1459937, and hopefully fixes some of the regressions from bug
1308876.
This disables the changes from bug 1459937 by commenting out a single
line in ReparentFrameInternal in nsBlockFrame.cpp, but all the added
code will be removed in the following patch.
Co-authored-by: Gerald Squelart <gsquelart@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Depends on D36423
Differential Revision: https://phabricator.services.mozilla.com/D36424
--HG--
extra : moz-landing-system : lando
Actually, long tap can set focus. But since it uses `nsIFocusManager::FLAG_BYMOUSE` flag, we cannot recognize whether setting focus is by long tap or not.
So I would like to add new flag `FLAG_BYLONGPRESS` and `CAUSE_LONGPRESS` that are by long tap.
Differential Revision: https://phabricator.services.mozilla.com/D35991
--HG--
extra : moz-landing-system : lando
This will display something like:
```
error: static_assert failed due to requirement '528UL <= 504UL' "Style struct became larger than the size limit"
static_assert(Actual <= Limit, "Style struct became larger than the size limit");
^ ~~~~~~~~~~~~~~~
note: in instantiation of template class 'AssertSizeIsLessThan<nsStylePosition, 528, 504>' requested here
STYLE_STRUCT_RESET(Position)
^
note: expanded from macro 'STYLE_STRUCT_RESET'
^
note: expanded from macro 'STYLE_STRUCT'
static_assert(AssertSizeIsLessThan<nsStyle##name_, sizeof(nsStyle##name_), kStyleStructSizeLimit>::instantiate, "");
```
Which includes both the size, the limit, and the struct name, as opposed to the
current:
```
error: static_assert failed due to requirement 'sizeof(nsStylePosition) <= kStyleStructSizeLimit' "nsStylePosition became larger than the size limit"
STYLE_STRUCT_RESET(Position)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: expanded from macro 'STYLE_STRUCT_RESET'
^~~~~~~~~~~~~~~~~~
note: expanded from macro 'STYLE_STRUCT'
static_assert(sizeof(nsStyle##name_) <= kStyleStructSizeLimit, \
```
Which only includes the name and thus isn't very useful.
Differential Revision: https://phabricator.services.mozilla.com/D36546
--HG--
extra : moz-landing-system : lando
This will have two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
With retained display lists, a content render root might get marked as not
needing a build, in which case the nsDisplayRenderRoot::CreateWRCommands
function does an early exit. In this case, we don't mark the associated
WebRenderUserData as used during the display list build, which causes it to
get deleted at the end of the transaction. The next transaction that
doesn't early-exit will re-create the WebRenderUserData with a new boundary
object. The compositor therefore thinks it's a brand new thing and, if
conditions are right, could end up destroying and re-creating much of the
APZC tree. That in turn can have effects like discarding paint-skipped
scrolling.
This patch ensures we always touch the WebRenderUserData during the display
list build, so we don't discard it. This problem may still affect nested
nsDisplayRenderRoot instances but I don't think we ever cases where those
occur.
Depends on D36386
Differential Revision: https://phabricator.services.mozilla.com/D36387
--HG--
extra : moz-landing-system : lando
The bounds attribute has been deprecated and shown zero use, and thus this change removes it.
Differential Revision: https://phabricator.services.mozilla.com/D36005
--HG--
extra : moz-landing-system : lando
After the deleted logic
```
aFinalSize.BSize(wm) =
std::max(aReflowInput.AvailableBSize(), aContentBSize);
```
aStatus changes to incomplete, so it computes the same thing again.
Differential Revision: https://phabricator.services.mozilla.com/D36290
--HG--
extra : moz-landing-system : lando
Daniel Holbert
Emilio Cobos Álvarez
Bogdan Tara
Lee Salzman
Nika Layzell
Mirko Brodesser
Noemi Erli
Chris Pearce
L. David Baron
Jeff Muizelaar
longsonr
Boris Chiou
Edwin Gao
Andreas Pehrson
Calixte Denizet
Gurzau Raul
Ting-Yu Lin
Boris Zbarsky
Kartikaya Gupta
Eitan Isaacson
Brendan Dahl
Barret Rennie
Thomas Nguyen
Mihai Alexandru Michis
Dorel Luca
Sylvestre Ledru
Nicholas Nethercote
Jonathan Kew
Hiroyuki Ikezoe
Narcis Beleuzu
shindli
Hiroyuki Ikezoe
Andrew Osmond
Sebastian Hengst
alwu
Cameron McCormack
Charlie Marlow
Jonathan Kingston
Cosmin Sabou
Geoff Brown
Victor Porof
Razvan Maries
Csoregi Natalia
Oana Pop Rus
Gerald Squelart
Dzmitry Malyshau
Makoto Kato
Kris Maglione
Sean Feng
Ryan Hunt
Kagami Sascha Rosylight