style: Allow passing an nth-index-cache to the invalidation code.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2a5121357a76e2b558ecd0dae7689d709b6a2b41
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 698ea0c490b0fa689461e29c8c97ab6f2de3ce95
Remove the main file that we don't need anymore and modify all
the imports to target the specific file they now need.
MozReview-Commit-ID: 2uWjTnAMAU0
--HG--
extra : rebase_source : ebf75886fac79aaebfab16c03997f402e9f5a278
By returning true from WebRenderLayerManager::EndEmptyTransaction, we
avoid doing a full paint in cases where the caller decides an empty
transaction would be sufficient. WebRenderLayerManager already rejects
attempts to set some forms of empty-transaction data (specifically
transform and scroll offset updates). This means that we will never get
a call to EndEmptyTransaction where the caller is expecting a transform
or scroll offset update to be sent over to the compositor. So if we have an
implementation of EndEmptyTransaction that ignores that data, it will not
break expectations.
There is still one piece of information that WebRenderLayerManager
doesn't reject in this manner, the APZ focus state. That is, if the
layout code sets a pending APZ focus state on the WRLM, followed by a
all to EndEmptyTransaction, it expects the focus state to get propagated
to the compositor. This patch makes sure that it does happen by using
the new API added in the previous patch.
MozReview-Commit-ID: 596UgW9ZWAF
--HG--
extra : rebase_source : e0f4f201a76747d6e29cde5da26fe760fd7f770b
One of the pieces of information that can be sent to the compositor is
the APZ focus state info, which is used for keyboard APZ. This patch
adds an API that allows updating this outside of a regular WR
"transaction" (i.e. a SetDisplayList call) so that we can use it in an
empty transaction (in the next patch).
MozReview-Commit-ID: L5TCbI9FtGV
--HG--
extra : rebase_source : 427b606a333d83eb82aa566768ba331d34542e8e
Currently some callers attempt to set a "pending scroll offset update"
on the layer tree, which basically allows it to send a scroll offset
update to the compositor in an empty transaction, without doing a full
paint. However, WebRenderLayerManager doesn't really support empty
transactions yet, so we want to reject attempts to do this for now. This
will force the callers to schedule a full transaction instead of an
empty transaction.
MozReview-Commit-ID: 1bBlj59W5HH
--HG--
extra : rebase_source : 0a018989c2681b01ff325e8e2c79c9ff146f04d4
When changing locales, an open dialog will not refresh but clicking on the
"Top sites" preference again (to display the dialog) will show the correct
dialog for the current locale.
MozReview-Commit-ID: 6UJvDIJZJtc
--HG--
extra : rebase_source : 777d0f4bc34829c8aacdeaac42fc0e27c3e7afd6
After speaking with liuche, we decided it'd be better to add a bit to determine
this rather than combining it with the isPocketEnabled field (which would be
loss of data) or cross-referencing the locale of the submitted event when
checking the Pocket value during telemetry analysis (which is hard to get right
and likely to get out of date).
MozReview-Commit-ID: JKFrdEsEbyp
--HG--
extra : rebase_source : bc20193ca29238cbde5361a840cbd367b492a346
Ideally, we'd centralize all queries as to which options are user specified.
However, I wanted to do the smallest change so we can uplift so I filed
bug 1405161 for this centralization.
I opted not to include the "de" locale that is included on desktop because it
does not appear we ever get the "de" locale on Firefox for Android [1].
I tested this patch by changing the system locale between locales with Pocket
on my device (en-US, en-GB, de-DE) and locales without Pocket (ko-KR). The
locale switching system makes this refresh automatically without extra code.
I also intend to test via the in-app locale switcher but that will take time
because I can't do artifact builds with multi-locale so I'm pushing this for
review before I'm finished.
Follow-up changes:
- Add to telemetry
- Hiding the preference in the undesired locales.
- A test for isPocketEnabledByLocaleInner (useful to document how this is
intended to work for locales with variants, different scripts, etc.)
[1]: https://sql.telemetry.mozilla.org/queries/4613#table
MozReview-Commit-ID: 7AVQ8fWub8I
--HG--
extra : rebase_source : 948f1a4ea6c6bbc51c8ae945b940d8ab4770e34e
As required by the recent spec change:
d696468777
MozReview-Commit-ID: Ev6kUk1uLAY
--HG--
extra : rebase_source : 70f8ca3143a8b3bb4e03016b9989925d5a328049
We don't however, use arrow syntax for local functions that act as class
constructors since they don't want the lexical this that arrow functions use.
MozReview-Commit-ID: FuVhHIBFZrE
--HG--
extra : rebase_source : 919bbe7a6f6fc42281411ad4058540f233a3e010
This tests the behavior clarified in the following spec changeset:
d696468777
MozReview-Commit-ID: 3hS7rHcTpUn
--HG--
extra : rebase_source : 13941772212d169824d3058a131067ca0823d2ca
This naming is recommended by [1] and from a random sampling of tests in
web-platform-tests it seems like most test don't use this, only tests that are
split over multiple files.
This "processing a keyframes argument" section is quite large so I intend to
split the tests up into a number of files to cover:
* Tests for property access
* Tests for easing
* Tests for offset
* Tests for composite
* Tests for equivalent forms
[1] http://web-platform-tests.org/writing-tests/general-guidelines.html#file-paths-and-names
MozReview-Commit-ID: JW2m50UnsKv
--HG--
rename : testing/web-platform/tests/web-animations/interfaces/KeyframeEffect/processing-a-keyframes-argument.html => testing/web-platform/tests/web-animations/interfaces/KeyframeEffect/processing-a-keyframes-argument-001.html
extra : rebase_source : fafe135996b11661385b0f28a82abc9b11c77c25
This seems to be standard JS style recently (as used in prettier etc.): Use
spaces to separate the { and } from the properties (but not for arrays).
MozReview-Commit-ID: FRkFRwwcJJh
--HG--
extra : rebase_source : f45fbc371bc23b542032612bcf4578ee4de9f98e
* We should refer to reading or accessing properties, as opposed to
"considering" them.
* We should use "property-indexed" consistently.
MozReview-Commit-ID: ItCE4g8LmOC
--HG--
extra : rebase_source : 8656dc185f6e6e820a283a725fd4217336b06712
There is a test that assumes that an offset specified on a property-indexed
keyframe is applied to all generated keyframes but that behavior is not (yet)
specified.
This behavior will be specified in [1] but until that happens it seems invalid
to test for it. Furthermore, when that is specified we will need much more
thorough tests than this one.
[1] https://github.com/w3c/web-animations/issues/148
MozReview-Commit-ID: HUUw88dg2P7
--HG--
extra : rebase_source : 5e38d8f0fb01b3ecf7339ca1be0e31c775bf4b21
But only in a couple of places where it makes the test more readable.
MozReview-Commit-ID: 6zVJ6h7Zb3k
--HG--
extra : rebase_source : 8ec4e7957cfccb4b60b97032a1a12fa12d9ff589
for...of is generally preferred over forEach since it is a little easier to read
and allows using 'break' and 'continue'. Furthermore it is supported in all
major browsers. (It also makes wrapping one of the long lines in this file
easier.)
MozReview-Commit-ID: 1BuoW0QSxaG
--HG--
extra : rebase_source : 4c0e04720cda5ecb60a276ac52c595cba693aa16
Gradually we plan to move all these tests to ES6 (or at least the subset
supported by all UAs that are likely to implement this spec) so while we are
touching this file we update a few uses of 'var' to let/const.
MozReview-Commit-ID: 45OJyXmUzKu
--HG--
extra : rebase_source : a14138a9ffddd8a89da0635e316f918297010529
KeyframeEffectReadOnly may disappear (see [1]) and is only needed for CSS
Animations and CSS Transitions so in that sense KeyframeEffect is more basic
(despite being a subclass of KeyframeEffectReadOnly) so we should prefer it to
KeyframeEffectReadOnly.
Furthermore, as the comment at the start of the file suggests, we should
consistently use the same method for testing these procedures. We currently use
the KeyframeEffect constructor because it is more direct and basic.
[1] https://github.com/w3c/web-animations/issues/185
MozReview-Commit-ID: LBrlfzyn2Ch
--HG--
extra : rebase_source : 358c60c89c70d642cb5c193a1bdff4e5991aac54
And also drop the slightly misleading and redundant comment about the procedure
that this test covers (it covers *both* the "process a keyframes argument"
procedure and the "process a keyframe-like object" subprocedure).
MozReview-Commit-ID: 9lzx4rCj20o
--HG--
extra : rebase_source : 64c429d8dfceb7e518cac1418cd6c6ea6de16eaf
The HTMLAnchorElement macros were basically a verbose version of the
CYCLE_COLLECTION_INHERITED helper macros.
MozReview-Commit-ID: 1bxuKdWUMlG
--HG--
extra : rebase_source : 84f5b0de5b1191d0df5c34bcadf61fca72178769
Add macro for nsISupports inheriting classes that need cycle
collection and only inherit from one parent, with no interface table
needed. Takes care of map and addref/release calls.
MozReview-Commit-ID: LtTwYH0DeEz
--HG--
extra : rebase_source : d3650209ddd7e28cbf205ac84f152b9763c26bde
Johann Hofmann
Oriol Brufau
Emilio Cobos Álvarez
Nicolas Chevobbe
Kearwood "Kip" Gilbert
abhinav
cku
Kartikaya Gupta
Daosheng Mu
Michael Comella
peter chang
Brad Werth
Wes Kocher
Kit Cambridge
Brian Birtles
Shane Caraveo
evilpies@gmail.com
Servo VCS Sync
Andreas Tolfsen
Kyle Machulis