With this commit a few of EventSource's and EventSourceImpl's data
members are now atomic, since a mutex isn't really necessary for
their use case. Also, several data members are now marked const.
Differential Revision: https://phabricator.services.mozilla.com/D101210
Automatic update from web-platform-tests
Ignore layout shifts for adding/removing position:fixed
- Treat position:fixed in scrolling LayoutView as layout shift root
(by checking CompositingReason::kScrollDependentPosition, which
also covers the previous sticky position condition).
- Check whether an object was a layout shift root at the
beginning of PaintPropertyTreeBuilder::UpdateForSelf(). Previously
was_layout_shift_root was incorrect if UpdateFragments() removed
PaintProperties() of the FragmentData.
- Update layout_shift_root_changed in both UpdateForSelf() and
UpdateForChildren(), so that the flag also applies to the object
itself if any paint properties in UpdateForSelf() affected
layout shift root status.
Bug: 1150657
Change-Id: I74a5e3bab93e66483b47eb27a04e7bf2277ee1c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2665761
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#849650}
--
wpt-commits: d47b8fbabcc1de1eca266a9aee12f6d348eee93f
wpt-pr: 27436
Automatic update from web-platform-tests
Tree-scoped references from external SVG use
Fix DCHECK failure. A tree-scoped reference may come from a different
document when the style is applied from sheets in an external reference
for SVG <use>.
Bug: 1172059
Change-Id: Ie687ca54d217ba37fa38471bb7e5024a1b4481f0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2665727
Reviewed-by: Fredrik Söderquist <fs@opera.com>
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#849563}
--
wpt-commits: 28de62292316f8edaec2f0b80359c4c9bf8dae6d
wpt-pr: 27440
Automatic update from web-platform-tests
Don't crash when serializing empty CSSUnparsedValues
The "tokens_" list (which despite its name is really a list of
CSSUnparsedSegments) can be non-empty, but still produce an empty
sequence when tokenized. We're not taking this into account, and can
therefore end up with an empty CSSParserTokenRange, which will DCHECK
when passed to CSSVariableData::Create.
To fix this, move the empty-check until after the CSSParserTokenRange
has been created.
Fixed: 1169941
Change-Id: I3eac2b46dca9999ba5f4b509f8293f604f678198
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2656036
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#849551}
--
wpt-commits: 0b172748d83874a2a8facb588e6a17ac423dd85d
wpt-pr: 27386
Automatic update from web-platform-tests
Replace most `.__proto__` with `Object.getPrototypeOf()` (#27394)
Co-authored-by: Philip Jägenstedt <philip@foolip.org>
--
wpt-commits: 59d28c8f2d91d12533cfd0371acbe473b1825967
wpt-pr: 27394
Automatic update from web-platform-tests
[wpt] Reject python versions <3.6 (#27426)
This commit changes the entrypoint to reject any Python version that is
not 3.6 or higher. It also removes the --py2 and --py3 flags.
We are deliberately doing a rejection rather than a fallback to Python 3
to quickly find any remaining entrypoints using Py2.
--
wpt-commits: 92b1c270d0e8831e84d7264e4cfeb1332fdaec5d
wpt-pr: 27426
Automatic update from web-platform-tests
FormData should not contain an entry for the submitter (#27439)
FormData should not contain an entry for the submit button that was used to submit the form.
--
wpt-commits: c134161fc0bf764b6371189b3aca0f3660f15f24
wpt-pr: 27439
If the activate_all_scroll_frames pref is on we want to never remove a minimal display port, and when a regular display port expires we want to downgrade it to minimal.
If the pref is off it's the same as before except we want to also remove the minimal property when on expiry.
Differential Revision: https://phabricator.services.mozilla.com/D103859
In the case that we have a painted minimal display port apzc knows about the scroll frame already, it just has the minimal amount of painted content. So we can tell apz right away. Note that the async transform for minimal dp's are still the identity so we'll still jank minimap dp's before the painted regular dp reaches the apzc.
Differential Revision: https://phabricator.services.mozilla.com/D103858
This patch is the result of auditing all places that look at the presence or absence of a display port to handle minimal display ports (HasDisplayPort, GetDisplayPort, etc).
Broadly speaking the places were in two categories:
1) things related to painting, that want to consider minimal display ports as display ports for purposes of things like sending over metadata and separating out layers.
2) things that care about async scrolling, and so actually want to have a properly sized display port.
Type 1) were not changed by this patch. Type 2) were changed to consider minimal display ports as not display ports.
Again, we are aiming to leave behaviour unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D103856
We introduce a new type of display port, a minimal display port. It is controlled via a property on the content element. When the property is present any other display port specified on the element is ignored and instead the display port rect is computed by assuming 0 display port margins and no alignment (this reuses the existing code for display port suppression).
We then add code to set a minimal display port on every scroll frame that is painted that has WantAsyncScroll() when certain prefs are set (the prefs are disabled as of this patch though).
We then need to manage removing the minimal display port property when, before this patch, we would have created a regular display port. As well we need to add the minimal display port property when, before this patch, we would have removed a regular display port.
In order to do this I audited all sites where we set the display port rect and display port margins property. The changes to the code for handling the removal display ports happens in a later patch.
My audit found that all of the places we set a display port want to clear the minimal display port property except:
-UpdateSub/RootFrame in APZCCallbackHelper
-UpdateDisplayPortMarginsForPendingMetrics in DisplayPortUtils
UpdateDisplayPortMarginsForPendingMetrics is basically a fast path of the UpdateSub/RootFrame code. These are the places where we handle calls to RequestContentRepaint from apz. By adding an assert and running it through try server I found that UpdateSub/RootFrame can create a display port in the following cases:
-a scroll info layer
-a scroll frame with !WantAsyncScroll() (the main thread never creates a display port for a scroll frame with !WantAsyncScroll()) (for example if the main thread creates a scroll id and sends over metadata via nsLayoutUtils::GetRootMetaData, and then the scroll rect changes, that will cause a RequestContentRepaint call)
-a few instances that don't fall into the above that happened on try server but didn't reproduce for me locally, so I don't know more about them.
It's not very important whether we clear the minimal display port property for these cases or not (the first two cases we don't async scroll the scroll frame at all, the last case seems quite rare).
Note that we intentionally do not change the existing behaviour of zero margin display ports set via SetZeroMarginDisplayPortOnAsyncScrollableAncestors as we are aiming for no behaviour changes with this patch (until we flip the pref). A later patch in a different bug handles changing these display ports over to minimal display ports.
Differential Revision: https://phabricator.services.mozilla.com/D103855
Currently the default value of buttons is set to
MOUSE_BUTTONS_NOT_SPECIFIED, which defers calculation of the value to
the DOMWindowUtils GetButtonsFlagForButton function. This calculates a
default value based upon the value of the button key.
By specifying a default button value of 0, which has a meaning of
ePrimary, the buttons value is calculated as the
ePrimaryFlag (1), suggesting that a button was pressed.
This patch changes the behaviour to set the value of buttons based on
the original value of button before the default was applied. The value
of buttons also considers the event type to ensure that a mousedown
event has a default value calculated by DOMWindowUtils.
With the new behaviour:
- if a value was explicitly set for buttons, this is used
- if a value was explicitly set for button, then the not-specified
constant is used to defer calculation to DOMWindowUtils
- if an event type was specified and that event type was not the
'mousedown' event, then the no-button constant is used
- if an event type was not specified or it was for the 'mousedown'
event, then the not-specified constant is used to defer calculation to
DOMWindowUtils
Differential Revision: https://phabricator.services.mozilla.com/D101690
This is a regression by bug 1651705.
After landing it, we use read-write lock to access GeckoEditableChild object.
But when using form submission with target=_blank, since we use some nested
event loop to open new window in same process, we may try to dispose
GeckoEditableChild even if it is still used. Then, it may be dead lock.
So I add a blocker class helper not to dispose GeckoEditableChild immediately.
Differential Revision: https://phabricator.services.mozilla.com/D103742
Butkovits Atila
Yaron Tausky
Jens Stutte
Simon Giesecke
Nicolas Silva
Jonathan Kew
Forrest
Jan-Erik Rediger
Neil Deakin
James Graham
moz-wptsync-bot
Xianzhu Wang
Aaron Krajeski
Mike Taylor
Stephen McGruer
Rune Lillesveen
Ilya Nikolaevskiy
Anders Hartvoll Ruud
Nayeem Rahman
autofoolip
Rob Buis
Timothy Nikkel
Kershaw Chang
Alexandre Poirot
Sylvestre Ledru
sachinchauhan2889@gmail.com
Asumu Takikawa
Andrew Nicols
Nils Ohlmeier [:drno]
Makoto Kato