1561827 - Flash plugin's `File` and `MIME Types` fields are empty in HTML about:addons

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Chris Peterson [:cpeterson]]

Attachment: Shockwave_Flash_Options.png

[Tracking Requested - why for this release]:

This bug is a regression in Firefox 68 from bug 1555012.

Steps to reproduce

1. Open about:addons.
2. Click "Plugins".
3. Click "Shockwave Flash".
4. Click "Options".

Expected results

The File field's value should be something like NPSWF64_32_0_0_207.dll. The MIME Types field's value should be application/x-shockwave-flash (Adobe Flash movie: swf), application/futuresplash (FutureSplash movie: spl).

Actual results

The File and MIME Types fields have no values. See the attached screenshot.

Comment 1

[Julien Cristau [:jcristau]]

Rob can you have a look and triage this? Thanks!

Comment 2

[Rob Wu [:robwu]]

Patch incoming.

Comment 3

[Rob Wu [:robwu]]

Attachment: Bug 1561827 - Move pluginPrefs initialization to pluginPrefs.js

The plugin preference rendering logic was in PluginProvider.jsm and
was tightly coupled to the markup of the XUL about:addons page,
and therefore does not work with the HTML about:addons page.

Fix this by moving the rendering logic to pluginPrefs.js (which is
loaded by pluginPrefs.xul), and updating the browser_pluginprefs.js unit
test to ensure that the rendering works as expected.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5d560c5e357d
Move pluginPrefs initialization to pluginPrefs.js r=Gijs

Comment 5

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/5d560c5e357d

Comment 6

[Rob Wu [:robwu]]

Comment on attachment 9074495 [details]
Bug 1561827 - Move pluginPrefs initialization to pluginPrefs.js

Beta/Release Uplift Approval Request

• User impact if declined: The "File" and "MIME types" rows of the flash plugin are empty instead of showing the expected metadata.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch moves around existing code and includes a unit test that verifies the expected behavior.
• String changes made/needed: none

Comment 7

[Julien Cristau [:jcristau]]

Comment on attachment 9074495 [details]
Bug 1561827 - Move pluginPrefs initialization to pluginPrefs.js

HTML about:addons fix for plugin prefs, approved for 68 rc1

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-release/rev/d987305774de

Comment 9

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-esr68/rev/d987305774de

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backed out because isFlashPlugin needs to be a method of a plugin in the new code but it's a function of PluginProvider.jsm (conflict with bug 1519434):
https://hg.mozilla.org/releases/mozilla-release/rev/2d818026aa0b85ce91d0cbd401d7833961408f55
https://hg.mozilla.org/releases/mozilla-esr68/rev/8e3d59d881261610fb366644dad874080d889a40

Comment 11

[Rob Wu [:robwu]]

Attachment: Bug 1561827 - Move pluginPrefs initialization to pluginPrefs.js (for 68)

The plugin preference rendering logic was in PluginProvider.jsm and
was tightly coupled to the markup of the XUL about:addons page,
and therefore does not work with the HTML about:addons page.

Fix this by moving the rendering logic to pluginPrefs.js (which is
loaded by pluginPrefs.xul), and updating the browser_pluginprefs.js unit
test to ensure that the rendering works as expected.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/4039b7434fea

Comment 13

[Rob Wu [:robwu]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/4039b7434fea4a3a6dfcbe5250e83fc582b1f4b2

Comment 14

[Victor Carciu]

Verified as fixed in FF 68.0 and 69.0a1 (2019-07-02) on Win10x64 and macOS 10.13.6

The File field's value on macOS is "Flash Player.plugin" instead of something something like "NPSWF64_32_0_0_207.dll" how is for Windows.

Please let me know if this is the expected behavior.

Comment 15

[Rob Wu [:robwu]]

(n reply to Victor Carciu from comment #14)

The File field's value on macOS is "Flash Player.plugin" instead of something something like "NPSWF64_32_0_0_207.dll" how is for Windows.

Please let me know if this is the expected behavior.

Looks good to me.

Comment 16

[Victor Carciu]

Verified as fixed also in 68.0esr (64-bit) on Win10x64 and macOS 10.13.6