887245 - Plugincheck should not link to itself on the "update now" button

Status: VERIFIED FIXED

(Websites :: plugins.mozilla.org, defect)

Description

[Carsten Book [:Tomcat]]

Testcase:
-> Outdated Adobe Reader Install
-> Plugincheck detect the install as vulnerable
-> Red Update now button occurs
The link on this button goes back to plugincheck (?)

Comment 1

[Schalk Neethling [:espressive]]

(In reply to Carsten Book [:Tomcat] from comment #0)
> Testcase:
> -> Outdated Adobe Reader Install
> -> Plugincheck detect the install as vulnerable
> -> Red Update now button occurs
> The link on this button goes back to plugincheck (?)

So, here is the code that builds the URL used for the buttons:

url: pfsInfo.releases.latest ? pfsInfo.releases.latest.url : ''

which means if the following section exists in the returned JSON it will use the latest URL from their else, it will return an empty string.

"releases": {
               "latest": {
                   "status": "latest", 
                   "app_release": "3.5", 
                   "app_version": "*", 
                   "vendor": "Adobe", 
                   "pfs_id": "adobe-flash-player", 
                   "url": "http://www.adobe.com/go/getflashplayer", 
                   "modified": "2009-09-18T23:09:55+00:00", 
                   "app_id": "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}", 
                   "locale": "ja-JP", 
                   "version": "11.0.0.0", 
                   "license_url": "http://www.adobe.com/go/eula_flashplayer_jp", 
                   "guid": "{89977581-9028-4be0-b151-7c4f9bcd3211}", 
                   "xpi_location": "http://fpdownload.macromedia.com/get/flashplayer/xpi/current/flashplayer-mac.xpi", 
                   "os_name": "mac", 
                   "name": "Adobe Flash Player"
               },

Comment 2

[Carsten Book [:Tomcat]]

Hey Brandon, could this be a problem with PFS2 that pfs2 is pulling the wrong field (as example not url field) here for the url for the update now buttons?

Comment 4

[Frank Wein [:mcsmurf]]

I wanted to take a curious look at this, but: Where does the pluginfinderservice JS code live? In https://github.com/ozten/Perfidies-of-the-Web/tree ? In http://viewvc.svn.mozilla.org/vc/projects/plugindir/trunk/ ? Somewhere else?

Comment 5

[Schalk Neethling [:espressive]]

(In reply to Frank Wein [:mcsmurf] from comment #4)
> I wanted to take a curious look at this, but: Where does the
> pluginfinderservice JS code live? In
> https://github.com/ozten/Perfidies-of-the-Web/tree ? In
> http://viewvc.svn.mozilla.org/vc/projects/plugindir/trunk/ ? Somewhere else?

It lives here now:

https://github.com/ossreleasefeed/Perfidies-of-the-Web

Please note that this is undergoing a major rewrite.

Comment 6

[Frank Wein [:mcsmurf]]

So I think there are two problems here:
1. The recursive link when no link is set in the database (don't do that in general?)
2. The Google earth plugin JSON response having no URL. Not sure about Comment 0 in that bug here where the Adobe Reader issue came from.

Comment 7

[Schalk Neethling [:espressive]]

(In reply to Frank Wein [:mcsmurf] from comment #6)
> So I think there are two problems here:
> 1. The recursive link when no link is set in the database (don't do that in
> general?)
> 2. The Google earth plugin JSON response having no URL. Not sure about
> Comment 0 in that bug here where the Adobe Reader issue came from.

I guess we need to decide what to do when the PFS service does not return a URL, so one:

1) Provide the user with a message stating that no URL was specified to update the plugin and offer them an option to search google for the latest plugin.

2) Not show the update now button at all but instead, show the research button.

With both of these we have some considerations in terms of l10n as has been highlighted here:

https://bugzilla.mozilla.org/show_bug.cgi?id=898766

Thoughts?

Comment 8

[Frank Wein [:mcsmurf]]

Bug 889751 is now about problem #2, so this bug here can deal with problem #1 (and Comment 0 if needed)

Comment 9

[Schalk Neethling [:espressive]]

So Carsten and/or Frank,

This bug is then related to

1. The recursive link when no link is set in the database (don't do that in general?)

Which of the suggestions in comment 7 (https://bugzilla.mozilla.org/show_bug.cgi?id=887245#c7) makes the most sense or, do you have another suggestion? Thanks!

Comment 10

[Frank Wein [:mcsmurf]]

I would implement suggestion #2. This makes it easier for you and localizers (no new string to translate for now). After all it should happen only rarely that we know about the plugin, but have no URL for it. In the case of the Google Earth plugin the missing URL looks like a mistake.

Comment 11

[Schalk Neethling [:espressive]]

Sent pull request: https://github.com/mozilla/bedrock/pull/1151

Comment 12

[Schalk Neethling [:espressive]]

Can someone provide me with info on a plugin I can install that exhibits this behavior for testing?

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Schalk Neethling [:espressive] from comment #12)
> Can someone provide me with info on a plugin I can install that exhibits
> this behavior for testing?

The Unity Player, on Windows, at least, exhibits the same-link problem:

http://unity3d.com/webplayer

Comment 14

[Schalk Neethling [:espressive]]

stephend on IRC also mentioned Google Talk PluginVersion 4.4.2.14502 which can be installed on Mac as a culprit.

Comment 15

[Schalk Neethling [:espressive]]

Ok so here is what I did. I set-up a Windows VM and then downloaded and installed an old version of the Unity Web Player that I found at this URL: http://answers.unity3d.com/questions/26420/where-can-i-find-older-versions-of-the-web-player.html (second link from the first answer)

After installing this I opened up plugincheck and the player shows up as unknown, as expected, with the research button pointing to a Google search for the latest version. Downloaded and installed the latest version, refreshed plugincheck and it then shown up as up to date.

So all and all, this work with two small changes I made during the testing phase.

Comment 16

[[github robot]]

Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/ef58c86b68138de9d45c25a5c7d670ae82e79ebf
Fix Bug 887245, point plugins with no update URL to google not to plugincheck itself

https://github.com/mozilla/bedrock/commit/7798d8a17a1f1d8815d999a44b65eb5fd3ca5d8e
Merge pull request #1151 from ossreleasefeed/bug887245-plugincheck-should-not-link-to-self-on-update-button

Fix Bug 887245, point plugins with no update URL to google not to plugincheck itself

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED for me on https://www-dev.allizom.org/en-US/plugincheck/

Comment 18

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED for me on prod, now, too:

http://www.mozilla.org/en-US/plugincheck/

Comment 19

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Post-fix screenshot

Comment 20

[Carsten Book [:Tomcat]]

i guess this is fixed now :)