I've been having problems with interdiffs on mozreview lately, so for
ease of review, this patch is being submitted as a seperate patch for
review. Once it is r+'d, it will be folded into the first patch in
this set before landing.
MozReview-Commit-ID: CS9MngaXlBd
--HG--
extra : rebase_source : 6a86fd4f7a66e73497a756976a2562d183002a2a
Removes applet tag interfaces, and changes HTML5 parser to output
HTMLUnknownElement when tag is found. Removes tag process from various
places in the browser.
MozReview-Commit-ID: 2zHhK2U2esX
--HG--
extra : rebase_source : d06ecaffd1cb656301e29b900bafde4c68a4606e
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
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.
--HG--
extra : rebase_source : c39560bdf66cda1a005c7b823b3a46e4734878a4
extra : source : 9cba1db527c7eed4371c9f4caf96fd942608cab6
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
--HG--
extra : rebase_source : 25799e27c6a2eb50d5ee3aded0d66fe6bb05c52b
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>
--HG--
extra : rebase_source : 11900af908654336cc2391ab9480542c5474e38f
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
