The immediate reason we need to change this is that bug 1299911
proposes adding a verifier to check that there are no black-gray edges
in the JS heap, and sGeneration being 0 causes that to fail, due to
mozilla::dom::TraceBlackJS(). If something is a black root, I believe
the verifier requires that it be marked black. This makes sense,
because a black root is something that is definitely alive, and if the
object is marked gray, the CC might free it, as far as the GC knows.
This fails because when the browser starts, it GCs and marks the stuff
at the bottom of TraceBlackJS grey. Then it runs the CC, which flips
sGeneration to 1. Now, the verifier runs (before the GC runs!), and it
sees that the stuff in TraceBlackJS claims to be black, but is grey,
causing a verification failure.
In this particular case the code is actually safe. The purpose of the
black-gray invariant is to ensure that the CC does not incorrectly
unlink any gray C++ objects that are reachable from black JS
roots. The JS objects in TraceBlackJS should all be reachable directly
from a C++ object, and the CC knows that those C++ objects are alive
(because of refcounting). Therefore, the CC will not unlink any
objects that are reachable from black JS roots.
MozReview-Commit-ID: 8PrRkjqWBL
--HG--
extra : rebase_source : f9c2971bf71475202a1a6bbc719ab9ce19f94bc5
If we have a creator parser, then we were a parser-inserted script and should
presumably be able to set a valid insertion point when we run or fire our
load/error events. For the error event case, we do this in
nsScriptElement::ScriptAvailable, so that async error events due to things like
bogus script URLs do not end up with a valid insertion point. For the load
event case, we just do this in ScriptEvaluated directly.
ScriptEvaluated is called while the scriptloader has our script set as the
current parser-inserted script. But for the error event case we need to
maintain that state around the ScriptAvailable call that will fire the event.
CLOSED TREE
Backed out changeset 5c65378feacd (bug 1298818)
Backed out changeset 72f66ce70dd8 (bug 1298818)
Backed out changeset eb17677e8167 (bug 1299838)
This allows other UAs to use it, removes duplicated checks, and
increases the chance of us noticing if the spec changes. Some of the
expected values in our mochitest were contrary to the spec.
I checked the new expected failures against the spec and the other UAs.
I filed a spec bug for one group because it was contrary to all UAs
(although IMO the spec makes more sense and the UAs are buggy), and the
others are fixed in the next patch.
MozReview-Commit-ID: 1j11XgfuErB
The VideoPuppeteer now uses played ranges where possible to calculate the
remaining time. It will also use the played ranges to determine the expected
duration where possible. This is more accurate than using the time when the
tests first poll the video. The first poll time was previously self._start_time,
but I've renamed this to self._first_seen_time, to reduce ambiguity -- the video
may have started playing before this time.
The playback_done function has had it's remaining time check relaxed. Previously
it was possible to skip over the window where a video would be considered
complete, that window is now expanded so that if the start threshold is passed
the video is considered played.
A concrete example: the tests could play a 90 second video, but the duration of
the test is set to 60 so only part of the video need be played back before the
test completes. If a 1 second interval was used in the tests there would be a
window between 59 to 61 seconds during which if the video were polled it would
be considered complete. However, due to latency polling may not take place in
this window, leading to racy fails. Now the tests will consider any point beyond
59 seconds to be complete.
MozReview-Commit-ID: J6DpqCbZxUg
--HG--
extra : rebase_source : 7990e4eee0bce30718b875f652c7148110cd4c3f
This is a quality of life change. Since VideoPuppeteer uses, and since I plan on
using the played ranges of a video element more, it is useful to output them as
part of the str representation.
MozReview-Commit-ID: LwVPfVtFF1v
--HG--
extra : rebase_source : 1ebe4b7a7176a15f7e9300dee84103a8f6b86708
This patch prevents the Windows widget code from dispatching the contextmenu
event if APZ is handling touch input. Instead, the APZ code processes the
raw touch input, and will fire a contextmenu event when the user lifts their
finger after a long-press action, in keeping with the Windows platform
convention. Doing it this way also allows us to respect web conventions where
the web content can prevent the contextmenu event from firing by calling
preventDefault on the touchstart event; this was not possible when dispatching
the contextmenu event directly from the widget code.
This also makes long-pressing on browser chrome components work properly, as
it just shifts the point in time that the contextmenu event is fired without
changing any of the code that triggers the XUL popup. However, some changes
were needed to have the widget code ignore the synthetic mouse events that
the Windows platform sends us, because those would otherwise immediately
dismiss the contextmenu popup after it appeared.
MozReview-Commit-ID: 9HFZLC6xUAi
--HG--
extra : rebase_source : aea932d9f95454c585bcdf962d151c946b5c6ec2
