589670 - Need to help OS X users upgrade Flash for Firefox 4?

Status: RESOLVED INCOMPLETE

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Justin Dolske [:Dolske]]

Bug 571537 dealt with an issue where keyboard input for Flash was not working. AIUI, the bug was that we switched to Cocoa events for plugins, but Flash didn't properly support that, and the fix is to upgrade to Flash 10.1.82.76.

Unfortunately, this leaves existing users in the lurch. Until OS X ships with the fixed version (or newer) of Flash -- and most users upgrade to it -- OS X users who have no problems with Flash + Firefox 3.6 will run into this bug upon upgrading to Firefox 4.x

This seems really bad for user experience (and support!). Not sure if there's anything we can do to support older versions of Flash, so the only other option I can think of is to make Firefox strongly suggest that users update their Flash. Maybe outright blocklist the old version?

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Note that bug 571537 doesn't happen with Flash 10.0 (even in FF 4) --
which (as far as I know) is the latest version available from Apple
(via Software Update).

But Flash 10.0 has serious security vulnerabilities.  So we still need
to get people to upgrade to Adobe's latest version.

Comment 2

[Josh Aas]

The only version of Flash with the major keyboard input problem is the first release of Flash 10.1. This was never pushed to Mac OS X users by Apple so only users who manually upgraded to it would have it, and those people already upgraded their Flash version once manually.

Comment 3

[Dirkjan Ochtman (:djc)]

Still (as someone who ran into this last week), for that apparently smallish population of users, can we have something to prevent people from running into this? A release note or known issue? Open the plugin check page in a tab on major upgrades? Incorporate some information from the plugin check page in the release page?

Comment 4

[Josh Aas]

We already have systems in place for encouraging users to upgrade their plugins. I think we even show the plugin check page for major upgrades. I think we should just relnote this.

Comment 5

[Justin Dolske [:Dolske]]

