Now that BeginUpdate is useless for the UPDATE_STYLE case, we don't need the
update mechanism at all. Just ensure that ApplicableStylesChanged is called on
the pres shell via the relevant RuleChanged, etc. notifications.
There's a big hidden gotcha here. nsIDocument::BeginUpdate does put a script
blocker on the stack for these updates. However it's not needed, since no script
can run during these notifications (only the stylesheet events we post for
devtools, but those use AsyncEventDispatcher and PostDOMEvents, so they don't
try to run immediately).
nsIDocument::BeginUpdate also does XBL binding attached queue stuff, but we
can't change bindings during these notifications anyway, so it also doesn't
matter.
MozReview-Commit-ID: HJvK6zQfloh
This fixes a bounds check assertion on the array access into the touch event's
touch list.
I don't know why we have a touch event with no touches. Maybe it's an internal
touch event?
MozReview-Commit-ID: 8MWF1SMAfor
--HG--
extra : rebase_source : 1b2477d5679d9f1a1adef680911263ff49a89da9
We don't want to gesture activate for key and mouse/pointer events sent to
editable elements, as that would mean user interaction intended as text input
could start media playback, which would not likely be the user's intention.
MozReview-Commit-ID: VemPfpuziz
--HG--
extra : rebase_source : b2267f5ae2c9f0f6626f622bc98e3c5f18faf8bb
We don't want key presses of keys which are likely to be intended to be
interaction with the browser or OS to gesture activate documents and unblock
autoplay videos. So don't gesture activate for key events which are modifier
keys, or which don't have a pseudo char code.
MozReview-Commit-ID: 6uyPmlzbAvg
--HG--
extra : rebase_source : 8be949228b666a2ff54385f14b38b8f89459b1e2
extra : source : 59979388ba67d5fbfa8f3801bb65ac0fd2a49408
We don't want to gesture activate for key and mouse/pointer events sent to
editable elements, as that would mean user interaction intended as text input
could start media playback, which would not likely be the user's intention.
MozReview-Commit-ID: VemPfpuziz
--HG--
extra : rebase_source : b2267f5ae2c9f0f6626f622bc98e3c5f18faf8bb
We don't want key presses of keys which are likely to be intended to be
interaction with the browser or OS to gesture activate documents and unblock
autoplay videos. So don't gesture activate for key events which are modifier
keys, or which don't have a pseudo char code.
MozReview-Commit-ID: 6uyPmlzbAvg
--HG--
extra : rebase_source : 8be949228b666a2ff54385f14b38b8f89459b1e2
extra : source : 59979388ba67d5fbfa8f3801bb65ac0fd2a49408
We should gesture activate documents in key/mouse down instead of up because
if a web app wants to play a video inside a key/mouse handler, the document
needs to be activated before the handler runs.
Also, Chrome activates on key/mouse down, so we may have compat issues if
we have different behaviour.
MozReview-Commit-ID: JgGaQcNQfzz
--HG--
extra : rebase_source : edf5673be59a3714c3dd4eb239efd17d6a91ec32