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
We should let window decide whether resume the media component, not document.
Because we might have media component which is not in DOM tree, but we still
want to play it.
Window should be resumed when all following conditions are true,
(1) the tab is in the foreground
(2) there is any alive media component (MediaElement/WebAudio/PlugIn...)
(3) the window is blocked (nsISuspendedTypes::SUSPENDED_BLOCK)
MozReview-Commit-ID: JXw5MA4FCxF
--HG--
extra : rebase_source : 953eed775637a19c6d5d323ab1549f6ed5f7ff31
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 : 28a8312373054b8e29b93267677de99dd862a074
We should let window decide whether resume the media component, not document.
Because we might have media component which is not in DOM tree, but we still
want to play it.
Window should be resumed when all following conditions are true,
(1) the tab is in the foreground
(2) there is any alive media component (MediaElement/WebAudio/PlugIn...)
(3) the window is blocked (nsISuspendedTypes::SUSPENDED_BLOCK)
MozReview-Commit-ID: JXw5MA4FCxF
--HG--
extra : rebase_source : 416113dd2282a979ea26c4694878c2f2db578274
In bug 1044586 we changed nsDocument::GetEventTargetParent such that events for
a document were not sent to its parent window if the inner window for the
document wasn't the current inner window. Unfortunately it seems this means
event listeners on the window sometimes miss user input events (mousedown etc.)
when user input takes place before the first paint of a new document that's
loading. In order to fix this, this patch backs out the changes from bug 1044586.
This reintroduces the issue we had before with the preference window, where
reloading the preferences quickly meant that its listeners (attached to the
window) got confused by DOMContentLoaded events from a previously loaded
document. Instead of the broad fix to nsDocument::GetEventTargetParent, this
patch simply changes the event listeners from the preferences code to be
attached to the document instead of the window, thus ensuring they only get
notified for events relating to their own document.
MozReview-Commit-ID: 9DImyNst9fS
--HG--
extra : rebase_source : 94936a0ec7e60d61b25ea2e2f3236884b3cf4293
The previous patch in this series converted all uses of mapped attributes
for animation to be animated as CSS properties (that is, to be treated
as presentation hints in the cascade).
As result, we no longer need the SVG Animation presentation hints level
of the cascade, the corresponding rule processor(SVGAttrAnimationRuleProcessor),
or the corresponding eRestyle_SVGAttrAnimations restyle hint. So this patch
removes these unused rule processor and restyle hint.
MozReview-Commit-ID: Hm8IDaqc3ym
--HG--
extra : rebase_source : 339ad209f37ea84857577001c7385323f2187d46
The previous patch in this series converted all uses of mapped attributes
for animation to be animated as CSS properties (that is, to be treated
as presentation hints in the cascade).
As result, we no longer need the SVG Animation presentation hints level
of the cascade, the corresponding rule processor(SVGAttrAnimationRuleProcessor),
or the corresponding eRestyle_SVGAttrAnimations restyle hint. So this patch
removes these unused rule processor and restyle hint.
MozReview-Commit-ID: Hm8IDaqc3ym
--HG--
extra : rebase_source : db5f467df198769474f0af6b6739d1b3cc957abc
When constructing a Loader without passing a document, we added a DocGroup
parameter so that we could still use it to dispatch events to the DocGroup.
Delete NS_ENSURE_TRUE because new() is infallable.
Use another runnable pointer for calling dispatching because forget() will
nuke the pointer and we need to use evt afterwards.
MozReview-Commit-ID: Ce2K6j4pUhA
--HG--
extra : rebase_source : 2bacf1f856e0700f36b2fefe4d2424719cad77a7
Users in nightlies are hitting the assertion in UnblockParser that ensures the
parser is blocked. The only way that should be able to happen is if the
initial parser is destroyed and a new one is created before we try to unblock.
In theory, that shouldn't happen for the initial parser when it's blocked
this early, so my best guess is that an add-on is ending the document load and
then re-opening the document.
MozReview-Commit-ID: iQkE2aWDTZ
--HG--
extra : rebase_source : a5f225cf45dc3552059b347f441120fea6476ccd
extra : amend_source : ed393f79c7626c65af33638da140f235a2d97743
In order to asynchronously load content scripts that need to run very early in
the page load cycle, before any ordinary page scripts, we need to be able to
block parsing from the document-element-inserted listener. Since the script
loader operates by returning promises, blocking on promise resolution is the
simplest way to achieve this.
MozReview-Commit-ID: CTWlyrP6dqG
--HG--
extra : rebase_source : 28ce713a6450c223f9b2089e6c6e8c78284ef8af
1. The current asynchronous behavior is pointless, because we still remove the
hashtable entry synchronously, which deletes the value, and it's the value
we're using.
2. Trying to asynchronously delete the value is difficult, and not currently
needed because we can't get a memory-pressure notification while we're using
the value, and hence can't expire it from the expiration tracker.
Note: we can't get this memory-pressure notification because the stage 2 of
mozalloc_handle_oom() to reclaim memory when OOM is not implemented yet.
The previous implementation regarding to the Flash Blocking Subdocument list blocked all subdocuments that matched the list. This patch changes that so that subdocuments are only blocked if they are on the Subdocument Block List and also are loaded in a Third-Party context.
The changes to cert8.db and key3.db add the https certificate for subdocument.example.com so that testing can verify that a scheme mismatch between the document and its parent results in a third-party classification.
MozReview-Commit-ID: IXnA4iPzB4y
--HG--
extra : rebase_source : 103c1e184d4219e6db9d00da1ea54674a0e216dd
In bug1319771, we found that the tab would become visible unexpectly in short
period in some situations. We don't want to resume the tab in this kind of
situation, so we check whether there is any alive media component in the tab
using IsServiceStarted(). However, since we have lots different ways to create
the service, this function is not accurate at all.
Therefore, we can add media element directly to the document when it binds to
tree so that we can really know whether there is any alive media component.
MozReview-Commit-ID: FvZFg91IqgE
--HG--
extra : rebase_source : 43c2460f6e9a39d44bf2ca1638c992a0e27b196c
Ehsan Akhgari
Xidorn Quan
Bevis Tseng
Kris Maglione
Kirk Steuber
Boris Zbarsky
Alastor Wu
Iris Hsiao
Carsten "Tomcat" Book
Andrea Marchesini
Gijs Kruitbosch
Mantaroh Yoshinaga
Manish Goregaokar
Wes Kocher
Ting-Yu Lin
Sebastian Hengst
Cameron McCormack
Samael Wang
Wei-Cheng Pan
Ben Kelly
Brad Werth
Jessica Jong