(In reply to comment #1)
> Note that bug 571537 doesn't happen with Flash 10.0 (even in FF 4) --
> which (as far as I know) is the latest version available from Apple
> (via Software Update).

Ah, I assumed it was a problem with all versions of Flash. So, I think that removes most of the concern here. (I think "get users to upgrade to a secure version" is a separate issue.)

It would be good to know what percentage of OS X users are on 10.1, I wonder if the Plugin Check guys have that data.

Comment 6

[Justin Dolske [:Dolske]]

The data should exist, Ryan was kind enough to file bug 589912 for having the stats guys extract numbers from logs, and bug 589897 for using our existing "Hey, upgrade your plugin" stuff for our whatsnew pages.

Let's preemptively close this as WFM, I'll reopen if the data indicates an alarmingly high percentage of users are on Flash 10.1.

Comment 7

[Justin Dolske [:Dolske]]

Sigh, the data is in and I finally got around to looking at it. Reopening for a decision on what to do here.

I looked at the data in bug 589912 for a few different days. This is the number of visitors to www.mozilla.com for *Intel* OS X users running Firefox *3.6* (since PPC users can't run 4.x anyway, and 3.0/3.5 users are already not that interested in upgrading).

The percentage varies by day, but indicates that 14% - 19% (or ~30K users/day) of our current OS X (intel/3.6) users are running a version of Flash that have problems with Firefox 4 -- bug 571537. AIUI, Flash 10.1.x versions prior to 10.1.82 have this problem; the logs only show notable numbers for 10.1.52 and 10.1.53.

Seems like we should at least see if we can push harder to get 3.6 users to update now, and possibly add a special warning in 4.0 if we detect the installed Flash version has this problem?

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Agreed.

Comment 9

[Josh Aas]

Only Firefox 4 on Mac OS X 10.6 requires Flash 10.1 (bugs aside). Firefox 4 on Mac OS X 10.5 can run older versions of Flash. Here are the dependencies:

Flash 10.1 and higher will use Cocoa NPAPI if possible but can use Carbon NPAPI.
Flash 10.0 and lower can only use Carbon NPAPI.
Firefox 4 on Mac OS X 10.5 supports Carbon and Cocoa NPAPI.
Firefox 4 on Mac OS X 10.6 requires Cocoa NPAPI.

So bugs aside, Flash 10.1 is only a hard requirement for Firefox 4 on Mac OS X 10.6. Apple updated Mac OS X 10.6 users to Flash 10.1.102.64 last week with their Mac OS X 10.6.5 update, so as that update is propagated to Mac OS X 10.6 users the number of people with a good Flash plugin installed will rise.

Note: Users running Firefox 4 in i386 mode on Mac OS X 10.6 complicates this matrix a bit, but that should be pretty rare so I excluded the possibility from the information above.

Comment 10

[Benjamin Smedberg]

Needs an assignee!

Comment 11

[David Dahl :ddahl]

(In reply to comment #7)

> Seems like we should at least see if we can push harder to get 3.6 users to
> update now, and possibly add a special warning in 4.0 if we detect the
> installed Flash version has this problem?

Is the solution to this bug (for now) to detect the flawed flash versions and open a page that urges the user to upgrade to the latest flash?

Comment 12

[David Dahl :ddahl]

Josh:

My 10.6 Mac was updated to Flash 10.1.102.64 on Dec. 20th. Should this be the case with most of our Mac users? Dolske says we should re-run the metrics to see what it looks like today as this may be a non-issue, correct?

Comment 13

[Josh Aas]

I noted the Apple update in comment 9. I'm all for more data, I'm pretty sure it will show that the number of affected users is significantly down but I don't know what our threshold is for considering this to be a non-issue.

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

The number is irrelevant, IMO. Older versions of flash won't work on 10.6, so let's minimize the impact by forcing people to upgrade by blocking earlier versions.

The appropriate minimum version is 10.1.102.64?

Comment 15

[David Dahl :ddahl]

(In reply to comment #14)

> The appropriate minimum version is 10.1.102.64?

According to this http://www.adobe.com/support/security/bulletins/apsb10-26.html it would seems so.

Comment 16

[David Dahl :ddahl]

Filed bug 625107 for the blocklisting to take place. Do we also need a
delayed-startup patch that will open a tab to urge the installation of Flash
10.1.201.64+?

Comment 17

[David Dahl :ddahl]

(In reply to comment #16)
> Filed bug 625107 for the blocklisting to take place. Do we also need a
> delayed-startup patch that will open a tab to urge the installation of Flash
> 10.1.201.64+?

rs, beltzner:
I think there is a facility in the startup path to show a tab on upgrade, correct? That is, if we need to really drive home the "upgrade your flash" plugin message.

Comment 18

[Robert Strong (they/them - no direct email)]

Firefox has code for this in
http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserContentHandler.js

Comment 19

[David Dahl :ddahl]

(In reply to comment #16)
> Do we also need a
> delayed-startup patch that will open a tab to urge the installation of Flash
> 10.1.201.64+?

Do we need to do this?

Comment 20

[David Dahl :ddahl]

Just setting up a test to make sure Flash gets blocked properly and we inform the user correctly - I looked all over the Adobe site to find the previous verison of flash to make this test as accurate as possible and could not find it. Do we have it archived somewhere?

Comment 21

[David Dahl :ddahl]

(In reply to comment #20)
> Just setting up a test to make sure Flash gets blocked properly and we inform
> the user correctly - I looked all over the Adobe site to find the previous
> verison of flash to make this test as accurate as possible and could not find
> it. Do we have it archived somewhere?

Instead I tested this against the current version of Flash I have. Works quite well, the blocklist snippet I used looks like:

  <pluginItem>
    <match name="filename" exp="Flash Player\.plugin"/>
    <match name="description" exp="10\.1 r102"/>
  </pluginItem>

of course, the 'description' exp will change to the problem version(s) of flash.

Comment 22

[Johnathan Nightingale [:johnath]]

So, should we morph this into a blocklist bug for morgamic's team to push out?

Comment 23

[David Dahl :ddahl]

(In reply to comment #22)
> So, should we morph this into a blocklist bug for morgamic's team to push out?

yes. I just wanted to test with the actual bad version of flash to make sure.

Here is the procedure I followed:
---------------------------------------------
Test procedure for new plugin blocklist item:

open about:plugins in your browser.

look for:
Shockwave Flash

    File: Flash Player.plugin
    Version: 10.1.82.76
    Shockwave Flash 10.1 r82

The above lines can be matched via the blocklist.xml file like so:

line 1: filename
line 2: name
line 3: description

these can be matched via a regex inside of a <pluginItem> node in blocklist.xml:
  <pluginItem>
    <match name="filename" exp="Flash Player\.plugin"/>
    <match name="description" exp="10\.1 r82"/>
  </pluginItem>

To test this, 

1. edit blocklist.xml directly - which is in the profile. 

2. remove pluginreg.dat

3. restart the browser

4. wait a few minutes as it can take a little while for Firefox to check the blocklist

5. You should see a window pop up warning the user that the plugin was disabled - in other cases, if you navigate to a page that uses the plugin, a warning notification pops up abover the content area telling you that your plugin is disabled and how to update it via the plugin checker

6. Install a new version of the plugin and make sure it functions properly

Comment 24

[Johnathan Nightingale [:johnath]]

Moving to blocklist component - morgamic, holler if you need details from David. We want to get this done before the last Firefox beta, for FF4 only - you anticipate problems there?

Comment 25

[Justin Scott [:fligtar]]

(In reply to comment #24)
> Moving to blocklist component - morgamic, holler if you need details from
> David. We want to get this done before the last Firefox beta, for FF4 only -
> you anticipate problems there?

David already filed bug 625107 for this but I'll dupe it over to this one. I'll take this as I'm trying to get the add-ons team to be more responsible for blocklist.

Comment 27

[mattburles]

how is this going to be fixed by rc1?

Comment 28

[Justin Scott [:fligtar]]

Questions:
1. This block is only for Mac OS X, correct?

2. Is this a hard or soft block? (is it forced upon the user or can they opt-out if they really want to use it?) Hard blocks usually cause rage and frustration, so we prefer soft blocks. Note: we could soft block in Firefox 3.6 and hard block in Firefox 4

3. We are blocking all versions below 10.1.102.64, which would be a description regex of 10\.1 r([0-9]{1,2}|10[0-1])$ correct?

Once these questions are answered I can put this on our blocklist staging server and give instructions for people to help test.

Comment 29

[Justin Scott [:fligtar]]

Kev, can you make sure Adobe knows about this?

Comment 30

[Justin Scott [:fligtar]]

(In reply to comment #28)
> 3. We are blocking all versions below 10.1.102.64, which would be a description
> regex of 10\.1 r([0-9]{1,2}|10[0-1])$ correct?

Hmm, this actually only covers 10.1 subversions. Let's try this:

^\D+(\d(\.\d+)?( r(\d+))?|10(\.0)?( r(\d+))?|10(\.1)?( r(\d{1,2}|10[0-1]))?)$
     ^------------------^ ^----------------^ ^----------------------------^
       versions lower        verions 10 and    version 10.1 below r102
       than 10               10.0

You can play around with the regex with version numbers that should pass/fail here: http://bit.ly/epJOTw

Comment 31

[Kev Needham [:kev]]

(In reply to comment #29)
> Kev, can you make sure Adobe knows about this?

Yes. I suspect they're going to want to understand what the UX is like, as well.

I know this is OSX-specific, but we need to address other platforms as well. Versions of flash before 10.1 don't support private browsing and there are issues with OOPP handling as well, IIRC. If we're going to be using the blocklist to mitigate this, we should tie everything together and address it at once (see also bug 595168, bug 604442, and bug 608697)

Comment 32

[Justin Scott [:fligtar]]

(In reply to comment #31)
> I know this is OSX-specific, but we need to address other platforms as well.
> Versions of flash before 10.1 don't support private browsing and there are
> issues with OOPP handling as well, IIRC. If we're going to be using the
> blocklist to mitigate this, we should tie everything together and address it at
> once (see also bug 595168, bug 604442, and bug 608697)

It's not clear to me why we would blocklist something that doesn't support private browsing mode. To blocklist something, we need to be certain that the impact of the issue is so great that it outweighs the user's choice to install the software and the vendor's freedom to distribute and control their software. Very few things meet that bar, and if the issue only affects a small percentage of the users who would be inconvenienced, the burden of proof is even greater.

I don't see private browsing mode coming close to that bar. And I think there's a decent number of users who will think Firefox is broken if their videos won't play, and they're also a factor when blocking something as popular as Flash.

I'd rather that discussion not block (get it?) forward progress on this bug. If no one has opinions on my questions in comment #28 I'll propose some answers tomorrow and stage them for testing.

Comment 33

[Justin Scott [:fligtar]]

I've added the following to blocklist staging. I haven't tested it yet, will do that tomorrow. I'd appreciate anyone's help testing using the following instructions: https://wiki.mozilla.org/Blocklisting/Testing

It softblocks in 3.6 and lower and hardblocks in 3.7 and above for Mac only.

<pluginItem os="Darwin">
    <match name="description" exp="^\D+(\d(\.\d+)?( r(\d+))?|10(\.0)?( r(\d+))?|10(\.1)?( r(\d{1,2}|10[0-1]))?)$"/>
    <match name="filename" exp="Flash Player\.plugin"/>
    <versionRange severity="1">
      <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
        <versionRange minVersion="0.1" maxVersion="3.6.*"/>
      </targetApplication>
    </versionRange>
  </pluginItem>
  <pluginItem os="Darwin">
    <match name="description" exp="^\D+(\d(\.\d+)?( r(\d+))?|10(\.0)?( r(\d+))?|10(\.1)?( r(\d{1,2}|10[0-1]))?)$"/>
    <match name="filename" exp="Flash Player\.plugin"/>
    <versionRange>
      <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
        <versionRange minVersion="3.7a1pre" maxVersion="*"/>
      </targetApplication>
    </versionRange>
  </pluginItem>

Comment 34

[Justin Scott [:fligtar]]

I have good news and bad news!

I tested the block and it seems to work properly, and I also asked the QA team for help testing. The modal dialog that comes up when the block takes place isn't great in that you can't upgrade Flash from there, but we'll link to it from the blocklist info page.

The good news is that once Flash is blocked, when you visit a page like youtube, we show an infobar that says Flash was blocked and you can learn more or update your plugins at our plugincheck page. http://people.mozilla.com/~fligtar/blocklist/flash/fx4-youtube.png

The bad news is that the plugincheck page doesn't say Flash is out of date because it thinks you don't have Flash installed. http://people.mozilla.com/~fligtar/blocklist/flash/fx4-plugincheck.png

I think we need to fix that before we can block it.

Comment 35

[David Dahl :ddahl]

(In reply to comment #34)

> The bad news is that the plugincheck page doesn't say Flash is out of date
> because it thinks you don't have Flash installed.
> http://people.mozilla.com/~fligtar/blocklist/flash/fx4-plugincheck.png
> 
> I think we need to fix that before we can block it.

its a chicken and egg problem. Who should update that page? I was going to file a bug on that as well, but got caught up in other things. I imagine you should roll them both out simultaneously.

Comment 37

[Nick Lowe]

10.2.152.26 is out now.

The update for Flash fixes 13 vulnerabilities, all of which are described as allowing remote code execution. Version 10.1.102.64 and earlier are vulnerable and Adobe recommends users update to 10.2.152.26.

http://www.adobe.com/support/security/bulletins/apsb11-02.html

Comment 38

[Bruno 'Aqualon' Escherl]

(In reply to comment #34)
> I have good news and bad news!
> 
> I tested the block and it seems to work properly, and I also asked the QA team
> for help testing. The modal dialog that comes up when the block takes place
> isn't great in that you can't upgrade Flash from there, but we'll link to it
> from the blocklist info page.
How is this related to bug 514327?

Comment 39

[Justin Dolske [:Dolske]]

(In reply to comment #34)

> The bad news is that the plugincheck page doesn't say Flash is out of date
> because it thinks you don't have Flash installed.
> http://people.mozilla.com/~fligtar/blocklist/flash/fx4-plugincheck.png

You effectively don't, from the webpage's point of view. AFAIK the Plugin Check page is basically just looking at navigator.plugins, and that only lists enabled plugins. Dunno if that can be changed without webcompat issues, and Plugin Check is probably the only type of page that would actually be interested in that info.

Hmm, seems like a tough problem.

We could look for a way to expose disabled plugin info, perhaps through a mozilla-specific API (say, navigator.mozDisabledPlugins) or by having the existing API treat the Plugin Check URL as a special case (ie, whitelist). Probably doable, though it's pretty late for a change like that.

Another possibility would be to have to have the infobar buttons pass along that info to the pages they link to... I think it just dumps you out to a generic SUMO page or the Plugin Check page right now?

Comment 40

[Justin Scott [:fligtar]]

This block is on hold for various reasons: bug 523784, bug 633285, bug 633311

Comment 41

[Johnathan Nightingale [:johnath]]

This doesn't need beta exposure, even if it does continue to be a hardblocker - also looks like it might have been betaN+'d by bsmedberg by accident? Back to final+

Comment 42

[Johnathan Nightingale [:johnath]]

Now that we've fixed the "too easy to cancel soft-block" issue, can this move ahead?

Comment 43

[Johnathan Nightingale [:johnath]]

Oh, crap, sorry for the spam - we're still dealing with the plugin-check problem, aren't we?

Comment 44

[Justin Scott [:fligtar]]

Yes. And Kev and I are meeting Tuesday to work on the messaging and send to SC.

There are also still people who don't think we should do this because of the experience (there's no way to update Flash from the block UI and updating Flash is crappy times) so I think there's some more selling to be done.

Comment 45

[Mike Beltzner [:beltzner, not reading bugmail]]

Did you meet Tuesday? Wha' happened?

Comment 46

[David Vo [:auscompgeek]]

Shouldn't Apple know about this as well?

Comment 47

[Mike Beltzner [:beltzner, not reading bugmail]]

Josh has said that most 64-bit OSX users are now on 10.1 or better due to Apple OSX updates. We should still move forward with this aggressively, I think, but not going to hold release on it.

Comment 48

[Kev Needham [:kev]]

(In reply to comment #45)
> Did you meet Tuesday? Wha' happened?

Couple items left:

- We're waiting on final design mocks for the plugin check page.
- Still need to finalize discussion with Adobe. They're aware but I want to see if we can link to the installer directly from the update page (a la PFS).
- Need to push new designs to stage, stage BL, and test UX 

Hopefully we can get things pushed to stage early/mid next week to test, and we should start messaging next week. I'll make sure PR, Product, and Support is looped in as well.

Comment 49

[Justin Scott [:fligtar]]

The following XML is on staging. It softblocks Flash versions below 10.1 r102 in Firefox 4.0b1 and above. For explanation of the regex, please see comment #30.

  <pluginItem os="Darwin">
    <match name="description" exp="^\D+(\d(\.\d+)?( r(\d+))?|10(\.0)?( r(\d+))?|10(\.1)?( r(\d{1,2}|10[0-1]))?)$"/>
    <match name="filename" exp="Flash Player\.plugin"/>
    <versionRange severity="1">
      <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
        <versionRange minVersion="4.0b1" maxVersion="*"/>
      </targetApplication>
    </versionRange>
  </pluginItem>
  <pluginItem os="WINNT">
    <match name="description" exp="^\D+(\d(\.\d+)?( r(\d+))?|10(\.0)?( r(\d+))?|10(\.1)?( r(\d{1,2}|10[0-1]))?)$"/>
    <match name="filename" exp="NPSWF32.dll"/>
    <versionRange severity="1">
      <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
        <versionRange minVersion="4.0b1" maxVersion="*"/>
      </targetApplication>
    </versionRange>
  </pluginItem>

This will need extensive testing if we're going to go ahead with it. Kev should be back next week and can update us on the messaging and Adobe outreach fronts.

The plugincheck fix to help users with blocked Flash is live now.

Comment 50

[Dirkjan Ochtman (:djc)]

I think this bug can be closed now?

Comment 51

[Benjamin Smedberg]

I think that the CTP work has made this obsolete.