This grows the selector struct, but only in 32-bit, since in 64-bit we take
space from the alignment padding that we're paying due to having the size of the
slice as a word.
Depends on D32644
Differential Revision: https://phabricator.services.mozilla.com/D32645
--HG--
extra : moz-landing-system : lando
This uses the bit added for tracking part attributes in order to avoid doing
wasted work.
Depends on D32643
Differential Revision: https://phabricator.services.mozilla.com/D32644
--HG--
extra : moz-landing-system : lando
I think that, given ::part() right now (without forwarding) cannot affect
descendants (and eager pseudo-elements are handled as part of the normal element
restyling process), it is not worth the effort to add more complex invalidation.
But we can always re-evaluate.
Depends on D32642
Differential Revision: https://phabricator.services.mozilla.com/D32643
--HG--
extra : moz-landing-system : lando
Still does nothing, since we still do not collect part rules, but this is all
the plumbing that should allow us to invalidate parts when attributes or state
change on their ancestors.
Depends on D32641
Differential Revision: https://phabricator.services.mozilla.com/D32642
--HG--
extra : moz-landing-system : lando
I need this to make style invalidation work with Shadow Parts in a way that's
fast. If something in the ancestor shadow root or any of its ancestor changes,
that makes a ::part() selector change, I don't want to walk the whole shadow
tree over and over in order to find the parts that I need to restyle.
Unfortunately we cannot just use the mutation observer setup from ShadowRoot
since, unlike for slotted elements, there's no restriction of where a part can
appear in the shadow tree.
That means that the regular nsIMutationObserver notifications don't quite cut
it, since we'd get notified only of subtree roots and we'd need to tree-walk
around in order to figure out if we have any new part.
I thought that I was going to be able to share more code with other bits if I
moved them away from nsIMutationObserver, thus bug 1554498, but in the end it
was not the case, so here's the "without bug 1554498" version of the patch.
The patch on top of that bug (that as I mention in the commit message I'm
ambivalent about whether we should land or not) should be pretty similar either
way.
Differential Revision: https://phabricator.services.mozilla.com/D32641
--HG--
extra : moz-landing-system : lando
Changes:
- updated expected outcomes for previously failing tests that now pass on macosx1014
Differential Revision: https://phabricator.services.mozilla.com/D34447
--HG--
extra : moz-landing-system : lando
The idea is to check IsBidiSplittable() in more places to prevent fixed
continuations created by column-span from becoming fluid ones.
Differential Revision: https://phabricator.services.mozilla.com/D34093
--HG--
extra : moz-landing-system : lando
This reverts the modification to nsBidiPresUtils.cpp in Bug 1520722 Part
2, but keeps the test added. Next part will fix the problem in a proper
way.
Differential Revision: https://phabricator.services.mozilla.com/D34092
--HG--
extra : moz-landing-system : lando
Changes:
- move xpcshell from macosx1010 to macosx1014
- updated regex for macosx1014 xpcshell to run on 2 chunks for all variants (for now)
Differential Revision: https://phabricator.services.mozilla.com/D34561
--HG--
extra : moz-landing-system : lando
We remove the debugging hooks that were added to check to see whether a DLL
was loaded, as we can just as easily check that by querying the loader itself.
Plus, we shouldn't be exporting a bunch of test-only loader hooks from mozglue
in our release builds, which is what we are currently doing.
We also remove Injector, InjectorDLL, and TestDLLEject, as these tests can
just as easily be done from within TestDllBlocklist by creating a thread with
LoadLibrary* as the entry point. The CreateRemoteThread stuff, while a more
accurate simulation, has no material effect on whether or not the thread
blocking code works.
Differential Revision: https://phabricator.services.mozilla.com/D34444
--HG--
extra : moz-landing-system : lando
Changes:
- added skip-If statements for some crashtest items that fail on macosx1014
- removed `crashtest` from `macosx64` test sets, with the consequence that `macosx64-qr-tests` test set is removed, with cascading effects to the test-platforms definitions that used only `macosx64-qr-tests`
Differential Revision: https://phabricator.services.mozilla.com/D34448
--HG--
extra : moz-landing-system : lando
The fuzziness in the position-dynamic-changes reftests seems nondeterministic.
The fuzziness annotations in the previous patch were what I got after a few
iterations of do-a-try-push-and-update-annotations, but there are still more
failures showing up in subsequent try pushes. I visually checked all the
failures and they are all just fuzzy in different places, but intermittent.
This patch updates the fuzziness annotations on these tests to the maximum
that I encountered on any test, which is (2, 1382).
I'm keeping this as a separate patch because I think it might be valuable
in version control history to have the actual numbers seen on try which
are in the previous patch.
Depends on D34538
Differential Revision: https://phabricator.services.mozilla.com/D34539
--HG--
extra : moz-landing-system : lando
There are a number of failures, for which I've filed separate bugs.
And then a lot of fuzziness. I manually inspected the reftest analyzer
results on try pushes to distinguish failures vs fuzziness.
Depends on D34537
Differential Revision: https://phabricator.services.mozilla.com/D34538
--HG--
extra : moz-landing-system : lando
It looks like bug 1321412 changed the number of params but didn't update the
template parameter, and then bug 1364221 followed its example of not matching
the template parameter to the actual number of params. As a result we're
passing an array with one garbage pointer to the callee, and it just happens
that the callee doesn't examine that pointer. But that's about to change.
Differential Revision: https://phabricator.services.mozilla.com/D34234
--HG--
extra : moz-landing-system : lando
Turns out we do have saturated arithmetic in mfbt, I just missed it.
Also, use just an uint32 for the heuristic. Text length is a uint32 anyway, and
it's unlikely we want to decide anything when the value is over the max uint32
value.
Differential Revision: https://phabricator.services.mozilla.com/D34496
--HG--
extra : moz-landing-system : lando
This patch adds a `known_intermittent_statuses` attribute to the `StatusHandler`
class, allowing it to keep a count of expected intermittents for future use.
Additionally, known intermittents are not recorded as `unexpected_statuses` but
are recorded as `expected_statuses`.
testing/mozharness/mozharness/mozilla/structuredlog.py is directly affected by
this change and has been updated to also reflect `known_intermittent_statuses`.
However, it may require a test to be written to check this addition.
The `StatusHandler` test has been added to, ensuring this patch works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D33086
--HG--
extra : moz-landing-system : lando
This allows to have more meaningful warning group messages, i.e.
"Content Blocking" is turned into something like "The resource at
'<URL>' was blocked because content blocking is enabled".
This is done by parsing the message of the first warning to put
in the group, and replacing the URL with a generic placeholder.
We take this as an opportunity to decouple content blocked messages
and storage access blocked ones, as they have slightly different
meanings and consequences.
Tests are updated to match the new labels, and a new test is
added to make sure that we can have multiple warning group in a
single "page navigation" session.
Differential Revision: https://phabricator.services.mozilla.com/D34339
--HG--
extra : moz-landing-system : lando
