These functions have a comment that suggests that the inherited
functionality isn't applicable and would all be skipped. This comment is
no longer true, so let's make use of the inherited function.
Differential Revision: https://phabricator.services.mozilla.com/D28264
--HG--
extra : moz-landing-system : lando
After introducing column-span, the ColumnSetWrapperFrame can have more
than one ColumnSetFrame children if there's any column-span:all child.
Thus we cannot use "height:100%" to pass block size information down to
the -moz-column-content's children.
Skip column span wrapper in nsIFrame::IsBlockWrapper() so that the
percentage column-span:all works.
Before this patch, the height of column contents are set to 100% of the
multicol container, so if the previous in-flows of column content
anonymous boxes consume all the height, later in-flows's height are all
0. In this patch, we don't restrict column-content's height, so their
height are calculated based on their children's height.
column-contain-1a.html passes because it can now correctly calculate the
union of all the column content's rect to find the correct sticky
positioning.
Differential Revision: https://phabricator.services.mozilla.com/D27627
--HG--
extra : moz-landing-system : lando
We remove initial x/y offset for nsSVGUtils::GetTransformMatrixInUserSpace
so that it can be used in not-nondisplay context. Previously it was only
used in nondisplay context, where x/y offset is always 0.
Then we use this utility to get the transform matrix to judge whether we need
special care for non-scaling-stroke. The old matrix doesn't account for CSS
transform.
Differential Revision: https://phabricator.services.mozilla.com/D28193
--HG--
extra : moz-landing-system : lando
...instead of forwarding to the sheet like HTMLStyleElement does.
I've proposed this behavior in:
https://github.com/whatwg/html/issues/3840#issuecomment-480894419
I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.
Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.
That means that setAttribute does something different than setting `disabled`,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.
Differential Revision: https://phabricator.services.mozilla.com/D26573
--HG--
extra : moz-landing-system : lando
SVGElement::PrependLocalTransformsTo doesn't take CSS transform into
account, we should use nsIFrame::GetTransformMatrix instead.
Differential Revision: https://phabricator.services.mozilla.com/D27659
--HG--
extra : moz-landing-system : lando
...instead of forwarding to the sheet like HTMLStyleElement does.
I've proposed this behavior in:
https://github.com/whatwg/html/issues/3840#issuecomment-480894419
I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.
Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.
That means that setAttribute does something different than setting `disabled`,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.
Differential Revision: https://phabricator.services.mozilla.com/D26573
--HG--
extra : moz-landing-system : lando
Use the external scroll offsets provided by Gecko to:
(a) Offset primitives and clips by accumulated scroll offset.
(b) Adjust the scroll transforms and hit test results.
This allows primitives and clips to be stored in a true local space,
that is consistent between display lists, even if scrolling has
occurred. This is a step towards planned picture caching improvements.
Differential Revision: https://phabricator.services.mozilla.com/D27856
--HG--
extra : moz-landing-system : lando
The reftests in the webm-video directory are currently only run in non-e10s
mode (bug 1544849), so at the moment, this test only provides coverage on
Linux 32bit debug builds and Android Fennec builds.
Differential Revision: https://phabricator.services.mozilla.com/D27601
--HG--
extra : moz-landing-system : lando
And tell webrender to do them itself (they have fundamental mismatches in how they
define shadow bounds).
Differential Revision: https://phabricator.services.mozilla.com/D26845
--HG--
extra : moz-landing-system : lando
Now the spec cleary says that we don't need to propagate body's
scroll-padding value to the document viewport since
https://github.com/w3c/csswg-drafts/issues/3740, so we don't need to care about
GetViewportScrollStylesOverrideElement() at all.
This change fixes the crash test case in this commit, but it's not sufficient.
In the next patch, we will fix another crash case.
Differential Revision: https://phabricator.services.mozilla.com/D27422
--HG--
extra : moz-landing-system : lando
And tell webrender to do them itself (they have fundamental mismatches in how they
define shadow bounds).
Differential Revision: https://phabricator.services.mozilla.com/D26845
--HG--
extra : moz-landing-system : lando
Check all transform-like properties which may affect the scaling
factors when computing the suitable scale for animations.
Differential Revision: https://phabricator.services.mozilla.com/D19526
--HG--
extra : moz-landing-system : lando
No color space was defined for these videos, making any correct rendering impossible.
We modify the h264 stream metadata, by marking it as being bt601.
This is done with the ffmpeg command:
ffmpeg -i dom/media/test/short.mp4 -codec copy -bsf:v h264_metadata=colour_primaries=6:transfer_characteristics=6:matrix _coefficients=6 -map 0
Differential Revision: https://phabricator.services.mozilla.com/D26871
--HG--
extra : moz-landing-system : lando
When an SVG is used as a CSS background-image, we previously used the same behavior as
a normal image. It will stretch if the background-size is incompatible with the intrinsic
size of the SVG. This is a webcompat issue.
Now we use the painting destination rect size instead to avoid stretching.
Differential Revision: https://phabricator.services.mozilla.com/D26935
--HG--
extra : moz-landing-system : lando
In the case where scroll-snap-type is specified for the scroll container, the
scroll-padding is also factored into in ScrollFrameHelper::ComputeScrollSnapInfo
which is called via ScrollFrameHelper::ScrollToWithOrigin. It doesn't double
the scroll-padding value, but it's actually redundant, we should avoid it.
We could separate the functionality of ScrollToWithOrigin, one is to scroll
to a given element, the other is to scroll to a given position. The former will
be used for Element.scrollIntoElement and relevant stuff, the latter will be
used for Element.scrollTo and relevant stuff. That's being said, as of now, we
have still the old scroll snap implementation, so the separation will introduce
complexity, the separation should be done once after the old implementation
removed.
There are 9 call sites of nsIPresShell::ScrollContentIntoView:
nsIPresShell::GoToAnchor
nsIPresShell::ScrollToAnchor
Element::ScrollIntoView
We definitely needs scroll-padding and scroll-margin for these functions.
nsCoreUtils::ScrollTo
This is used for Accesible::ScrollTo which scrolls to a given accesible node,
probably we should behave as what Element::ScrollIntoView does.
Accessible::DispatchClickEvent
Similar to the above, similated various mouse events on a given target node.
PresShell::EventHandler::PrepareToUseCaretPosition
PresShell::EventHandler::GetCurrentItemAndPositionForElement
Both are for context menu, we shouldn't consider scroll-padding and
scroll-margin.
nsFormFillController::SetPopupOpen
This is used for autocompletion popup, we shouldn't consider scroll-padding
and scroll-margin.
nsFocusManager::ScrollIntoView
This is bit unfortunate, we should use scroll-padding and scroll-margin
depending on call site of this function. Bug 1535232 is for this case.
cssom-view/scrollIntoView-scrollPadding.html which has some tests that is
actually testing scroll-padding with scrollIntoView passes with this change.
The reftest in this change is a test case that the browser navigates to an
element with specifying the anchor to the element.
Differential Revision: https://phabricator.services.mozilla.com/D23084
--HG--
extra : moz-landing-system : lando
When computing transform matrix, translation in SVG should not be rounded.
Checking !IsSVGTransformed() isn't the correct way, since an SVG frame may
have CSS transform applied.
Differential Revision: https://phabricator.services.mozilla.com/D26271
--HG--
extra : moz-landing-system : lando
Summary:
- Add markers to generated files to discourage manual edits.
- Add generated file to clang-format-ignore.
- Handle currently not supported Georgian characters in the Perl script.
Reviewers: jfkthame
Reviewed By: jfkthame
Bug #: 1533481
Differential Revision: https://phabricator.services.mozilla.com/D25269
--HG--
extra : rebase_source : cb485b400638790af9cbe24867d6a25505888459
This will enable the devtools font highlighting issue in bug 1479760 to be fixed
using ::selection, and matches webkit/blink behavior.
When we implement ::inactive-selection (bug 1475773) it will supersede this.
Differential Revision: https://phabricator.services.mozilla.com/D25396
--HG--
extra : moz-landing-system : lando
Changes:
- skipped problematic tests in crashtest suite on windows10-aarch64
- removed unnecessary pixel fuzzy values from previous iterations of greening tests
Differential Revision: https://phabricator.services.mozilla.com/D25714
--HG--
extra : moz-landing-system : lando
'contain:size' just means we should size these elements as if they had no
contents -- i.e. wherever we derive the size of the scrollable frame from the
size of its contents, we should pretend that its contents had zero size.
Differential Revision: https://phabricator.services.mozilla.com/D25155
--HG--
rename : layout/reftests/w3c-css/submitted/contain/contain-size-block-001.html => layout/reftests/w3c-css/submitted/contain/contain-size-block-002.html
rename : layout/reftests/w3c-css/submitted/contain/contain-size-inline-block-001.html => layout/reftests/w3c-css/submitted/contain/contain-size-inline-block-002.html
extra : moz-landing-system : lando
The animated GIF in background-blending-image-color-gif.html has two animation
frames, the one is a red rectangle, the other is a green rectangle. The reftest
is supposed to take the snapshot during the time where the animation frame is
the red rectangle (the first frame) and the frame duration is 1000ms. So if we
take over 1000ms there for some reasons, say on slow platforms, before taking
the snapshot, the reftet fails.
Differential Revision: https://phabricator.services.mozilla.com/D24843
--HG--
extra : moz-landing-system : lando
elementFromPoint-002.html, elementFromPoint-003.html and dialog-showModal.html
use document.elementFromPoint with a given point which is calculated from the
value returned by getBoundingClientRect() for a 100% width element. Before
this change, the given point is outside of view because there is no viewport
meta tag in the documents so that elementFromPoint fails. After this change, the
documents fit to the visual viewport so that elementFromPoint works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D16155
--HG--
extra : moz-landing-system : lando
Daniel Holbert
Ting-Yu Lin
violet
Ian Moody
Emilio Cobos Álvarez
Noemi Erli
Alexis Beingessner
Joel Maher
Andreea Pavel
Mats Palmgren
Glenn Watson
Markus Stange
Hiroyuki Ikezoe
Daniel Varga
Coroiu Cristina
Boris Chiou
Cosmin Sabou
Jean-Yves Avenard
Ciure Andrei
Lee Salzman
Jonathan Kew
Henri Sivonen
Jeff Muizelaar
André Bargull
Edwin Gao
Botond Ballo
Gurzau Raul
Cameron McCormack