Previously, WebRender was getting a rectangle for reference frames
and stacking contexts, and it had to carefully treat the origin of this rectange:
- by offseting all the items in a stacking context
- by negatively compensating the sticky frame scroll port according to the
parent reference frame origin
With this change, we stop providing any non-zero origins. Instead we accomplish
the same behavior using existing API primitives, such as reference frames:
1. when a stacking context has an origin, we push another reference frame for it
2. when computing the sticky frame scroll port, we take this origin into account
This slightly simplifies Gecko-WR API, but more importantly it would allow WR to
get rid of this logic (of handling origins), which in turn would allow to switch
the reference frames from push()/pop() model to just define(), like we do for
scroll/sticky frames already.
Differential Revision: https://phabricator.services.mozilla.com/D13081
--HG--
extra : moz-landing-system : lando
This class wasn't applied due to a typo, and it's unnecessary anyway -- there's
a separate 'fieldset {...}' CSS rule further down in the file that has the same
effect (hiding the border and the textual contents).
Differential Revision: https://phabricator.services.mozilla.com/D12618
--HG--
extra : moz-landing-system : lando
Note that we don't get this correct for form controls yet, so the -002 test is annotated as "fails" for now.
Differential Revision: https://phabricator.services.mozilla.com/D12617
--HG--
extra : moz-landing-system : lando
Note that Firefox doesn't actually match this expectation yet, so I've added a
'fails' annotation to the manifest with the followup bug number.
Also, this patch makes several other improvements to this test:
- remove red background in testcase. This was making the testcase spuriously
fail in Chrome, because Chrome paints (at least) a 1px-tall background-area
on empty buttons, which meant a 1px-tall red area in the testcase vs. a
1px-tall gray area in the reference case.
- clear floats to prevent them from piling up awkwardly.
- use 'vertical-align:top' to turn off baseline alignment in parts of the test
where the testcase has text and the reference case does not (and where we're
not intentionally testing the baseline's influence on layout).
Depends on D12614
Differential Revision: https://phabricator.services.mozilla.com/D12615
--HG--
extra : moz-landing-system : lando
Now we no longer update the corresponding display items for the animations that
are prevented from running on the compositor if the animations themselves don't
generate any change hints, e.g the same value is specified in both 'from' and
'to' keyframes. So that we can enable the reftests that we had been suffering
from continuous MozAfterPaint events.
Depends on D12397
Differential Revision: https://phabricator.services.mozilla.com/D12369
--HG--
extra : moz-landing-system : lando
add fuzzy-if statements to allow reftests to run on new windows10 AMI image
Differential Revision: https://phabricator.services.mozilla.com/D12553
--HG--
extra : moz-landing-system : lando
There are 7 test cases in this commit.
- no-viewport.html
A test case that wider contents should be scaled down even if no viewport
meta tag exists.
- viewport-width.html
A test case that wider contents should be scaled down (i.e. fit to the
device screen).
- minimum-scale.html
A test case that the initial zoom value is clamped by minimum-scale.
- initial-scale-0.html
A test case that specified initial-scale value is less than the default
minimum scale value (0.1), in such cases we shrink the content to fit
the display size.
- initial-scale-100.html
A test case that specified initial-scale value is greater than the default
maximum scale value (10), in such cases we shrink the content to fit
the display size.
- initial-scale-1.html
A test case that the auto initial zoom calculation doesn't apply to the
documents specifying initial-scale.
- box-shadow.html
A test case that box-shadow-ed area isn't incorporated into the initial zoom
value.
Depends on D10197
Differential Revision: https://phabricator.services.mozilla.com/D10198
--HG--
extra : moz-landing-system : lando
The contain:paint clipping would be redundant and hence unnecessary in this
scenario, because:
- Scroll frames already clip their descendant frames.
- contain:paint has other (non-clipping-related) effects that prevent
descendant frames from escaping the scrollframe ancestor.
So, no further clipping is required.
This is a behavior change - it works around an issue that makes us fail to
repaint mousewheel-scrolled content inside of any scrollframe that returns true
from ShouldApplyOverflowClipping().
Differential Revision: https://phabricator.services.mozilla.com/D12056
--HG--
extra : moz-landing-system : lando
The modification to nsLayoutUtils::GetFirstLinePosition() is needed because we
need to get the correct first line position from child (i.e. ColumnSet) when
there's an outside bullet on ColumnSetWrapperFrame.
The difference between the two newly added tests is "overflow: hidden" on
the columns.
Differential Revision: https://phabricator.services.mozilla.com/D7009
--HG--
extra : moz-landing-system : lando
In particular:
-webkit-appearance:none inhibits the range track.
An author-specified 'border' or 'background' does NOT disable the theme.
The default non-themed background-color is opaque.
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
adjust fuzzy-if statements for win10 tests that are fialing on new windows 10 ami image
Differential Revision: https://phabricator.services.mozilla.com/D11914
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This is enough to fix the devtools regression and matches what other browsers
do in the no-attribute case.
Also, I think this change over all makes sense: it doesn't make any sense to
display the broken image icon if there's no request, and we already assume in
EnsureIntrinsicSizeAndRatio() that we don't paint the icon for those (and make
the intrinsic size 0x0).
We still show the border, which matches other UAs (note that devtools
effectively masks the border away with mask-image).
This technically also can change behavior of <object> and <input>, but I think
it's better to be consistent, since EnsureIntrinsicSizeAndRatio also doesn't
special-case <img> either.
Differential Revision: https://phabricator.services.mozilla.com/D11659
--HG--
extra : moz-landing-system : lando
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
Keep our old 'progressbar' as an alias for now, but unship
'progresschunk' by restricting it to UA/chrome sheets only.
Unship 'progresschunk-vertical' by removing it since it's
not used internally for anything.
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
--HG--
extra : source : 803b224d52a0940b4fb4b3b9cffc6a1fa6e5d4ee
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
The current spec says: "If only the X value is given, the Y value
defaults to the same value.", so we should update the behavior.
Besides, we also update the serialization, so we serialization both
specified and computed value by servo. We enable the preference
for all the css-transforms, so some of them are passed now.
Differential Revision: https://phabricator.services.mozilla.com/D10638
--HG--
extra : moz-landing-system : lando
Add reftests that test the ImageRendering property on video (NativeTexture external images), JS-based ImageRendering changes and inequality of results between different ImageRendering settings. Also include a simple h264 mp4 with minimal lossy encoding. OSX fuzzing values determined by try run.
Add reftests that test the ImageRendering property on list-style-images, JS-based ImageRendering changes and inequality of results between different ImageRendering settings.
--HG--
extra : rebase_source : a3c6298364dd5c099d6e1a851b2f20e1a2b48ab9
Add reftests that test the ImageRendering property on video (NativeTexture external images), JS-based ImageRendering changes and inequality of results between different ImageRendering settings. Also include a simple h264 mp4 with minimal lossy encoding. OSX fuzzing values determined by try run.
--HG--
extra : rebase_source : 7eafbc57935659f73894cab83757dffe1f7e7c60
Add additional reftests that test for JS-based changes to the ImageRendering field. Also test for differences between different ImageRendering settings.
--HG--
extra : rebase_source : 3b839704392f0c7b7b91bdaf8f978eb3778409b9
shape-outside, shape-margin, shape-image-threshold have been shipped in Firefox
62. We can remove the preference.
The change in devtools/shared/css/generated/properties-db.js is generated by
"./mach devtools-css-db"
The actual shape-image CORS mode tests in file_shape_outside_CORS.html are
moved into test_shape_outside_CORS.html because we don't need the <iframe>
trick to enable the feature.
Differential Revision: https://phabricator.services.mozilla.com/D10804
--HG--
extra : moz-landing-system : lando
Keywords on the sizing properties in the block axis should behave as
initial values in the flex frame. We store the keywords as enum, instead
of auto or none in nsStyleCoord, so we have to handle it explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D9438
--HG--
extra : moz-landing-system : lando
Also remove specified-value-only keywords, since those are handled
only in Rust code and C++ doesn't need to know about them.
Differential Revision: https://phabricator.services.mozilla.com/D9634
--HG--
extra : moz-landing-system : lando
This implements the selector(<complex-selector>) syntax for @supports.
See https://github.com/w3c/csswg-drafts/issues/3207 for explainer and
discussion.
Probably would should wait for that to be sorted out to land this, or maybe we
should put it behind a pref to get the code landed and change our
implementation if the discussion there leads to a change.
Differential Revision: https://phabricator.services.mozilla.com/D8864
--HG--
extra : moz-landing-system : lando
It's not really invalidated anywhere, and the float manager code only checks for
float region changes. Extend it so that it knows about shapes as well, and avoid
reframing due to a bogus nsChangeHint_ScrollbarChange which really meant to be
UpdateOverflow, which really is useless in this situation..
Differential Revision: https://phabricator.services.mozilla.com/D7583
The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
--HG--
extra : amend_source : 05dc9a320afeb1d58981e2bd8bc47b435999f2f9
To avoid trimming pixels at the top / left.
This makes it closer to non-WR[1], and fixes both the checkboxes getting
cut off and the master password field.
[1]: non-WR at least at 124 scaling on a hiDPI display is still perfect, though I saw nin symmetric borders at other resolutions, so we might be able to improve here further.
Differential Revision: https://phabricator.services.mozilla.com/D7251
--HG--
extra : moz-landing-system : lando
The animation in this reftests runs on the compositor. In the mean time,
reftest harness waits for the state where there is no pending paint in the
initial phase (STATE_WAITING_TO_FIRE_INVALIDATE_EVENT, i.e. before sending
a MozReftestInvalidate event). So if the animation starts running on the
compositor before a MozReftestInvalidate event is received, it means that
the reftest harness has to wait for the 'no pending paint' state until the
animation finishes because the reftest harness keeps flushing styles in the
initial phase which means the animation causes a paint on every flush.
To avoid above situation, we start the animation in question after we get a
MozReftestInvalidate event.
Differential Revision: https://phabricator.services.mozilla.com/D7681
--HG--
extra : moz-landing-system : lando
This revert reftest changes in bug 1431255 Part VIII (c42039f3ffe7)
so that we could test UA Widget in these tests.
Depends on D5085
Differential Revision: https://phabricator.services.mozilla.com/D7543
--HG--
extra : moz-landing-system : lando
Judging from the description in comment 3 and the fact that this test started
failing shortly after bug 1308876 landed, it is highly likely that this test is
being hit by the same issue as bug 1428670.
This also makes sense given that this test is supposed to test the clamping of
the effective container width for font inflation by the actually visible area of
that frame - be that the viewport for a top level document as in bug 1428670, or
the width of an <iframe> as in this test.
Without the patches for bug 1428670, this test is still failing very frequently.
With those patches applied on the other hand, no more failures are encountered.
Differential Revision: https://phabricator.services.mozilla.com/D5580
--HG--
extra : moz-landing-system : lando
Before bug 1308876, child frames marked themselves as dirty during reflow if
their parent was dirty, too. After bug 1308876, the point where dirtiness is
being propagated to a frame's descendants has been shifted: Now, dirty parents
are responsible for marking all their children as dirty, too, when the parent
starts reflowing.
This means that if a frame wants to mark a whole subtree as dirty *during its
own* reflow, it's no longer sufficient to just mark the root of the subtree as
dirty and then rely on all further children marking themselves as dirty as well
when reflow reaches them.
The font inflation code is one such case. When the font inflation data on a font
inflation flow root has become dirty, or we're resizing the top-level frame
(which because of the effective container width clamping from bug 707855 can
affect the font inflation font size as well), we now need to explicitly mark all
affected children as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D5577
--HG--
extra : moz-landing-system : lando
The failure mode this test is testing is the following:
Apart from the relevant preferences (which cannot change without reloading the
page, so they're not relevant in this case), the magnitude of font size
inflation for all content governed by a particular font inflation flow root
depends on the flow root's effective container width, which is calculated by
taking the smaller of the following two values:
- The font inflation flow root's calculated NCAIsize.
- The ISize of the PresContext's currently visible area.
Minimum font size for font inflation then scales linearly with the effective
container width.
While for a plain document without frames, the visible area normally
corresponds to the viewport size, the MobileViewportManager will only calculate
the viewport after the "load" event or the first paint, whichever is sooner.
This means that the initial reflow will proceed using the current window
dimensions (on mobile this is corresponding to the display size) for the
currently visible area, which in portrait mode typically means around
300 - 500 px width.
After the MVM has done its viewport calculations, we'll reflow again using the
new viewport size as our visible area. For non-mobile friendly pages where font
inflation is relevant, the standard viewport width is 980 px.
If a font inflation flow root is wider than the initial window size, this means
that its effective container width is governed by the visible area and will
therefore increase during the second reflow, as will correspondingly font
inflation's minimum font size.
While the font inflation code detects changes in a font inflation flow root's
NCAISize, respectively ISize resizes of the top-level (Viewport)Frame, after bug
1308876 it no longer correctly marks all descendants of the affected flow root
as dirty. If the text is contained inside an element with a fixed width, which
has therefore been unaffected by the viewport width change, this means that
we'll skip reflow for that text entirely, so the text gets rendered at the new,
increased font size, but continues using the old layout laid out assuming the
smaller initial font size.
I didn't manage to force the visible area to be larger than the initial window
size of 800 px using meta viewport tags, so I'm adjusting browser.viewport.
desktopWidth for this test instead. This also more closely mimics the real-life
failure case described above, where the viewport width gets set to a value
larger than the initial window size through the special desktop page viewport
width handling.
Differential Revision: https://phabricator.services.mozilla.com/D5579
--HG--
extra : moz-landing-system : lando
Judging from the description in comment 3 and the fact that this test started
failing shortly after bug 1308876 landed, it is highly likely that this test is
being hit by the same issue as bug 1428670.
This also makes sense given that this test is supposed to test the clamping of
the effective container width for font inflation by the actually visible area of
that frame - be that the viewport for a top level document as in bug 1428670, or
the width of an <iframe> as in this test.
Without the patches for bug 1428670, this test is still failing very frequently.
With those patches applied on the other hand, no more failures are encountered.
Differential Revision: https://phabricator.services.mozilla.com/D5580
--HG--
extra : moz-landing-system : lando
Before bug 1308876, child frames marked themselves as dirty during reflow if
their parent was dirty, too. After bug 1308876, the point where dirtiness is
being propagated to a frame's descendants has been shifted: Now, dirty parents
are responsible for marking all their children as dirty, too, when the parent
starts reflowing.
This means that if a frame wants to mark a whole subtree as dirty *during its
own* reflow, it's no longer sufficient to just mark the root of the subtree as
dirty and then rely on all further children marking themselves as dirty as well
when reflow reaches them.
The font inflation code is one such case. When the font inflation data on a font
inflation flow root has become dirty, or we're resizing the top-level frame
(which because of the effective container width clamping from bug 707855 can
affect the font inflation font size as well), we now need to explicitly mark all
affected children as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D5577
--HG--
extra : moz-landing-system : lando
The failure mode this test is testing is the following:
Apart from the relevant preferences (which cannot change without reloading the
page, so they're not relevant in this case), the magnitude of font size
inflation for all content governed by a particular font inflation flow root
depends on the flow root's effective container width, which is calculated by
taking the smaller of the following two values:
- The font inflation flow root's calculated NCAIsize.
- The ISize of the PresContext's currently visible area.
Minimum font size for font inflation then scales linearly with the effective
container width.
While for a plain document without frames, the visible area normally
corresponds to the viewport size, the MobileViewportManager will only calculate
the viewport after the "load" event or the first paint, whichever is sooner.
This means that the initial reflow will proceed using the current window
dimensions (on mobile this is corresponding to the display size) for the
currently visible area, which in portrait mode typically means around
300 - 500 px width.
After the MVM has done its viewport calculations, we'll reflow again using the
new viewport size as our visible area. For non-mobile friendly pages where font
inflation is relevant, the standard viewport width is 980 px.
If a font inflation flow root is wider than the initial window size, this means
that its effective container width is governed by the visible area and will
therefore increase during the second reflow, as will correspondingly font
inflation's minimum font size.
While the font inflation code detects changes in a font inflation flow root's
NCAISize, respectively ISize resizes of the top-level (Viewport)Frame, after bug
1308876 it no longer correctly marks all descendants of the affected flow root
as dirty. If the text is contained inside an element with a fixed width, which
has therefore been unaffected by the viewport width change, this means that
we'll skip reflow for that text entirely, so the text gets rendered at the new,
increased font size, but continues using the old layout laid out assuming the
smaller initial font size.
I didn't manage to force the visible area to be larger than the initial window
size of 800 px using meta viewport tags, so I'm adjusting browser.viewport.
desktopWidth for this test instead. This also more closely mimics the real-life
failure case described above, where the viewport width gets set to a value
larger than the initial window size through the special desktop page viewport
width handling.
Differential Revision: https://phabricator.services.mozilla.com/D5579
--HG--
extra : moz-landing-system : lando
This test now passes with WebRender enabled, but it's still fuzzy with WebRender
disabled, so just enable it when WebRender is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D7157
--HG--
extra : moz-landing-system : lando
Mostly straight-forward, the bordercol.css changes are just color renames, but
that file had bogus newlines and such so it looks much bigger.
Differential Revision: https://phabricator.services.mozilla.com/D6604
See the discussion in https://github.com/servo/webrender/issues/1280. I think we
should do this sooner rather than later.
Need to update a couple reftests to hardcode the new colors, waiting on try for
that but should be trivial.
This makes a few more tests pass which are just marked as failure in bug 1487407,
because I implementing the border-collapsing reusing a bunch of Gecko code,
including the table 3d border stuff.
Differential Revision: https://phabricator.services.mozilla.com/D6565
The previous border-collapse beveling implementation assumed that there would
only be one beveled border per side in the whole table, which is... not true at all.
So a bunch of borders ended up clobbering other values in mBevelBorders and
never getting painted.
I'm actually somewhat scarily surprised that only this reftest seems to fail
without this patch...
Here we reuse most of the existing one-off beveling / border rendering support
in nsCSSRendering, and convert the Gecko bevels into a WebRender display list
using rects and borders. This is only remotely possible thanks to Gecko not
supporting dotted / dashed beveled borders :)
This would slightly easier and presumably also more efficient with a triangle
display item in WR instead of (ab)using the border display item to render the
bevel, but this is probably relatively edge-casey so maybe not worth it... In
any case I've left a TODO comment there, that can be a nice followup if we deem
it worth it.
Anyway, I'm _so_ sorry for the border trick, I was this (||) close to go and
rewrite our border collapsing code, but after a few tries I realized it'd take
me a whole lot of time (instead of the day that this has taken me).
Differential Revision: https://phabricator.services.mozilla.com/D4793
This code is no longer necessary since we now invalidate using Display List
Based Invalidation instead of using recursive calls up the frame tree.
The tests that are marked as failing have only been passing due to a bug in the
code that's being removed from nsSVGIntegrationUtils.cpp which coincidentally
hides the fact that we are actually invalidating in those tests given their
particular structure (which the tests are supposed to be checking we're not
doing).
Differential Revision: https://phabricator.services.mozilla.com/D6850
--HG--
extra : rebase_source : cb95359d694dafeca915a22b3c48f580a69679ef
extra : amend_source : 7074f5837170ce0a9243811291782f689666e122
