Closed Bug 1023718 Opened 10 years ago Closed 7 years ago

Plugin checker for newly installed FF 30.0 shows Adobe Acrobat plugin "vulnerable" but update button just reloads plugin checker

Categories

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

Product:
Websites
Component:
plugins.mozilla.org
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: dannyfox, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

Updated to FF 30.0 (from 29.0.1).  Run ADD-ONs manager and "check to see if my add-ons are up to date".  Adobe Acrobat "NPAPI" plugin Version 11.0.7.79 was flagged as vulnerable.  Pressed red UPDATE button.


Actual results:

Plugin UPDATE button just caused the plugin checker page to reload.  Even mousing over the button, you can see the target is the plugin checker, whereas other buttons go elsewhere.


Expected results:

Plugin UPDATE should have connected to Adobe.com or similar to download a fix (or tell me one isn't available).
You probably need to know this:
https://www.mozilla.org/en-US/plugincheck/

I can't get this to load (as mentioned in Bug 861407) -- it just goes to the en-US version:
https://www.mozilla.org/en/plugincheck/
Component: Untriaged → plugins.mozilla.org
Product: Firefox → Websites
QA Contact: cbook
Version: 30 Branch → unspecified
Depends on: 1020133
Bug 1020133 reports on the accuracy of the plugin checks for Acrobat (and others), not the action of the UPDATE button.  Looks like the action is intended to be neutral ("do nothing", "do no harm") at this point.

But I'd prefer to have a warning, or an indication that there is no update or there is an error -- something -- rather than an action that a user such as myself would conclude is faulty.
BTW: The reload thing reminds me of Bug 887245 (just mentioning, not sure if it's actually related).
(In reply to Frank Wein [:mcsmurf] from comment #3)
> BTW: The reload thing reminds me of Bug 887245 (just mentioning, not sure if
> it's actually related).

Frank, that does sound the same.  BTW, the Adobe thing (Acrobat here, Reader in 887245) just happens to be what failed, thereby causing the problem with the UPDATE button to surface.  How Adobe gets checked may be partially responsible (maybe they don't provide a good link), but something other then loop & reload should occur.  (And everybody has Adobe, but I suspect other software updates may also experience the bug occasionally.)
Dan,
As you have discovered from bug 1020133 the Acrobat reporting is NOT OK
in the 'new plugincheck service'.

(In reply to Dan Pernokis from comment #0)
> Actual results:
> 
> Plugin UPDATE button just caused the plugin checker page to reload.  Even
> mousing over the button, you can see the target is the plugin checker, whereas
> other buttons go elsewhere.

Dan, I see this too.
If you are "mousing over" any of the 'buttons in the Action column' you will see
a URL of 'where you are about to go' if you click the button.

In my case,
Using Aurora (and the 'new plugincheck' - with NO enumeration) I also have a
link to my %LOCALE% plugincheck site for Acrobat
https://www.mozilla.org/en-GB/plugincheck/ (in my GB case)

For "Google Earth Plugin", which is "Up to Date", I also get the same link
https://www.mozilla.org/en-GB/plugincheck/ (in my GB case)

For "Adobe Flash Player" which is now "Up to Date" (I updated to 14.0.0.125
after I had done some tests to see if 13.0.0.214 was being detected - bug 1023838)
I get a link to 
http://get.adobe.com/flashplayer/

So, I think this is a reflection on the 'quality of the database', that is
used to make the JSON list, that is then used at the 'plugincheck web site'.

I speculate wildly that 'where there is no web site to go to' in the
Plugincheck database then the default is to 'stay on the plugincheck site'.

In a case like this, you click the button and you come back to the plugincheck.

FYI,
I can ALSO, by UA spoofing, use the 'old plugincheck' (which uses enumeration)

See DJ-Leith in bug 956905 comment # 143
> ... ... [near the end of the comment]
> 
> Some Good News:
> 
> UA spoofing helps
> (see my comment in bug 1010132 comment # 19)
> 
> Using Release with
> 
> user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0)
> Gecko/20100101 Firefox/29.0.1");
> 
> combined with
> "plugins.enumerable_names" set to "*"
> 
> I get a *very* similar result to this:
> https://bug1010132.bugzilla.mozilla.org/attachment.cgi?id=8426517
> 
> These settings will give you the 'most accurate result'
> That is
> "Adobe Acrobat" 11.0.7.79 "Up to Date" - correct
> and you still have the "Unknown" plugins.
> 
> The 'result for Flash' is wrong
> because the Plugin database needs updating (see bug 1023838).

For Reader (in the old plugincheck service) the link is
http://get.adobe.com/reader/ which Adobe redirect to the UK site:
http://get.adobe.com/uk/reader/ in my case.

On the 'old plugincheck' (which uses enumeration) I also have an
"Unknown" (which happens to be a Google Update plugin) and the link is a 
'google search for the current version of Google Update plugin'.

I think "Unknown" buttons have always (since August 2010) worked
like this: have a customised search.

See bug 1023946 "Plugincheck Redirect" - which I would regard as a
Duplicate of this bug.

(In reply to Dan Pernokis from comment #1)
> You probably need to know this:
> https://www.mozilla.org/en-US/plugincheck/
> 
> I can't get this to load (as mentioned in Bug 861407) -- it just goes to the en-US version:
> https://www.mozilla.org/en/plugincheck/

I don't quite understand.
In "about:config" search for
"plugins.update.url"
I expect it to be
"https://www.mozilla.org/%LOCALE%/plugincheck/"


DJ-Leith
In reply to DJ-Leith:
>> I speculate wildly that 'where there is no web site to go to' in the
>> Plugincheck database then the default is to 'stay on the plugincheck site'.

I agree we should stay on the page, but there are better ways to stay on a page besides reloading it.  (Clicking the UPDATE button makes it seem like something should happen, and when it doesn't, it confuses the user and looks like a faulty button.)

(1) If there is no update, the UPDATE button can be replaced with something else, such as an image that says "No Update Available", or a phrase of text explaining the situation.
(2) A click can be intercepted to make a pop-up that says no update is available, with fuller explanation than would fit on a line of text in (1).
(3) The URL-constructing code can return a null href which would be ignored by a click.  (This trick allows the <a> tag, as in <a href="">, to inherit all its styles & attributes without actually having an href spec to follow.)

And my situation trying to load the /en/ plugin checker:  I typed or pasted the URL to mozilla and mozilla automatically forwarded (re-routed) me to the /en-US/ version.  Actually, I'm in Canada but we (US & Canada) often share the same or similar settings, one for both of us, etc.  (I was just curious to see if I could easily fudge going back to the old one...)
I'm seeing this on Windows 7 with the latest version of Adobe Reader (currently 11.0.07). Also reported by someone on Windows Vista.
https://support.mozilla.org/questions/1005686
Status: UNCONFIRMED → NEW
Ever confirmed: true
Schalk,

thanks for the bedrock bug (see below).

(DJ-Leith said in bug 956905 comment # 145)
> 
> Adobe Acrobat 11.0.7.79 - the 'correct result' should be "Up to Date"
> 
> Tests done on 2014-06-12 at both STAGE and LIVE with 3 browsers:
> 
> STAGE
> https://www.allizom.org/en-US/plugincheck/
> 
> LIVE
> https://www.mozilla.org/en-GB/plugincheck/ (in my GB case)
> 
> Fx 30 - with NO enumeration - "plugins.enumerable_names" set to "" (empty string)
> Adobe Acrobat reported as "vulnerable" - WRONG.
> 
> Fx 30 (UA spoof to 29.0.1) - "plugins.enumerable_names" set to "*" [all plugins enumerated]
> Adobe Acrobat reported as "Up to Date" - good.
> 
> Fx 31.0a2 - with NO enumeration - "plugins.enumerable_names" set to "" (empty string)
> Adobe Acrobat reported as "vulnerable" - WRONG.

The above tests were done before 2014-06-12 03:00:00 PDT

Good News

Now that bug 1024435 "Bump version of plugincheck.next to 30", the bedrock bug, has completed,
repeating the 6 tests, I have the results we were hoping for:

Fx 30 - with enumeration - "plugins.enumerable_names" set to "*" [all plugins enumerated]
Adobe Acrobat reported as "Up to Date" - good.
"plugins.enumerable_names" set to "*" is the default in Fx 30.

Fx 30 (UA spoof to 29.0.1) - "plugins.enumerable_names" set to "*" [all plugins enumerated]
Adobe Acrobat reported as "Up to Date" - good.
UA spoofing is 'not normal'.

Fx 31.0a2 - with NO enumeration - "plugins.enumerable_names" set to "" (empty string)
Adobe Acrobat reported as "vulnerable" - WRONG.
We know this.  We have another few weeks to get the 'new plugincheck' working
without ANY enumeration (possibly for Fx 31 - not my decision).

Main Acrobat Bug is:
Bug 1020133 "Improve Adobe Acrobat plugin reporting"
I will put in a cross ref to this bug.


Main Acrobat bug - since the Release of Fx 30 is:
*this* bug 1023718
"Plugin checker for newly installed FF 30.0 shows Adobe Acrobat plugin "vulnerable"
but update button just reloads plugin checker"

Possible Duplicates of bug 1023718 include:

Bug 1023946 "Plugincheck Redirect" 

Bug 1023653 "Adobe Acrobat plugin on Windows detected as Mac, can't update" 
Schalk, bug 1023653 comment # 4 has useful data from the JSON list.

Bug 1024323 "[plugincheck] Adobe Acrobat NPAPI Plug-in update link leads nowhere"

Schalk, 
Many good points have been made by users in the Duplicates and at
SUMO (linked in the Duplicates).

Also, if you search bugzilla for plugins bugs

https://bugzilla.mozilla.org/buglist.cgi?all=&component=plugins.mozilla.org&product=Websites&query_format=advanced&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0

you will see that Gingerbread Man has, around 2014-05-28, opened several new bugs
to get more Plugins into the Database.

DJ-Leith
Noteworthy to mention again as the bug still exists through Aurora 32.0a2 (2014-07-21).

AU: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Greetings... I'm on FF Beta and am running into the same issue.

The exact link I see 'under' the Update Now button (for Adobe NPAPI) is:

https://www.mozilla.org/en-US/plugincheck/?utm_source=firefox-browser&utm_medium=firefox-browser&utm_campaign=plugincheck-update

Also, when I got the 'blocked plug-in screen' (can't get it now), this is what it said:
----------
(link: https://addons.mozilla.org/en-US/firefox/blocked/p89)

Adobe Acrobat NPAPI Plug-in has been blocked for your protection.

Why was it blocked?
    The Adobe Acrobat plugin doesn't work on Mac OS X in default (64-bit) mode, showing a blank page when users click on links to PDF files in Firefox. It also causes a significant number of crashes in 32-bit mode.

    There's more information on this blog post.
Who is affected?
    Firefox users on Mac OS X who have installed the Adobe Acrobat plugin.
What does this mean?

    Users are strongly encouraged to disable the problematic add-on or plugin, but may choose to continue using it if they accept the risks described.
    When Mozilla becomes aware of add-ons, plugins, or other third-party software that seriously compromises Firefox security, stability, or performance and meets certain criteria, the software may be blocked from general use. For more information, please read this support article.

Blocked on May 4, 2012. View block request.
-----

It states MAC OS more than once.
=============

I went and checked Adobe for updates to Reader... I'm up to date. I went ahead and 'repaired' my installation and will report back after I reboot, if something changes.

I'm running Adobe Reader Version: 11.0.8.4

Thank you.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
I am CCing Schalk Neethling [:espressive] who has been doing a lot of work on Plugincheck.

This bug "Depends on:" bug 1020133 "Improve Adobe Acrobat plugin reporting".
It is the main bug for this issue.

In bug 1053417 comment # 3 I have explicitly referred to this bug as I'm not sure Schalk had read it.

rapier216 the extra data, about how the 'Plugincheck Service seems to think you had a Mac plugin',
when you are on Windows, makes sense to me but it is Schalk who needs to see this, and alter
'how the new Plugincheck (using the JSON List)' detects (and then tests) the
'Adobe Reader' AKA 'Adobe Acrobat' plugins.

(in reply to rapier216 from comment #13)
> I'm running Adobe Reader Version: 11.0.8.4
You are up to date, the 'new Plugincheck Service' is wrong.


(in reply to rapier216 from comment #13)
> The exact link I see 'under' the Update Now button (for Adobe NPAPI) is:
> 
> https://www.mozilla.org/en-US/plugincheck/?utm_source=firefox-browser&utm_medium=firefox-browser&utm_campaign=plugincheck-update

FYI, in Fx 32+, "utm_source" etc are added - see bug 1022745

> We would like to add UTM parameters to the plugincheck URL that is in Firefox.
> Why? Because the traffic looks like "direct" traffic and it is difficult to tell if that
> is coming from the browser or another source.

in about:config see the "plugins.update.url"


BACKGROUND

Bug 956905 comment # 148 has a
Status Update on 'the plugincheck service' as at 2014-07-16.

> Status Update on 'the plugincheck service'.
> 
> Q. "Is the new plugincheck service ready for use without enumeration?"
> 
> A. "Not quite: Schalk Neethling [:espressive] has done a lot of work and has 
> produced a very impressive result but there are a few outstanding issues."
> 
> Release (Fx 30) is using enumeration for plugincheck.
> Beta, Aurora and Nightly (Fx 31+) are NOT using ANY enumeration for plugincheck.
> Fx 31 is due for Release on 2014-07-22.
There is much more detail, and many references, in that bug comment.

Since then, the version of Fx that uses enumeration has been bumped on.
So, FX 31 is still using enumeration and Fx32+ is using the JSON list.

This happened very close to the release of Fx31.
See bug 1020133 comment # 5 onwards.

DJ-Leith
I just updated to FF 32.0 (from 31.0).  I know you guys know that the Adobe Acrobat plugin is still not enumerating properly -- but the UPDATE button still just causes the plugin checker page to reload, which is why THIS bug (1023718) co-exists with similar bugs.  (Even mousing over the button, you can see the target is the plugin checker, whereas other buttons go elsewhere.)

Under the present screen, users would rightly expect the UPDATE button to connect to Adobe.com or similar to download a fix (or tell them one isn't available).  By just reloading the plugin checker, it gives the impression of a program failure.

Since the checker knows it is simply going to reload -- it must know, as it has to fetch a URL from somewhere -- can we display a better button or message instead?  See my Comment #2, Comment #3, and Comment #7 for some possible options.
I agree with all Dan's points in comment # 15.

See also:

Bug 1060905 "Bump Firefox Version for plugincheck - Fx 32 will be released on 2014-09-02"
where I tried to prevent this beeng seen in Fx 32.

Bug 1061985 - is a new Duplicate (because the changes in bug 1060905 did not land in time).

(From bug 1061985 comment # 1) DJ-Leith wrote:
> On testing again about 11:00 PDT, on Wed Sep 3 2014
> I can confirm that the UK version of Plugincheck is now
> reporting "Adobe Acrobat" version 11.0.8.4 as "Up to Date" - CORRECT.

Bug 1053417, particularly from bug 1053417 comment # 3 onwards, where I have tried
to point out 'where to start looking' in trying to fix the 'new plugincheck - uses the JSON List'.

DJ-Leith
No longer depends on: 1020133
I'm marking this bug as WONTFIX per bug #1269807.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.