When styling with the Servo backend, we should also use the Servo backend to
determine if a property is animatable or not. However, if we do this,
Servo_Property_IsAnimatable will start returning true for the 'display' property
once we mark that as animatable in Servo (for SMIL).
Even if we later fail to actually animate 'display' (due checks added to Servo
in the next patch) we still need to treat 'display' as un-animatable in
KeyframeUtils so that we don't *read* the 'display' property of Keyframe objects
passed to the Animations API, since that is observable.
This patch makes us consult Servo_Property_IsAnimatable when using the Servo
backend and also explicitly treat the 'display' property as not animatable.
MozReview-Commit-ID: 1JllbeJisAS
--HG--
extra : rebase_source : d73b7d9ee0da03bfed68e574b67e10b342c1868d
The intermittent failure appears to have been due to mOriginsHavingData
only being updated when the db thread flushes. The db thread has a
hard-coded 5 second flush interval. It's likely that e10s startup was
previously so slow that we were assured of having a flush happen by the
time our fresh process created its parent actor.
We correct this by reliably ensuring a flush before spinning up the
process to check preload state. We also ensure a flush at the start of
the test for our check that there was no preload in the initial cases.
We were actually more vulnerable in that case, I believe, but as a
browser chrome test, there were no other tests that would have used
content localStorage.
We additionally ensure that the content process has received and
populated mOriginsHavingData by having the tab opening process wait for
about:blank to load in the process before actually opening our origin.
Prior to this change we were depending on orderings that aren't
guaranteed.
--HG--
extra : rebase_source : 92d3c675cee82ffe8b562e83860601e0c6dc1a9b
Bug 1345990 introduced a "forceNewProcess" argument in
BrowserTestUtils.openNewForegroundTab. By switching to this we can
stop bloating the process count pref to try and produce equivalent
results. To minimize test churn and because it doesn't really hurt to
double-check, the code that asserts that our tabs are each in different
processes and related book-keeping infrastructure have been left intact.
We also set a preference to disable preallocated processes in the interest
of maximizing test consistency and minimizing breakage. It's conceivable
that a preallocated process might end up creating its StorageDBParent
actor prior to when we want, breaking things. By ensuring the process
isn't created until we want it, we avoid a lot of brittleness.
--HG--
extra : rebase_source : 5736f7b2d06b720cefbe82eb6052e71b9fc14f23
Per spec [1], date/time inputs fall into this category:
"For input elements without a defined input activation behavior, but to which
these events apply, and for which the user interface involves an explicit
commit action but no intermediate manipulation, then any time the user commits
a change to the element's value, the user agent must queue a task to first fire
an event named input at the input element, with the bubbles attribute
initialized to true, and then fire an event named change at the input element,
with the bubbles attribute initialized to true."
So, we fire input/change events when:
- User selects a date/time from the picker
- User changes the value using up/down keys in a already complete date/time
value
- User changes the value using the number keyboard in a already complete
date/time value
- User clears the value (using reset button or using backspace)
MozReview-Commit-ID: E7Jc5qMKZj4
--HG--
extra : rebase_source : 01d4ddbf97d7cef626491946e008a88db4641258
Ben Kelly
Sebastian Hengst
Wes Kocher
Andrew Osmond
Mats Palmgren
Nicolas B. Pierron
Andrea Marchesini
Carsten "Tomcat" Book
JerryShih
Brian Birtles
Robert Longson
Andrew Sutherland
Olli Pettay
Eden Chuang
Jessica Jong
Kris Maglione
Matt Woodrow
Samuel Vargas