The root cause of the crash was that FlexItem::NeedsFinalReflow
returned false even though the item had a non-empty next-in-flow.
This made the flex container skip the item's reflow and consider
the item's reflow status as COMPLETE, which triggers the removal
of the container's own next-in-flow, which causes the assertions
and eventually the crash.
Differential Revision: https://phabricator.services.mozilla.com/D118420
Python2 is no longer used in testing/mozharness. Hence,all the instances of file 'websocketprocessbridge_requirements.txt' are removed as it is obsolete now.
Differential Revision: https://phabricator.services.mozilla.com/D118214
This enables the following configuration on central / autoland:
> test-linux1804-64-tsan/opt-web-platform-tests-fis-e10s
Differential Revision: https://phabricator.services.mozilla.com/D110555
We were previously constructing some expected values as a list of
StringNode objects due to make_value_node incorrectly calling
make_node for list items. This is wrong as StringNode types can only
be on the lhs of an expression (e.g. if os == "linux") but never on
the right hand side (which is always a ValueNode or ListNode with ValueNode
children).
StringNodes are always serialized with quotes and this was causing
values to flip flop between quoted and unquoted forms in some cases.
Differential Revision: https://phabricator.services.mozilla.com/D115259
The `mozbase` modules were being unconditionally added to the
`sys.path` regardless of the Mach command being run, so there isn't
much value keeping them in a separate file. Besides, all other
source module paths are described in `common_virtualenv_packages`,
why is `mozbase` special?
In the future, we're going to want to make improvements here (such as:
there's a difference between informing mach of first-party code
versus defining which third_party vendored packages should be in scope,
and that workflow difference should be represented in-code).
It's useful to peel out the existing, less useful abstraction before
we can build a stronger one.
Differential Revision: https://phabricator.services.mozilla.com/D117711
Having separate `<name>.pth` files in the virtual environments
isn't providing an advantage. We can simplify configuration
by putting all `pth` adjustments into a single file: `mach.pth`.
Differential Revision: https://phabricator.services.mozilla.com/D117710
Automatic update from web-platform-tests
cc Rename one ARIA test, and update messages.json
--
wpt-commits: 6ce585b845874728b6c7c6bdf312cc1ed12ca4a4
wpt-pr: 29396
Automatic update from web-platform-tests
Update sticky position pushed beyond scrollable range test.
The css-position spec[1] was updated to suggest that sticky positioned
elements are only shifted after layout within their containing block.
This would imply that the now unified behavior across browsers matches
the new spec expectations. This updates the test to match what the
browsers do.
[1] https://drafts.csswg.org/css-position-3/#stickypos-insets
Bug: 752022
Change-Id: Ic95d32948f9088ae4592a3de78d6ac0a58db8183
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2960015
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#892805}
--
wpt-commits: 05ab45fb425416018d4bfa23ee3a65b5d37f593b
wpt-pr: 29368
Automatic update from web-platform-tests
Safe slot reassigment
1. Use GetWithoutInvalidation() instead of Get() in DCHECKs.
We should never call Get() inside of a DCHECK(), because this can
lead to a different code path depending on whether DCHECKs are enabled.
2. Get() should not cause immediate side effects. At most, it should
queue up an invalidation for later processing.
Fixing #1 and #2 were required in order to get past a first set of
errors introduced by the new test.
3. The actual fix -- avoid infinite loop by calling a special
new SlotAssignmentWillChange(), rather than ChildrenChanged(),
where a minimal GetWithoutInvalidation() is called that does not
lead to IsShadowContentRelevantForAccessibility() => FirstChild() =>
RecalcAssignedNodes() => ChildrenChanged() ... (infinite loop).
A simpler potential fix is in CL:2965317 but requires more
research. It's also mentioned in a TODO comment.
Bug: 1219311
Change-Id: Iafaa289f241a851404ce352715d2970172a2e5f8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2961158
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#892778}
--
wpt-commits: 7b9ca7da96108c39142ebf9b6d639d9725beebf4
wpt-pr: 29388
Mats Palmgren
Geoff Brown
Csoregi Natalia
Neil Deakin
Marian-Vasile Laza
Butkovits Atila
Matt Woodrow
Boris Chiou
surajeet310
Andrew Osmond
Andrew Halberstadt
Henrik Skupin
James Graham
Kagami Sascha Rosylight
Joel Maher
Brindusan Cristian
Alexandru Michis
Olli Pettay
Ryan VanderMeulen
Mitchell Hentges
Mark Banner
Gabriele Svelto
Andi-Bogdan Postelnicu
Kris Maglione
moz-wptsync-bot
Michael[tm] Smith
Joey Arhar
Robert Flack
Aaron Leventhal