SupportsServoStyleBackend() uses methods in nsIDocument, so it would be more
straightforward to do that in UpdateStyleBackendType().
Also, call StyloEnabled() before doing other logic so that the warning about
"no docshell" won't show up when stylo is built but disabled.
MozReview-Commit-ID: 9ZUYatPBv1r
--HG--
extra : rebase_source : ea130cdf2ef0b49d73bd688aeca1fc227431441c
In this way, the callers who have nsIDocument don't need to cast to nsDocument.
MozReview-Commit-ID: 8zVUjkbrlaG
--HG--
extra : rebase_source : c444a103a430e3746508cc894902e677d58e65fe
Technically speaking, we use the new async API 'nsIURIClassifier.asyncClassifyLocalWithTables'
to replace the old sync API. However, since we cannot guarantee the async call will be done when
we neet its result, we need a sync call as a fallback in this case. This is a sub-optimal
solution and we will be investigating if there's a better solution if the sync call
is used too frequently.
MozReview-Commit-ID: L1uQ2eaYr1e
--HG--
extra : rebase_source : 148e0e85796c932ea85d123092f479e1373ecec9
extra : intermediate-source : 53007a31b576fcd4f16ad6523cccd0a9b90c66f0
extra : source : 1175b9c64b31da2ca2ab88f78488aed6fdc405bc
Previous design allows us calling resume/block from both front-end and back-end,
it's not easy to know who called these operations.
So move all these logic to frond-end side, it's more clear than before.
One important thing is that we should block tab before loading the content.
If we block the tab after loading, the media might not be blocked because it had
already started (that is one situation I observed from test).
The value of block state would be stored in the outer window, before media want
to start, it would check this value to know whether it can start playing or not.
---
In addition, introduce new attribute "media-blocked".
The "media-blocked" attribute indicates that whether the tab is allowed to play autoplay media.
The "activemedia-blocked" attribute indicates whether the tab has blocked the autoplay media.
MozReview-Commit-ID: FnNh3zmItxo
--HG--
extra : rebase_source : cdc890c0c47a4a03ea8dbbdfee24c66b52945c60
Previously, we cleared mCachedRootElement a bit later -- after removing *all*
of the children and calling nsNodeUtils::ContentRemoved() and UnbindFromTree on
each of them. This was problematic, because these cleanup functions can
involve calls to GetRootElement() -- and prior to this patch, any such
GetRootElement() calls would likely return the stale value in
mCachedRootElement.
Now, with this patch, we'll be clearing mCachedRootElement
sooner, so these GetRootElement() calls will return the correct current root
(which will likely be null in this case, since we're emptying the document of
children).
MozReview-Commit-ID: 8skGJyic1pC
--HG--
extra : rebase_source : 2a1c3880c676123b2bfa9dd21ae296e663ba6a38
Measure execution time by adding telemetry probes for tracking
foreground, tracking background, non-tracking foreground and
non-tracking background timeouts.
--HG--
extra : source : 69439c0cd3e6d118681d1bb6586cb0a7b4bb85fc
Measure execution time by adding telemetry probes for tracking
foreground, tracking background, non-tracking foreground and
non-tracking background timeouts.
--HG--
extra : rebase_source : f638cc4422a777bbd093d5bbb2d5852c19b1c9d1
Currently, attribute and child arrays (implemented in dom/base/nsAttrAndChildArray.h) start out empty. When cloning, the array ends up being resized multiple times in order to add the attributes and children that are being cloned from the original node. This would be quicker if the array was initialized to the correct size in the first place so that resizes are not necessary.
However, preallocating space for children is only necessary when performing a deep clone. Therefore, an additional parameter is being added to the Clone, CopyInnerTo, and CloneDocHelper methods to indicate whether preallocation of children should happen. Attributes are copied either way, so that part of the array is preallocated in both cases.
MozReview-Commit-ID: 3iVezeAKXnI
--HG--
extra : rebase_source : 9c3deec6d7aafd6411044d623d4863637b45fd58
Internally, doRemoveChildAt does quite a bit of cleanup, and that includes some
calls to nsIDocument::GetRootElement(). Before this patch, those calls will
misleadingly return the still-present mCachedRootElement member-var. We'd
really like those invocations to find an empty cached variable, and fall back
to checking the actual updated child list.
MozReview-Commit-ID: 8hhKcWyUVYQ
--HG--
extra : rebase_source : 238057c864e01c2af8c985250ed5e948b29bc338
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
--HG--
extra : rebase_source : 199ab921acfc531b8b85e77f90fcd799b03c887b
SelectorCache::NotifyExpired() will be invoked by nsExpirationTracker::TimerCallback() from an unlabel runnable.
We adopt the change in nsExpirationTracker to provide a DocGroup EventTarget for the invocation of this callback.
--HG--
extra : rebase_source : 42626d5493efff4bc38fba418a4ac3a8b9ff6b6a
This is a hybrid of the previous two approaches. The nsParser weak reference
sometimes stays alive after it's been detached from the document, after which
attempting to remove it throws. This stores a reference to the original
parser, and checks that it's still the current parser when it comes time to
resume.
MozReview-Commit-ID: 1JSi2FmPxt0
--HG--
extra : rebase_source : fc29ab7cd2074eda5f2c747ff7255a29bcc6f4a2
The next patch moves nsCSSFontFaceRule into a separate header, which
somehow affects lots of header dependencies. I'm not completely sure
why this happens, though.
MozReview-Commit-ID: KuXbsaX0NUd
--HG--
extra : rebase_source : cef91018964b5488c5031df8aada90aa7fa0ad51
Previously, we operated under the understanding that with Flash blocking activated, non-whitelisted documents would be set to CTA. We are changing that such that now, documents will only be CTA'ed if Flash is set to "Ask to Activate".
Flash blocking will now behave according to the following chart:
User Setting Flash block Whitelisted sites Blacklisted sites Unlisted sites
"Never ..." Off Deny Deny Deny
"Ask ..." Off Ask Ask Ask
"Always ..." Off Allow Allow Allow
"Never ..." On Deny Deny Deny
"Ask ..." On Allow Deny Ask
"Always ..." On Allow Deny Allow
This patch also completely reworks the flash blocking testing. Test data and most code remains consolidated, but will be run in multiple different tests. This avoids having to extend the timeout for Flash block testing to an extremely long length. The new Flash block testing additionally tests each of the six cases (rows) in the table above.
MozReview-Commit-ID: 5aPGUEiUiCv
--HG--
extra : rebase_source : d5f5711855d108a9a33b9d28aae6e312cc9cb432
Since the window would know when need to resume the media, we don't need the
add/removeMediaContent() anymore.
MozReview-Commit-ID: F9MSiqqnOiV
--HG--
extra : rebase_source : fa86b3977e13d1f2a6b6233b6d608ccc331b5bf7
