This method is used when updating the SMIL override style and from Web
Animations' Animation.commitStyles method. By using update we accurately return
false when no change is made to a declaration block.
For SMIL this simply acts as an optimization, meaning we can avoid updating the
SMIL override style ub some cases.
For Animation.commitStyles, however, this allows us to avoid generating
a mutation record. Normally making a redundant change to an attribute *does*
generate a mutation record but the style attribute is different. All browsers
avoid generating a mutation record for a redundant change to inline style.
This is specified in the behavior for setProperty[1] which does not update the
style attribute if updated is false.
[1] https://drafts.csswg.org/cssom/#dom-cssstyledeclaration-setproperty
Differential Revision: https://phabricator.services.mozilla.com/D30871
--HG--
extra : moz-landing-system : lando
Later in this patch series we will add a HashSet<OwningAnimationTarget> member
to EffectCompositor. This patch provides the necessary definitions to support
that.
Differential Revision: https://phabricator.services.mozilla.com/D30320
--HG--
extra : moz-landing-system : lando
According to the procedure to update animations and send events[1] the UA should
update all timelines first and _then_ run a microtask checkpoint.
As a result, when we run callbacks for the finished promise on an Animation they
should see the fully up-to-date state of all animations, regardless of which
timeline they are attached to.
However, that is currently not the case since we run a microtask checkpoint
after updating each individual timeline.
This difference will become more significant later in this patch series when we
introduce another step--removing replaced animations--that _also_ should happen
before we run the microtask checkpoint (so that the promise callbacks always see
a fully-up-to-date state).
This patch makes our handling a little more in line with the spec. It's not
quite the same because it's possible there may be other refresh driver observers
that trigger a microtask checkpoint in between ticking the different timelines
but that case is expected to be rare and fixing it would require maintaining
a separate queue for timeline observers that we run after all other observers--
so it is probably not necessary to fix that case at this stage.
The test added in this patch fails without the code changes in this patch.
[1] https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events
Differential Revision: https://phabricator.services.mozilla.com/D30319
--HG--
extra : moz-landing-system : lando
Animation::UpdateTiming takes a SyncNotifyFlag parameter. This is passed to
UpdateFinishedState where it determines how we handle finish actions.
If it is async we queue a microtask where we re-evaluate if the animation is
finished or not before queuing events / resolving promises.
That allows code like the following to _not_ trigger finish events:
```
const animation = elem.animate({...}, 1000);
animation.currentTime += 1000;
animation.effect.updateTiming({ duration: 2000 });
```
(Since the check that the animation is finished will run in a microtask _after_
the call to updateTiming.)
When the flag is "sync" we still don't _actually_ run the finish actions
entirely synchronously: the finished promise is resolved synchronously, but
resolving a promise actually queues a microtask for each callback. Likewise, the
finish event is queued synchronously, but not dispatched.
Since there should be no opportunity for script to run between when we call
Animation::Tick and when we run the next microtask checkpoint (currently at the
end of DocumentTimeline::WillRefresh but that will change slightly in the next
patch in this series) there is no need to introduce the extra "async" microtask
for re-evaluating an animation's finished state. Instead it should be possible
to use the "sync" finishing behavior. Such a change should be unobservable to
Web content but will reduce indirection somewhat.
Differential Revision: https://phabricator.services.mozilla.com/D30318
--HG--
extra : moz-landing-system : lando
The in-class initializers are easier to maintain since you don't have to try and
match them up with the constructor initializer list (including matching the
order).
Differential Revision: https://phabricator.services.mozilla.com/D30317
--HG--
extra : moz-landing-system : lando
Filters blur(), invert(), etc. can omit argument.
Computed/specified style serialization is a little tricky w.r.t the shortest
serialization principle. Ideally we should serialize `invert(1)` to `invert()`,
but that will be a breaking change, so we always serialize them with an
argument.
Note, Blink/WetKit treat specified (but not computed) style serialization
differently when the specified one is originally without argument. Our
current behavior is the same as pre-Chromium Edge.
Differential Revision: https://phabricator.services.mozilla.com/D31720
--HG--
extra : moz-landing-system : lando
Bug 1548941 restricted under which circumstances we allow the
browser.tabs.remote.autostart pref to turn off e10s. The PGO profileserver.py
script relied on the unittest-required user.js prefs collection to turn off
e10s (see also bug 1196094) via this pref. For PGO builds, we do not set the
MOZ_DISABLE_NONLOCAL_CONNECTIONS env var, which meant that we stopped
honouring the pref to turn off e10s. Unfortunately, this meant that
e10s was inadvertently now switched on for the pgo profiling, which
negatively impacted speedometer on PGO builds (and possibly other tests).
All this change does is re-disable e10s for PGO profiling. We should
investigate how to turn e10s on "properly" for PGO, but we can do that in
bug 1196094, without taking this temporary regression, especially as 68
branches.
Differential Revision: https://phabricator.services.mozilla.com/D31736
--HG--
extra : moz-landing-system : lando
Most of it is not used at this point, this leaves the parts that are used by
MathML, which are minimal.
Differential Revision: https://phabricator.services.mozilla.com/D31706
--HG--
extra : moz-landing-system : lando
In RTL scroll containers, the right most x-axis scroll position is 0 and
leftward scroll positions are negative values. And also
nsLayoutUtils::TransformFrameRectToAncestor, which is used to tell whether the
snap target element is inside the destination snapport or not [1], returns
negative x-axis positions for elements in RTL scroll containers if the element
is positioned at places where the elements are outside of the initial scroll
position (0, 0). So we don't need to tweak snapport postion even in the case
of RTL scroll containers.
Instead, what we needed in the first place is that we choose a proper x-axis
scroll position that the targe element appears inside the snapport.
[1] https://searchfox.org/mozilla-central/rev/11cfa0462a6b5d8c5e2111b8cfddcf78098f0141/layout/generic/nsGfxScrollFrame.cpp#6604-6605,6616-6617
Depends on D31409
Differential Revision: https://phabricator.services.mozilla.com/D31410
--HG--
extra : moz-landing-system : lando
This is part of the effort to get all the other versions of rand out.
Unfortunately the diff is kinda bug because this is the first crate
requiring rand 0.6 which has been split into multiple crates.
Differential Revision: https://phabricator.services.mozilla.com/D30744
--HG--
extra : moz-landing-system : lando
Annotation on main process crashes are written to both the .extra file
(for crash submission) and to the event file so that the browser can
detect the crash when restarting even if the crash report files have
been deleted.
This patch factorizes all the code that writes to both files, cutting
down all the duplicate calls, and fixes an issue with the
BreakpadReserveAddress and BreakpadReserveSize annotations which were
not written to the event file.
Differential Revision: https://phabricator.services.mozilla.com/D31247
--HG--
extra : moz-landing-system : lando
Upon a content process crash or hang crash annotations were incrementally
written into the .extra file starting with the exception handler callback and
then in a number of different places before the file was ready for submission.
This had a number of downsides: since the annotations were directly added to
the file it was impossible to tell which ones were already written at a
certain point in time, additionally some were written twice or even thrice.
The code doing the writing would also behave differently depending on the
contents of the file, the parameters passed to it and the contents of global
variables.
This change overhauls the whole process by keeping the annotations into a
temporary per-crash annotation table which is filled with all the required
annotations before being written out in a single pass when they are ready.
The annotations are gathered from the main process annotation table, the
per-process one (held by the CrashReporterHost) and exception-time specific
ones.
The resulting annotations are slightly different than before the patch: first
of all there are no more duplicate entries in the .extra file and secondly all
content/plugin process hangs annotations are properly filtered, before
annotations that were main process-only would leak into them.
Differential Revision: https://phabricator.services.mozilla.com/D31069
--HG--
extra : moz-landing-system : lando
This removes the XRE_TakeMinidumpForChild() which does not need to be
exposed anymore in the XUL API as well as
IToplevelProtocol::TakeMinidump() which was simply unused.
Differential Revision: https://phabricator.services.mozilla.com/D31062
--HG--
extra : moz-landing-system : lando
This patch sets the screen brightness on the reference Moto G5 and Pixel 2 phones to 50% before starting power tests and resets it to its original value once the test is complete.
Differential Revision: https://phabricator.services.mozilla.com/D31662
--HG--
extra : moz-landing-system : lando
- Put every color in a variable name.
- Add `label:hover` so that the radio input provides visual feedback upon hover.
- Implement "pressed" (`[type="radio"]:active`) and `:focus{border:0}`
to match Photon's design guidelines at
https://design.firefox.com/photon/components/radio-buttons.html
- Implement dark theme for radio inputs (using creative freedom as there
is no Photon guideline for this).
Differential Revision: https://phabricator.services.mozilla.com/D31510
--HG--
extra : moz-landing-system : lando
- Update info.svg to adjust color based on the fill color.
- Use button colors as defined by Photon (without this, the background
of the non-generic buttons are almost indistinguishable when dark
themes are enabled).
- Small refactor of message-bar.css to put all type-specific
declarations in one location.
Differential Revision: https://phabricator.services.mozilla.com/D31509
--HG--
extra : moz-landing-system : lando
Most colors have been replaced with a variable that has the same color
value.
The exception is the border color at the add-on details.
`--grey-90-a20` was replaced with `--in-content-box-border-color`,
whose value is `--grey-90-a30`. This is close enough.
Differential Revision: https://phabricator.services.mozilla.com/D31508
--HG--
extra : moz-landing-system : lando
Brian Birtles
Edgar Chen
Julien Cristau
Mihai Alexandru Michis
Jan Beich
violet
Brian Hackett
Henrik Skupin
Ed Lee
Gijs Kruitbosch
Geoff Brown
Emilio Cobos Álvarez
Hiroyuki Ikezoe
Bastien Orivel
Miko Mynttinen
Gabriele Svelto
Gregory Mierzwinski
Rob Wu