The spec recently changed to match browsers better. There's currently
not much interop in exact details of how this work. This brings us in
line with the spec except for the limit of 1000 on the span attribute.
The added textarea failures are spurious, because I'm not updating our
local tests in this commit. The new tests are submitted upstream at
<https://github.com/w3c/web-platform-tests/pull/3518>.
MozReview-Commit-ID: 1L8aUtF47Qi
The test uses either a theora/flac file or a h264/mp4 one.
XP doesn't have a h264 decoder and as such the test would have failed in
the past having no file to work with.
This is no longer the case now that flac in ogg is usable.
MozReview-Commit-ID: EWUR4G85XPD
--HG--
extra : rebase_source : aecd4d8759ad23096a671c81880923edf7283c36
When deleting, we previously would only move the cursor back into the
previous block if the last leaf node was a text node, for some reason.
We should move into the previous block in other cases as well, like if
the leaf node is a collapsed <br>. (Probably it's not correct to move
backward into tables, but that already was happening if the table had
text at the end. There may be other cases where this is wrong.)
MozReview-Commit-ID: 8e0dTU3lNYO
If the user tries to insert text without moving the cursor, the
invisible break will become visible, which from the user's perspective
means an extra line break was inserted for no reason.
The IsVisBreak change here is a bit scary, because it may result in
unexpected behavior changes, but it seems to improve correctness. If it
turns out to cause problems, it can be added as a special case to
GetGoodSelPointForNode instead.
MozReview-Commit-ID: 7SRQYHYtJvF
Previously we supported insertParagraph as a synonym for formatBlock
"p", which is both useless and incompatible with all other browsers.
Edge's behavior doesn't look useful and looks redundant with insertHTML
(although it matches the name nicely, probably because they invented
the command). Blink/WebKit treat it the same as hitting Enter, which is
useful for cross-browser testing until we get synthesizeKey() in wpt.
At the same time, I added insertLineBreak, which Blink/WebKit support
with the same functionality as pressing Shift-Enter.
The new event.html failures are spurious -- we used to pass by mistake
because we didn't support insertlinebreak at all. insertlinebreak.html
has only new passes, no new failures, although it's not clear on the
diff.
MozReview-Commit-ID: 16oPcxXwGcj
When deleting, we previously would only move the cursor back into the
previous block if the last leaf node was a text node, for some reason.
We should move into the previous block in other cases as well, like if
the leaf node is a collapsed <br>. (Probably it's not correct to move
backward into tables, but that already was happening if the table had
text at the end. There may be other cases where this is wrong.)
MozReview-Commit-ID: 8e0dTU3lNYO
If the user tries to insert text without moving the cursor, the
invisible break will become visible, which from the user's perspective
means an extra line break was inserted for no reason.
The IsVisBreak change here is a bit scary, because it may result in
unexpected behavior changes, but it seems to improve correctness. If it
turns out to cause problems, it can be added as a special case to
GetGoodSelPointForNode instead.
MozReview-Commit-ID: 7SRQYHYtJvF
./mach web-platform-tests tries to access the tests at
http://web-platform.test/. If an HTTP proxy is configured, it tries to
access it via the proxy, which fails. Disabling the proxy entirely
fixes the problem and should probably have no adverse effects, although
a cleaner solution would be to skip proxies only for that domain (as is
done with localhost).
MozReview-Commit-ID: IkIRLwbH16P
This implements the spec change here: ee1577c959
MozReview-Commit-ID: 8XKaocLbrmL
--HG--
extra : rebase_source : 18c402b0af7c21b8721ca796c054a3f58eb21a72
This implements the spec change in 21de090dac
The spec change refers to a binary 'animation direction' flag. Instead of that,
however, we just pass the playback rate along and use it inside
GetComputedTimingAt since this seems simpler.
Also, this patch moves the implementation of
KeyframeEffectReadOnly::GetComputedTiming from the header file into the .cpp
file. This is because with this change, GetComputedTiming needs to call
mAnimation->PlaybackRate() and so mozilla::dom::Animation needs to be a complete
type. However, simply including Animation.h doesn't work because of a cyclic
dependency between KeyframeEffect.h and Animation.h. We might be able to fix
this later but since yet-to-land bug 1049975 moves this code around a lot, I'd
rather not touch it too much just now.
MozReview-Commit-ID: 1h6XRh4xmfI
This test overlaps somewhat with the tests in
web-animations/timing-model/animation-effects/simple-iteration-progress.html.
However, these tests are more specific to just covering the phase calculation
algorithm. Ultimately the tests in simple-iteration-progress.html should be
broken down into separate tests for the different algorithms being tested.
There is also some redundancy in these tests. For example, instead of writing:
.forEach(function(test) {
assert_phase_at_time(animation, test.phase, test.currentTime);
});
we could just define an assert_phases_at_times function that takes the array of
test cases and iterates over them. However, I think writing the test like this
makes it easier to read since it requires less imagination about what
assert_phases_at_times might be doing.
One concern is that this test requires the setter for AnimationEffectTiming.fill
to be implemented. We could rewrite this to create a new animation with the
appropriate fill mode each time but I think this is probably ok.
MozReview-Commit-ID: 82uvBB8bizI
Phil Ringnalda
Thomas Wisniewski
Ryan VanderMeulen
Boris Zbarsky
Emilio Cobos Álvarez
Wes Kocher
Aryeh Gregor
Stone Shih
Ehsan Akhgari
Boris Chiou
Jean-Yves Avenard
Sebastian Hengst
Jonathan Kew
Brian Birtles
Ben Kelly
Mason Chang
Daisuke Akatsuka
Jessica Jong