Every JS plugin is assigned a unique ID. When an instance of a JS plugin is created the
frame loader that we use to load the plugin's handler URI will create a special
TabContext. This TabContext causes the ContentParent to use the process for this specific
JS plugin (creating one if it hasn't already) when it creates the PBrowser actors.
This causes the iframes for all the instances of a specific JS plugin to be grouped in the
same process.
This patch is mainly for ObjectLoadingContent. Since there is no any runnable
between setting src and creating channel, I check urgent-start just after
creating channel.
MozReview-Commit-ID: IoishRqENBM
It's not only inefficient, but also prone to buggyness. Since styles may not be
up-to-date when it happens.
Post a reconstruct instead, which ensures a style flush happens before running
frame construction.
MozReview-Commit-ID: DrakHsJv5fY
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
We know these rewritable YouTube Flash embeds are out there. We don't need to track that we're rewriting them. While only about 0.4% of browser sessions saw rewritable embeds in April 2017, compared to almost 2% in April 2016, is there any reason we would decide to stop rewriting these embeds?
If YouTube ever stops serving Flash video entirely, then we should remove the enablejsapi check (YOUTUBE_NONREWRITABLE_EMBED_SEEN) so users at least see a non-scriptable video instead of nothing.
MozReview-Commit-ID: IixKc6myvs6
Firefox 51 users with telemetry enabled blocked about 4.35M SWFs for stability. The block count has been in the single-digit millions for the last few releases. We don't expect these SWFs to go away, so we can stop tracking this telemetry and later replace this plugin blocklist with a more general solution.
MozReview-Commit-ID: KF1jIBTG5m4
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
Since the Shumway project is dead, we no longer register a stream converter for flash files. We can remove this check, as it will always return false.
MozReview-Commit-ID: CzC7wYmWEFp
* * *
Bug 1282485 - Plugin fallback rule - don't use fallback when the descendant has an embed element
* * *
Bug 1316102 - Plugin fallback rule - use fallback when it contains a <video> element
* * *
Bug 1282487 - Plugin fallback rule - don't use fallback when it contains links to adobe.com
* * *
Bug 1282486 - Plugin fallback rule - don't use fallback when it contains 'install Flash' instructions
MozReview-Commit-ID: DexVBrAfaTb
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
