Closed Bug 952602 Opened 7 years ago Closed 6 years ago

Disable bug 757726 for Firefox 28 release (changes to plugin detection)

Categories

(Core :: Plug-ins, defect)

28 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla28
Tracking Status
firefox28 + verified
firefox29 --- verified
firefox30 --- verified
firefox31 --- verified

People

(Reporter: cpeterson, Assigned: cpeterson)

References

(Depends on 1 open bug)

Details

(Whiteboard: [28b5])

Attachments

(1 file)

No description provided.
#ifdef EARLY_BETA_OR_EARLIER to disable navigator.plugins[] cloaking before GA release.

I would like to land this patch on Aurora 28 so it will be ready before the merge to Beta 28. I do not plan to land this patch mozilla-central, so this patch should only affect Firefox 28 as it rides the train.
Attachment #8355122 - Flags: review?(benjamin)
See Also: → 952914
Attachment #8355122 - Flags: review?(benjamin) → review+
Comment on attachment 8355122 [details] [diff] [review]
ifdef-plugin-cloaking.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 757726 in Firefox 28
User impact if declined: Some websites using plugins will stop working
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): Low risk. This patch just #ifdefs off a new feature after the EARLY_BETA_OR_EARLIER period. Bug 757726 requires some websites to fix their plugin detection code (for uncommon plugins). This code is currently in Aurora 28, but we would like to get some test time in Beta 28 to find more broken websites that need tech evangelism to fix their code. But we want to disable this feature in Beta 28 before GA Release 28.
String or IDL/UUID changes made by this patch: None
Attachment #8355122 - Flags: approval-mozilla-aurora?
Attachment #8355122 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/54f62d5771bf

#ifdef EARLY_BETA_OR_EARLIER includes Nightly, Aurora, and the first 2.5 weeks of Beta (beta releases 1-4).

I'm leaving this bug open as a reminder to verify that this feature is disabled during Beta 28.
Keywords: verifyme
Catalin, please verify that this is disabled in 28.0b1 once it builds next week.
Flags: needinfo?(catalin.varga)
QA Contact: catalin.varga
Catalin and Anthony: as noted in comment 3, this feature is expected to be enabled for the first four releases of Beta 28. So you don't need to verify whether this feature is disabled until the end of February.
Okay, thanks Chris. I've added a whiteboard tag to show this applies starting with Firefox 28b5.
Whiteboard: [28b5]
I'll verify this in FF 28b5 .
Flags: needinfo?(catalin.varga)
Hi I've verified this bug on:
FF 28.0b6 
Build id: 20140224220227
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0

and the "disallow enumeration of navigator.plugins" feature is not disabled on this build.
Is this expected behavior or the feature should have been disabled after 28.0b4?
Flags: needinfo?(cpeterson)
Thank you for catching this problem, Catalin! Release management forgot to disabled features marked EARLY_BETA_OR_EARLIER.
Flags: needinfo?(cpeterson)
Verified fixed by https://hg.mozilla.org/releases/mozilla-beta/rev/72efe9bb86a9
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
I've verified this bug on:

FF 28.0b8 
Build id: 20140303165517
OS: Win 8 x64, Mac OS x 10.9, Ubuntu 12.04 x86

The feature is disabled.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Comment on attachment 8355122 [details] [diff] [review]
ifdef-plugin-cloaking.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): 
String or IDL/UUID changes made by this patch:

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: Some sites that use uncommon plugins will break when Firefox 28 is released.
Testing completed (on m-c, etc.): Aurora 28 and Beta 28
Risk to taking this patch (and alternatives if risky): Very low risk.
String or IDL/UUID changes made by this patch: None

