Now, callers of EventUtils.synthesizeKey() don't need to specify
KeyboardEvent.code value anymore if they assume that active keyboard layout
is US keyboard layout.
Note that this patch changes the meaning of only test_bug551434.html.
Some callers in it don't match the key value and code value but that looks
like that they don't checking such odd keyboard events. So, they must be
bug of the test.
MozReview-Commit-ID: Itxo7yZ9rkK
--HG--
extra : rebase_source : 856ef3715c924ca16e993ea57d92d1243b5cc6be
The keyframe stuff runs from animation building, which needs clean styles
already.
Same for counter styles, they run from a well-defined point in time where rules
should be up-to-date already.
The canvas stuff needs no stylist access mostly, since it's only used to compute
a couple font-related things.
MozReview-Commit-ID: 3Vh1wzeaYl3
--HG--
extra : rebase_source : 9de148782365e128222a46414d87235b596a1660
This patch does basically throttle animations on visibility:hidden element
and unthrottle it once the animating element became visible or a child of the
animating element became visible. But still there are some cases that we don't
throttle such animations perfectly. For example;
div.style.visibility = 'hidden'; // the 'div' has no children at this moment
div.animate(..);
// The animation is throttled
div.appendChild(visibleChild);
// The animation isn't throttled
visibleChild.style.visibility = 'hidden';
// Now the animation should be throttled again, but actually it's not.
To throttle this case properly, when the |visibleChild|'s visibility changed
to hidden, we would need to do either
1) Check all siblings of the |visibleChild| have no visible children
or
2) The parent element stores visible children count somewhere and decrease it
and check whether the count is zero
To achieve 1) we need to walk up ancestors and their siblings, actually it's
inefficient.
2) is somewhat similar to what we already do for animating images but it's hard
to reuse it for CSS animations since it does not take into account that
descendants' visibilities.
Another example that this patch does not optimize is the the case where
animating element has children whose visibility is inherited and the element
itself initially visible something like this;
let child = document.createElement('div'); // child visibility is 'inherit'
div.appendChild(child);
div.animate(..); // the 'div' is visible
// The animation isn't throttled since the animating element is visible
div.style.visiblily = 'hidden';
// Now the animation should be throttled, but it's not since this patch does
// not descend down all descendants to check they are invisible or not when the
// animating element visibility changed to hidden.
This patch adds a test case for this case introduced with todo_is().
Another test case added in this patch fails if we don't use
nsPlaceholderFrame::GetRealFrameFor() in HasNoVisibleDescendants().
MozReview-Commit-ID: BJwzQvP9Yc4
--HG--
extra : rebase_source : e56505706bb2799b59bbfb3bbcce4a9ce86892f4
This new change hint doesn't influence layout so that it can be regarded
as nsChangeHint_Hints_CanIgnoreIfNotVisible. Note that if visibility changed
from collapse or to collapse, we set NS_STYLE_HINT_REFLOW separetely.
MozReview-Commit-ID: AirDWeBYVKG
--HG--
extra : rebase_source : a462845ac2d8280986bb8db5e6482bf401f65322
Replace the one use of it with element.focus().
MozReview-Commit-ID: 5qK6yfyuRoY
--HG--
extra : rebase_source : f6f9a738c6ebf2201dbd6a2ac5fe476797e0adb5
In partiuclar: nsCSSRenderingBorders.cpp is already using IsBoxDecorationSlice
and BoxDecorationRectForBorder. This would be compile error, except that we
happen to unify the two .cpp files together. This patch promotes these two
functions (along with a closely-related function, for consistency).
MozReview-Commit-ID: 4sWj5Rb9QSw
--HG--
extra : rebase_source : 542f0200a82121f13626c9c2d129fcb5c441ff45
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
It doesn't fill the ancestors of the first frame if aCommonAncestor is null,
which means that we get garbage afterwards.
MozReview-Commit-ID: G85dv7KM1Xd
In particular, even when there are no frames, we may have used the rule
cascades / stylist data (for different stuff, like font-feature-values, thus the
regressing bug).
Using the old rule cascades / stylist data without knowing it has changed is
wrong, thus the bug.
Now that media query change stuff is async and has a well-defined processing
point, we should be able to just call it without too much worry.
Also note that at the point the extra hints are passed, if there's no root frame
/ elements are not styled / etc, we'll optimize away the change hint.
The test-case intermittently fails without this patch, but I didn't manage to
make a better one, unfortunately :(
MozReview-Commit-ID: LY2HRIlAKHX
The reason why bug 1355721 regressed this is because in non-e10s we definitely
flush before parsing the standards quirks-mode. And bug 1355721 introduced an
unconditional UpdateStylistIfNeeded, unless the counter style / font
equivalents.
That means that the stylist wouldn't remain on its initial state after the first
flush, which itself means that when the compat mode changed, the UA and user
rules were already on the stylist with the quirks mode keys. That makes
class-names be keyed in ascii lowercase.
After that no user style changed, so no rebuild happens for the cascade data in
the user origin, so we keep looking at the wrong keys indefinitely.
MozReview-Commit-ID: 25dD2bca3tN
This will make it easier to handle it properly for Shadow DOM, though this patch
doesn't do that.
This also makes some method inline and infallible for convenience, since nobody
checks the errors anyway.
MozReview-Commit-ID: Hq3erAUs5tf
This reverts back to just returning failure rather than warning and returning
failure in GetInLink.
--HG--
extra : rebase_source : ce32635e3c301164c3296db71fcab624e256ac93
Add a command CreateClippedDrawTarget to DrawTarget, which takes the
max required size and a transform between this draw target and the one
to be created. The created draw target may have its size clipped to
the size of this draw target, transformed to the new target's
space. This means that the new surface will be large enough so
that it is rendered to this draw target correctly, but not necessarily
any larger.
Usually this will just create a draw target of the requested size, for
simplicity. However, when replaying a recorded draw target we do clip
the size to the base draw target's size. This is done using a
DrawTargetTiled, so when applying the mask in PopLayer, we must take
the SourceSurface's offset in to account.
MozReview-Commit-ID: 89ONElphzLu
--HG--
extra : rebase_source : 7eebeb66a2686a7b6f4ade36f3004ebb06abc2fe
In particular, even when there are no frames, we may have used the rule
cascades / stylist data (for different stuff, like font-feature-values, thus the
regressing bug).
Using the old rule cascades / stylist data without knowing it has changed is
wrong, thus the bug.
Now that media query change stuff is async and has a well-defined processing
point, we should be able to just call it without too much worry.
Also note that at the point the extra hints are passed, if there's no root frame
/ elements are not styled / etc, we'll optimize away the change hint.
The test-case intermittently fails without this patch, but I didn't manage to
make a better one, unfortunately :(
MozReview-Commit-ID: LY2HRIlAKHX
--HG--
extra : rebase_source : ed7d57cbdf4d08510ad62e88818a754b46441ac4
This fixes a bug where EnsureEventualDidPaintEvent needs to be called separately for each transaction id, but we skip it since mFireAfterPaintEvents is still true from the previous paint.
We now track the equivalent state by checking for the presence of mTransactions[aTransactionId], and correctly schedule an eventual didpaint for each id.
MozReview-Commit-ID: JnRTycGEyom
--HG--
extra : source : 39ffcc432d0c04641acf3be018f1919a9d620893
This fixes a bug where EnsureEventualDidPaintEvent needs to be called separately for each transaction id, but we skip it since mFireAfterPaintEvents is still true from the previous paint.
We now track the equivalent state by checking for the presence of mTransactions[aTransactionId], and correctly schedule an eventual didpaint for each id.
MozReview-Commit-ID: JnRTycGEyom
Changing the last retrieval of the nsIWebBrowserPrint in
printpreview_bug396024_helper.xul caused problems because doing it via the
docshell interrupts the load that triggers run5.
So, I moved the test to run5, which is more consistent with run2 and run3.
I then realised that the frames would have switched anyway, so I changed it to
retrieve frame[0] for the last test, which I think makes more sense.
It's not totally clear to me what this was testing originally or whether it
continued to do so after the addition of the second iframe a long time ago.
The invalid variable test for #if{,n}def was only checking that the
first character in the variable was alphanumeric or underscore, not
the other characters.
More generally, preprocessor instructions were also cut out such that
whitespaces before and after arguments were part of the arguments.
Subtly, some legitimate strings end with what, in ISO-8859-1, is
considered as whitespaces, and because the preprocessor largely works
on byte strings (str), and because the regexps are using re.U, those
characters (e.g. 0xa0) that can legitimately appear in byte strings of
UTF-8 encoding, are treated as whitespaces. So we remove the re.U from
the instruction regexp, so that only plain ascii whitespaces only are
stripped out.
There's one place in layout/tools/reftest/manifest.jsm that was using
a broken pattern, making the test never true, which, once fixed, unveils
broken tests, so the branch that was never used is removed.
--HG--
extra : rebase_source : b695dec025c55aee0e50f2a0047278fe9c849c9e
This patch makes a bunch of tests start passing, so it removes some 'fails' annotations.
MozReview-Commit-ID: DCxkXFnztLc
--HG--
extra : rebase_source : 53f4d38c0bf8915fc420f971ba36f4c0ad7aa8ed
This patch doesn't change behavior; it's simply a rename.
I'm also fixing one mistyped mention of this variable in a comment in
nsFlexContainerFrame.cpp. (The comment had "Reflow" rather than "Height" in
its mention of this variable-name.)
MozReview-Commit-ID: KRW7FCVSlto
--HG--
extra : rebase_source : 2a27ea3bf9d3eabc437db398d24e374ce48ba677
In particlar, this patch:
- ...renames a bunch of 'auto'-BSize-measurement functions/variables from
"Height" to "BSize". (I thought about splitting this part out, but
typically the correctness of the renames was intrinsically tied to the logic
generalizations that I'm performing here, and vice versa, so it seemed
clearest to group it all together.)
- ...replaces some calls to IsMainAxisHorizontal() with the more general
"FlexItem::IsInlineAxisMainAxis()" API, for cases when we're reasoning about
whether a flex item's main-size is really just its (easier-to-resolve) ISize.
- ...replaces some calls to IsCrossAxisHorizontal() with either
IsColumnOriented() or FlexItem::IsInlineAxisCrossAxis() (depending on
whether we're reasoning about the flex container's cross-size vs. a flex
item's cross size).
This makes a bunch of tests start passing (including a "received" w3c
reftest/wpt-test), so this patch also removes some failure annotations.
MozReview-Commit-ID: 3uR1mOzvytX
--HG--
extra : rebase_source : 40f4e7dd6aacfb4f267d2f4d217fbf84befb5ebf
This patch doesn't affect behavior -- it's just adding a new member-var &
accessor with no usages. The next patch in the series will add some usages.
MozReview-Commit-ID: NKBvKnb7Jw
--HG--
extra : rebase_source : aff89907bfef41a8fa3ff076264a2b7a72c36e27
This patch doesn't affect behavior. It simply reorders a member variable to be
near the beginning of the FlexItem class, so that the next patch in this series
can use that member-variable when initializing another member in the
constructor init list. (You're only allowed to use earlier member-vars like
this, since member-vars get initialized in order.)
MozReview-Commit-ID: 9v4Dr0Ir6i7
--HG--
extra : rebase_source : ff0ebd63c4a88017e8211a77049e79469b4e9858
This patch includes two tests with a row-oriented vertical-writing-mode
flex container, and one test with a column-oriented flex container.
(And then the next patch in this series will add some more column-oriented
variants as copies of this patch's last test.)
Note: All of the tests in this patch *already* pass (unlike other tests added
in this bug), so they don't have a 'fails' annotation in reftest.list.
MozReview-Commit-ID: oaMvhjxv16
--HG--
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-010-ref.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-011-ref.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-010.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-011.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-010-ref.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-012-ref.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-010.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-012.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-010-ref.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-013-ref.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-010.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-writing-mode-013.html
extra : rebase_source : f1cdba662ceb617d4b3a6b082f5af5ed7800342d
In nearly all of these cases, the writing-mode tweak isn't supposed to affect the
test's rendering, so I'm reusing the original test's reference case.
The only exception: a few of the copied tests have some "spacer" elements with
`display:inline-block`, which stack horizontally (in the inline axis) in the
original testcase. In the new copy of the test, I'm dropping that inline-block
styling, so that they continue to stack horizontally (in the vertical writing
mode's block axis) and continue to match the original reference case.
These tests are marked as 'fails' for now, but they'll start passing as of a
later patch in this series.
MozReview-Commit-ID: JLzT61JHudz
--HG--
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-basic-block-horiz-001.xhtml => layout/reftests/w3c-css/submitted/flexbox/flexbox-basic-block-horiz-001v.xhtml
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-basic-block-vert-001.xhtml => layout/reftests/w3c-css/submitted/flexbox/flexbox-basic-block-vert-001v.xhtml
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-basic-canvas-horiz-001.xhtml => layout/reftests/w3c-css/submitted/flexbox/flexbox-basic-canvas-horiz-001v.xhtml
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-basic-canvas-vert-001.xhtml => layout/reftests/w3c-css/submitted/flexbox/flexbox-basic-canvas-vert-001v.xhtml
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-001.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-001v.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-002.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-002v.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-003.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-003v.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-004.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-004v.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-005.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-005v.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-006.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-006v.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-mbp-horiz-002b.xhtml => layout/reftests/w3c-css/submitted/flexbox/flexbox-mbp-horiz-002v.xhtml
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-mbp-horiz-003.xhtml => layout/reftests/w3c-css/submitted/flexbox/flexbox-mbp-horiz-003v.xhtml
extra : rebase_source : ccb97cb2adce394b7d2c4e39b6db023c8ecae105
Inner classes already have the same visibility as member function of the outer
class, so there's no need to explicitly make them friends.
MozReview-Commit-ID: 3Aovsj0JO2S
--HG--
extra : rebase_source : 8ba686b3904949147c4584eb949f1e3dd5f0e452
In some cases there are imported tests where the same test is compared against
two reference pages, once as == and once as !=. Webrender is currently failing
the == tests but not the != tests. However there is no way to annotate this
precisely in the failures.list file, so we had previously marked the tests
as random-if. This patch modifies the import-tests.py to recognize a ref:<file>
argument in failures.list to match the reference file as well, and uses it to
clarify the webrender reftest expectations.
MozReview-Commit-ID: 6nAXoCQDreI
--HG--
extra : rebase_source : 93633ed6f62ccfb4b28ebed34943781350c4c831
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This patch does basically throttle animations on visibility:hidden element
and unthrottle it once the animating element became visible or a child of the
animating element became visible. But still there are some cases that we don't
throttle such animations perfectly. For example;
div.style.visibility = 'hidden'; // the 'div' has no children at this moment
div.animate(..);
// The animation is throttled
div.appendChild(visibleChild);
// The animation isn't throttled
visibleChild.style.visibility = 'hidden';
// Now the animation should be throttled again, but actually it's not.
To throttle this case properly, when the |visibleChild|'s visibility changed
to hidden, we would need to do either
1) Check all siblings of the |visibleChild| have no visible children
or
2) The parent element stores visible children count somewhere and decrease it
and check whether the count is zero
To achieve 1) we need to walk up ancestors and their siblings, actually it's
inefficient.
2) is somewhat similar to what we already do for animating images but it's hard
to reuse it for CSS animations since it does not take into account that
descendants' visibilities.
Another example that this patch does not optimize is the the case where
animating element has children whose visibility is inherited and the element
itself initially visible something like this;
let child = document.createElement('div'); // child visibility is 'inherit'
div.appendChild(child);
div.animate(..); // the 'div' is visible
// The animation isn't throttled since the animating element is visible
div.style.visiblily = 'hidden';
// Now the animation should be throttled, but it's not since this patch does
// not descend down all descendants to check they are invisible or not when the
// animating element visibility changed to hidden.
This patch adds a test case for this case introduced with todo_is().
Another test case added in this patch fails if we don't use
nsPlaceholderFrame::GetRealFrameFor() in HasNoVisibleDescendants().
MozReview-Commit-ID: BJwzQvP9Yc4
--HG--
extra : rebase_source : ceb95bdce1042cbfc16751d6d023fc6feee5845e
This new change hint doesn't influence layout so that it can be regarded
as nsChangeHint_Hints_CanIgnoreIfNotVisible. Note that if visibility changed
from collapse or to collapse, we set NS_STYLE_HINT_REFLOW separetely.
MozReview-Commit-ID: AirDWeBYVKG
--HG--
extra : rebase_source : 1cd03a78a522b1a6965ba73ebf002ddacb0ab4f2
This replaces reftest's homebrewed chunking algorithm with the one that
all the other test harnesses use in manifestparser.
For now Android will continue to use the reftest based algorithm.
MozReview-Commit-ID: AfUBmQpx3Zz
--HG--
extra : rebase_source : cb513d1b3a54ddeb95ce5861d858aad4492de2a6
Instead of parsing the manifests and running the tests all in one go, this will
spawn an extra Firefox instance at the beginning that does nothing but parse the
manifest and dump them to a file.
This will allow the python harness to load and manipulate the test objects, before
sending them back to the JS harness as a list of tests to run. The main motivation
for this change is to implement run-by-manifest, a mode where we restart the
browser in between every test manifest. But there are other benefits as well, like
sharing the chunking logic used by other harnesses and the ability for the python
harness to stuff arbitrary metadata into the test objects.
For now, Android will continue to parse the manifests and run the tests all in one
go. Converting Android to this new mechanism will be left to a follow-up bug.
MozReview-Commit-ID: AfUBmQpx3Zz
--HG--
extra : rebase_source : 955966c07bb650946c7c0e5706856f028335e850
Currently manifest parsing happens within the StartTests method. This method is
already quite large, and this commit series about to make the logic around
gathering tests a lot more complicated.
This commit pulls the manifest parsing out into a new 'ReadTests' method which
is responsible for retrieving the list of tests (however that may be) and then
calling StartTests.
MozReview-Commit-ID: 6ijOqhNaig
--HG--
extra : rebase_source : 16d4e2debcbe95765c4355b9964f62c7e7a417f1
This is a simple refactor of manifest.jsm.
We'd like to access the test objects from the parsed manifest in python. This
will allow us implement things like runByManifest (to improve intermittent
stability), share the chunking logic used by other harnesses, and much more.
To do this, we need to JSON serialize all of the test objects and dump them
to a file. The python side can then load the file, make modifications, and
send it back to the JS side to run.
The problem is that we turn the test urls into nsIURI objects as soon as they
are parsed, which isn't JSON serializable. This commit is a simple refactor to
delay this from happening. Instead, we will create the urls in reftest.jsm,
after the modified test objects have been loaded from python. This step will
be implemented by the next commit.
MozReview-Commit-ID: 6ijOqhNaig
--HG--
extra : rebase_source : 06acb038a4d3e35b3a4158b81b361a9a0ae54337
All the arrays we're switching to ranged loops can't mutate during the loop
since are locals or not referenced from other places.
MozReview-Commit-ID: C2N73HMMeNW
--HG--
extra : rebase_source : 428dd2805cb58b3ac5fcddb549b960f72615bf6f
Just something I noticed while sneaking into bug 1435634.
RemoveElement returns whether the element was actually removed, so no need to
use Contains to bail out.
MozReview-Commit-ID: FryHBV66yRV
Bug 1427292 broke display: contents on non-special MathML elements.
Just for reference, I've manually audited calls to nsIFrame::GetContent() in
MathML and turns out that MathML is pretty well-behaved in that sense (it
inspects the frame tree, then gets the content), so it should work fine with
display: contents / ShadowDOM.
Only exception to that is[1], but that one seems harmless.
[1]: https://searchfox.org/mozilla-central/rev/eeb7190f9ad6f1a846cd6df09986325b3f2c3117/layout/mathml/nsMathMLmactionFrame.cpp#301
So we can enable or implement when the CSSWG pleases.
MozReview-Commit-ID: 8N6kiGyjE4i
--HG--
extra : rebase_source : a80197e39b20bc6ab385a3d0b90628bc4ad81d92
We'll stop dispatching keypress events on web contents for conforming to spec of
UI Events. Some existing tests assumes that keypress events are fired even
when non-printable keys are pressed.
This patch makes them check the pref,
"dom.keyboardevent.keypress.dispatch_non_printable_keys_only_system_group_in_content"
and only listen to keydown event instead of keypress even if the pref is true
and expected key event is not a printable key press.
MozReview-Commit-ID: 6bKoK7dsB0l
--HG--
extra : rebase_source : b3705b0814d5690e00208d0d3315f09f886c6f26
It's the last thing we check before looking into the array, modulo other two
tags, so there should be no need for something more fancy.
MozReview-Commit-ID: 4Wi1fe7jBlN
--HG--
extra : rebase_source : c13394a0b057e28cd922f1d15cb8b149a4204292
This is a new issue that gets linted with flake8 3.5.0. Basically you should
never use a blank except: statement.
This will catch all exceptions, including KeyboardInterrupt and SystemExit
(which is likely not intended). If a catch all is needed, use
`except: Exception`. If you *really* mean to also catch KeyboardInterrupt et
al, use `except: BaseException`.
Of course, being specific is often better than a catch all.
MozReview-Commit-ID: FKx80MLO4RN
--HG--
extra : rebase_source : 7c74a7d0d81f2c984b47aff3a0ee3448b791177b
I left some IgnoredErrorResults for now where people warn on failure. We could
consider adding a WarnOnError() thing or something.
MozReview-Commit-ID: L5ttZ9CGKg0
This should make us agree with other browsers re the serialization of
`"vert" 0`, and with servo after https://github.com/servo/servo/pull/19918
Left try running, may need some test adjustments that I'll send for review if
they're non-trivial.
Differential Revision: https://phabricator.services.mozilla.com/D539
MozReview-Commit-ID: LgIPfn4lfrF
This change is in response to this CSSWG resolution:
"RESOLVED: compute min-width/min-height: auto to auto"
https://github.com/w3c/csswg-drafts/issues/2230#issuecomment-362009042
...which was later clarified as only being applicable to grid/flex items (in
both axes). Other layout modes may get further min-width/min-height
clarification, but for now we'll leave that behavior the same (returning 0 from
getComputedStyle).
MozReview-Commit-ID: 2wLYDAOj9I6
--HG--
extra : rebase_source : c5f384ef5ae906e20a6e10da20c39b0a5eb226eb
Everything that needs them up-to-date will call flush appropriately, there
should be no need to do it manually.
This way we coalesce all the stylist updates until the next style flush in the
best case, or until one of the consumers actually needs them.
MozReview-Commit-ID: BVsxXxhtcKL
--HG--
extra : rebase_source : a41c14689fdcdb30935e16bdb0e757e7140e88e7
This fixes InspectorUtils::getCSSValuesForProperty to return the
correct values for line-style-type.
MozReview-Commit-ID: 72Tes6y15j8
--HG--
extra : rebase_source : fa893f59cafc433f554353cf42d0f9495cdd5b23
The invalid variable test for #if{,n}def was only checking that the
first character in the variable was alphanumeric or underscore, not
the other characters.
More generally, preprocessor instructions were also cut out such that
whitespaces before and after arguments were part of the arguments.
There's one place in layout/tools/reftest/manifest.jsm that was using
a broken pattern, making the test never true, which, once fixed, unveils
broken tests, so the branch that was never used is removed.
--HG--
extra : rebase_source : d1fe8a299203a29c0906ff99054c326acd135000
We no longer assert here when stylo-chrome is enabled.
MozReview-Commit-ID: CbVItBV2Q5V
--HG--
extra : source : 62d4361658b91c2825fae256913016495a9289f6
The test only passes with WebRender enabled. Passing without WebRender
would require implementing CSS filters in the Gecko compositor.
MozReview-Commit-ID: HPgxxuj5iJl
--HG--
extra : rebase_source : 8afbc717d8e086f7a407eb5f0090f30d62d9638b
On a CLOSED TREE, since Android is barfing at the prefs key in the manifest:
runByManifest mode must be enabled to set the `prefs` key
MozReview-Commit-ID: 2oK3CG69s9E
Going forward we should add the more detailed tests to web-platform-tests but
for now if we don't add tests here test_transitions_for_property.html will
complain that a property that we think is not transitionable, does in fact
transition.
MozReview-Commit-ID: DJwVR50U36K
--HG--
extra : rebase_source : 39510dde2c602cfbb13bd05ccd8402fe5c3be5ec
extra : source : 2a0fbd39ee548e2023aade2da993a9c65bf784b6
On Linux, media feature changes is processed after dispatching sizemodechange
event, so we need to wait for the next tick before checking style changes that
caused by the media feature changes.
MozReview-Commit-ID: 2kb0kToXA6e
--HG--
extra : rebase_source : 640739b49c18b410e8610d801d3ea2795380254e
Since we do not support async-transform for individual-transform yet.
MozReview-Commit-ID: gfOzHpjOnQ
(grafted from dd508458f70d5473256a4bfe5a2f6bc665bbac9d)
--HG--
extra : source : dd508458f70d5473256a4bfe5a2f6bc665bbac9d
This will allow us to invoke it from nsAttrValueInlines.h, which can't
include ServoStyleSet.h due to circular dependencies.
MozReview-Commit-ID: BgC7ExyWRn7
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
The accessible caret manager is owned by the event hub, that is owned by the
shell.
All the callers of methods that call FlushLayout on the AccessibleCaretManager
should hold an external reference to the event hub.
Flushing pending notifications can run arbitrary script, that can call Destroy()
on the pres shell (and thus tear down the accessible caret event hub, and the
manager with him).
I don't know why before my change this wasn't crashing badly, but the code as it
was just doesn't look sound to me at all either (maybe I'm misunderstanding
something and I should just revert that patch and give up on having nice
invariants during our flushes..., but I don't think it's the case).
This also adds some sanity-checking that we don't die under our flush.
MozReview-Commit-ID: 4s0UT0fD3TI
See 7.6. in the section '8.1.4.2 Processing model';
https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-8
Note that this dispatching scroll events should be done after we process
WillRefresh() for FlushType::Style observers since main-thread scroll
animations is one of the FlushType::Style observers, that means it affects
scroll events.
Also test_scroll_event_ordering.html was modified to check scroll events happen
before requestAnimationFrame callbacks.
MozReview-Commit-ID: LuV157XoRkJ
--HG--
extra : rebase_source : a22424c248dcd4a3ec0aad8e71b75306c8f7e487