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
--HG--
extra : rebase_source : f1f9f7ea9cffc585f95ff83dbeedd734e0b83cc3
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
--HG--
extra : rebase_source : 5dbdfadfed4f88da33fb4f2efc66c7dd1777b2b3
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 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
--HG--
extra : rebase_source : 24373bc48da66fccb616864a6f03a5fc5d57ba9c
* * *
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.
The idea is to not make consumers think about whether the principal exists or
not when the caller knows for sure that it does.
The substantive changes are in dom/bindings, nsHTMLDocument::SetDesignMode, and
around the CanUseStorage bits. Everything else is pretty mechanical.