I landed this patch to disable this plugin detection change (using #ifdef EARLY_BETA_OR_EARLIER) in Aurora 28. Firefox 28 has now shipped, but this feature is not ready to ship with Firefox 29. I would now like to land this patch on all channels (Nightly 31, Aurora 30, and Beta 29) until I have a complete solution for regressions from this plugin detection change.
Attachment #8355122 - Flags: approval-mozilla-beta?
Attachment #8355122 - Flags: approval-mozilla-aurora?
Attachment #8355122 - Flags: approval-mozilla-aurora+
Attachment #8355122 - Flags: approval-mozilla-beta?
Attachment #8355122 - Flags: approval-mozilla-beta+
Attachment #8355122 - Flags: approval-mozilla-aurora?
Attachment #8355122 - Flags: approval-mozilla-aurora+
I have removed the site compatibility info from the doc:
https://developer.mozilla.org/en-US/Firefox/Releases/29/Site_Compatibility$compare?to=542503&from=537455

A tweet from @MozWebCompat coming.
Blocks: 990808
I've verified this bug on:

FF 29.0b5 
buildID=20140403132807
OS: Win 7 x64, Mac OS x 10.9, Ubuntu 13.10 x64

The feature is disabled.
I've verified this on:

FF Aurora 30
Build Id: 20140425004002
OS: Win 7 x64, Mac Os 10.9

It seems that the feature was not disabled.
I've installed several plugins( eg: Unity. Silverlight, Avg and VLC) and only Java, QuickTime, Flash, and Shockwave are displayed.
It's #ifdef EARLY_BETA_OR_EARLIER, so Aurora builds are expected to have it enabled.
That was my mistake, thanks for the quick clarification
I've verified the bug on the following environment:

FF 30.0b2 
Build Id: 20140505140302
OS:Mac Os X 10.7, Mac Os X 10.9, Ubuntu 13.04 x64, Win 7 x64

The feature is disabled.
I've verified this bug on the FF 31.0b6 build and I've noticed some strange behaviors:

- not all plugins are displayed in the plugincheck and that let me believe that disallow enumeration of plugins is not disabled or some of the plugins are not displayed on 31.0b6
- with the assumption that some of the plugins are not displayed due to disallow enumeration being enabled, I,ve noticed that between FF 28.0b1 and FF 31.0b6 some of the plugins became visible even with the feature enabled eg: Unity, Google Earth and Silverlight.

Are we leaving disallow enumeration enabled to reach the release at the same time as plugin whitelist feature or is something else happening? Can you please provide feedback?
Flags: needinfo?(cpeterson)
Catalin: plugincheck was updated (in bug 938885) to not use plugin enumeration. plugincheck now uses a list of all plugins (that it has version information for) to query navigator.plugins[] for each plugin by name. So plugincheck will show plugins that are hidden when plugin detection is disabled, but it won't show plugins that it has no version information for.
Flags: needinfo?(cpeterson)
See Also: → 938885
Hi Chris in order to verify this bug my understanding is that I need access to the list published by the server and compare it with my installed plugins( eg: https://plugins.mozilla.org/en-us). Is my assumption correct? and if yes can we get access to the list? for the moment the page requires authentication.
Flags: needinfo?(cpeterson)
Hi Catalin, anyone can read plugincheck's list of known plugins, but it is an ugly JSON file: https://plugins.mozilla.org/en-us/plugins_list.json

To test the new plugincheck, compare your list of installed plugins (from about:plugins) with the list of plugins displayed when you visit the plugincheck web page. Then Verify that:

1. the plugins displayed by plugincheck are in plugins_list.json
2. your installed plugins *not* displayed by plugincheck are also *not* in plugins_list.json

This will test that plugincheck is only checking (and displaying) plugins from its list of known plugins.

Note that the plugin names in plugins_list.json are a little different from the names on the about:plugins page. For example, Adobe Flash is listed as "Shockwave Flash" on about:plugins but with a friendlier name "Adobe Flash Player" in plugins_list.json (so the plugincheck web page is user-friendly). You might need to get a little creative when searching for the plugin's user-friendly name. You might try searching plugins_list.json for the plugins' version numbers (e.g. I have Flash version "14.0.0.145" installed) because the version numbers will be unchanged, though different plugins might have the same version numbers.
Flags: needinfo?(cpeterson)
(In reply to Chris Peterson (:cpeterson) from comment #25)
> Hi Catalin, anyone can read plugincheck's list of known plugins, but it is
> an ugly JSON file: https://plugins.mozilla.org/en-us/plugins_list.json
> 
> To test the new plugincheck, compare your list of installed plugins (from
> about:plugins) with the list of plugins displayed when you visit the
> plugincheck web page. Then Verify that:
> 
> 1. the plugins displayed by plugincheck are in plugins_list.json
> 2. your installed plugins *not* displayed by plugincheck are also *not* in
> plugins_list.json
> 
> This will test that plugincheck is only checking (and displaying) plugins
> from its list of known plugins.
> 
> Note that the plugin names in plugins_list.json are a little different from
> the names on the about:plugins page. For example, Adobe Flash is listed as
> "Shockwave Flash" on about:plugins but with a friendlier name "Adobe Flash
> Player" in plugins_list.json (so the plugincheck web page is user-friendly).
> You might need to get a little creative when searching for the plugin's
> user-friendly name. You might try searching plugins_list.json for the
> plugins' version numbers (e.g. I have Flash version "14.0.0.145" installed)
> because the version numbers will be unchanged, though different plugins
> might have the same version numbers.

We`ve tested using your provided steps and found some plugins that appear in plugins_list.json and about:plugins but they don`t appear in https://www.mozilla.org/en-US/plugincheck/. 
I`ve filled bug 1038685 on that. We`ve tested on Windows 7 64bit, Mac OS X 10.9.4 and Ubuntu 14.04 32bit using Firefox 31.0RC. 

Please let me know if there is anything I can help with.
Flags: needinfo?(cpeterson)
Thanks for testing, Bogdan. We can track the VLC plugin issue in bug 1038685 you reported.
Flags: needinfo?(cpeterson)
(In reply to Chris Peterson (:cpeterson) from comment #27)
> Thanks for testing, Bogdan. We can track the VLC plugin issue in bug 1038685
> you reported.

Then I will mark this bug verified on Firefox 31 as well.
You need to log in before you can comment on or make changes to this bug.