Closed Bug 416396 Opened 17 years ago Closed 15 years ago

Firefox doesn't install Flash plugin when it is needed and absent

Categories

(addons.mozilla.org Graveyard :: Plugins, defect, P2)

Product:
addons.mozilla.org Graveyard
Component:
Plugins
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: valent.turkovic, Assigned: morgamic)

References

(
URL
)

Details

(Keywords: relnote, Whiteboard: [needs new flash XPI from adobe])

Attachments

(6 files)

flash bug
70.16 KB, image/png
Details
local install fails
124.80 KB, image/png
Details
Screenshot of RDF error
223.02 KB, image/png
Details
Screenshot; automatic install fails
211.50 KB, image/png
Details
v1, patch to change installer info for 3.5 clients
1.66 KB, patch
Details | Diff | Splinter Review
v2, fixes tests and edge cases
2.56 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020623 Fedora/3.0b4pre-0.beta2.16.nightly20080206.fc9 Minefield/3.0b4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020623 Fedora/3.0b4pre-0.beta2.16.nightly20080206.fc9 Minefield/3.0b4pre

I have tried different Firefox versions on multiple hardware and on multiple Fedora versions and I still see this bug.

You can look for yourself:
http://www.youtube.com/watch?v=-_ayaoEUHZ4

Steps to Reproduce:
1. Go to a web page with any flash content
2. Try to install Flash plugin by clicking on top of the browser content window.
3. Fails to install

I have tried multiple 2.x versions and also 3.xb versions and I see this issue with all of them.

Reproducible: Always

Steps to Reproduce:
1. Go to a web page with any flash content
2. Try to install Flash plugin by clicking on top of the browser content window.
3. Fails to install


Expected Results:  
To have flash plugin installed and profit :)

https://bugzilla.redhat.com/show_bug.cgi?id=236881
http://www.getautomatix.com/forum/lofiversion/index.php/t387.html
Attached image flash bug — 
flash bug screenshot
This isn't a pfs issue, this is a problem with the hosted xpi
Component: Plugin Finder Service → Plugins
Product: Firefox → addons.mozilla.org
QA Contact: plugin.finder → plugin-listings
For the record, I couldn't reproduce this on Ubuntu with FF2.
Wil you got it to install under Ubuntu?
Doron what is the problem with the hosted xpi?

I came to same conclusion. This is how I got to it. I started wireshark to capture packets and look for myself what is going on while installing flash plugin.

I found out the url of the flash plugin and it is:
http://fpdownload.macromedia.com/get/flashplayer/xpi/current/flashplayer-linux.xpi

I entered that in in firefox 3 and I still got the error message!

So I downloaded the file and tried to install it localy - and it still fails :(

Is there some way to notify Adobe so that they fix this issue?
Yep, worked great.  To reproduce (my success...):

1) Go to page with flash content
2) Click either flash content placeholder or yellow bar at the top of the page
3) Be told I need the Adobe flash player
4) Click next.  Firefox downloads it and installs.  Doesn't even have to restart firefox.

(again, this was FF2 and comment 0 is about FF3)

Also, for the record, there is no hosted xpi for flash on AMO.
Emmy, do you know someone who can help us out with this?
I have tested this with Mint Linux (Ubuntu) and I first removed flash-nonfree packages with option "completely remove" in synaptics and the started firefox 2.0.0.10 and I see the failed plugin message again.

So I can reproduce this error on Ubuntu, strange?
Fore firefox 3, I believe we are removing install.js support and require install.rdf
Ok - I tried again and now it got installed.

Second time it didn't download the flash (the bar went to fast for that) but it looks like it used a cached file that it downloaded the first time when it failed.

Could that maybe be some clue? If Firefox in Fedora erasing this file every time and that is why it fails and Firefox on Ubuntu keeps this downloaded file so it fails only first time it downloads a file?

Still it doesn't explain why I can't install in Fedora from a local file on the desktop.
Attached image local install fails — 

    
    

    
  
cc: bsmedberg - we have a new way now to do this using <InstallerLocation>
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
Is this an issue with our XPI? If so, let me know what is different/needs to change and we'll look into it.

    
    

    
  
It looks like FF3 beta has some issues with your flashplayer-linux.xpi file. On FF2 it usually fails first time you try to install it but the second time (if the file wes downloaded correctly and it is cached localy) it passed the install.

Can somebody tell me how this could be troubleshooted? I'm willing to help but don't know enough about FF to know how to do it.

Cheers.

    
    

    
  
Can somebody tell me how this could be troubleshooted? I'm willing to do hard work if somebody just points me in the right direction...

Valent.

    
    

    
  
I tested with Firefox 3 Beta 4 and I still see the same issue.

    
    

    
  
Tony or Stephen do you have any tips for Valent on how to troubleshoot this?

    
    

    
  
(In reply to comment #13)
> Is this an issue with our XPI? If so, let me know what is different/needs to
> change and we'll look into it.

Seems to be; please see the following screenshots, one of which complains about the RDF file.

    
    

    
  
The screenshots in comment 19 and comment 20 were from:

[mozilla@localhost ~]$ lsb_release -a
LSB Version:    :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: Fedora
Description:    Fedora release 8 (Werewolf)
Release:        8
Codename:       Werewolf

    
    

    
  
So should somebody at Adobe fix this or is it a bug in Firefox?

    
    

    
  
(In reply to comment #22)
> So should somebody at Adobe fix this or is it a bug in Firefox?

Emmy, can you have someone take a look?  I'll do likewise, here...

    
    

    
  
shouldn't we point Firefox3 users to the manual install unless we get an updated flash.xpi with install.rdf ?

    
    

    
  
Requesting blocking? so we can get some traction from either/both side(s).
Flags: blocking-firefox3?

    
    

    
  
Just to mention this bug is present on Firefox 2.x and also on Firefox 3.x betas

    
    

    
  
Ok, so the issue is a missing install.rdf?

I agree - plugin finder service should fail gracefully. The correct URL to direct users to is www.adobe.com/go/getflashplayer.

    
  
OS: Linux → All

    
    

    
  
What is the correct procedure for suggesting new features? Here what lots of fedora developers think is crucial for Mozilla developers to address in Firefox:

The abillity to make your plugin detection technology more flexible so fedora developers could easily redirect firefox users to a page we controlled with information concerning the situation with proprietary codecs and proprietary players needed to display flash and other online content.
Then fedora would be most of the way there to telling people why we are so very dearly sorry that flash doesn't work out of the box.

If you aren't aware of the situation; Fedora Project can't include anything in Fedora linux distribution that isn't free from patent rights - it has to be open and it has to be legal in order for Fedora to distribute it. 

Jeff Spaleta suggested also this "If you can get firefox's plugin technology fixed such that it gives users a choice as to which flash implementation to choose... you should champion that.  A fedora specific fix isn't that interesting to me.  But if you can convince firefox developers to extend how their plugin technology works so our users or anyone's users can choose
between open and closed flash plugins..well then.. that's a win for
everyone."

If current method of install fails for Fedora there is the solution that would be made to work if Firefox plugin system got more flexible.
The idea is this:
When Firefox presents "Install Flash Player" then it enables adobe yum repository, presents the licence and if users agree goes out and install the flash plugin via yum command "yum install flash-plugin".

If you would like to know more please look at this thread:
https://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00363.html

    
    

    
  
I think Mozilla Corp should notify Adobe earlier on removing support of install.js.

BTW: In install.js I can get
platformStr = new String(Install.platform);
On Solaris sparc, platformStr is X11; SunOS 5.11; sun4u
With install.rdf, I have OS_TARET and TARGET_XPCOM_ABI, which are SunOS and sparc-sunc on my box.
In another word, I could not detect OS_RELEASE.

    
    

    
  
Could someone help Emmy by providing an example RDF?

    
    

    
  
Mike, can you at least make sure the fallback URL is correct?

I do not think Flash should be using install.rdf. They should be providing a native installer (.exe or .msi on Windows) and we should hook that up to PFS using InstallerLocation just like we're doing for Java.
Assignee: nobody → morgamic

    
    

    
  
Fallback URL is fine:
http://www.adobe.com/go/getflashplayer

That matches comment #29.

    
    

    
  
Can somebody clarify for me how is this bug being fixed? Or is the idea to leave it broken?

    
    

    
  
We can't leave it broken.  Emme -- you have two options when it comes to the .xpi:
1) replace the .xpi with an external installer (.msi/.exe) and provide a hash for this to verify file integrity (or serve it via SSL) -- this is preferred
2) replace install.js with install.rdf and continue serving the .xpi

    
    

    
  
Are these solutions for Firefox 3 only? For 1 and 2, will things still work for prior versions of Firefox?

The bug is marked all OS, but we can't reproduce this bug using the following configuration: Windows XP SP2, Firefox 2.0.0.12. So, it is really Linux XPI only?

thanks


    
    

    
  
Correct, this is a Firefox 3 change.

    
    

    
  
@Valent - I don't think it will be completely broken if the fall back is to
direct users to www.adobe.com/go/getflashplayer. 

We're looking at supporting the install.rdf - we'd rather continue to support
the XPI so that we can keep it to one deliverable. But at this time, I can't
commit to when we would have an install.rdf.

@Mike - I'm not sure I understand why an exe with hash is preferred to
install.rdf?

We still have to support install.js for older versions, correct? Does this mean
the PFS points to a different link for FF3?

    
    

    
  
An binary installer with a hash is preferred because it will install Flash not only as a Firefox extension, but as a normal piece of OS software that you can then manage independently. If you ship it as an extension with an install.rdf, updates will have to be managed through the Mozilla addons site, which is not a burden I think you want.

And yes, we have the ability to have separate links in PFS for an .exe installer and an .xpi installer, so newer clients (FF3) will use the .exe and older clients will use the .xpi.

I discussed this with Michael Williams a few months ago, and at the time he had an .exe installer of Flash available for local testing which worked well.

    
    

    
  
Ok, got it. I wasn't up to date on that info.

If that is the preferred way for FF3, we'll take a look.

thanks,
e

    
    

    
  
(In reply to comment #41)
> And yes, we have the ability to have separate links in PFS for an .exe
> installer and an .xpi installer, so newer clients (FF3) will use the .exe and
> older clients will use the .xpi.
> 
> I discussed this with Michael Williams a few months ago, and at the time he had
> an .exe installer of Flash available for local testing which worked well.

What about Linux and Solaris?

    
    

    
  
Can I please ask a short comment about comment #30
https://bugzilla.mozilla.org/show_bug.cgi?id=416396#c30

Michael and Emmy I would really love to hear your comments/suggestions regarding opening up plugin architecture so it fits more with opensource way of things, as some fedora developers suggested.

I know that this bug report isn't the way but please at least tell me where we can carry this discussion to?

Cheers,
Valent.

    
    

    
  
I have tested Firefox 3.0b5 and I still see this bug.
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-

    
    

    
  
I'm using Minefield (Firefox 3 beta) CVS version 2008032522 on fedora linux and I still see this bug :(

    
    

    
  
there may be a work around.. id winexp... windows emulator

    
    

    
  
somebody attack this thing with ollydebug... and scratch my other comment pls

    
    

    
  
Can confirm inability to install Flash with fresh 3.0b5, Gutsy.

File that is corrupted/missing seems to change.  I'm guessing that's just a randomization/fudge factor to make the unpacked files unique?

"install-lqc..rdf" (1st try)
"install-zrt..rdf" (2nd try)
"install-gcf..rdf" (3rd try)

Additionally noted that the page seemed to get less responsive each time I tried to install the plugin.  Site I used was http://www.myspace.com/uncgsapphires , but I'm sure any flash site will do.

    
    

    
  
Emmy, any update on the external installer?

    
    

    
  
Hi folks, I will be investigating these issues later on this month, and may have a solution implemented before May.

    
  
Target Milestone: --- → 3.4

    
    

    
  
Just installed Windows (grrr).  Can confirm same error "install-xxx..rdf" error with

Windows XP Home, SP2
Firefox 3.0b5 (installed during SP1, before SP2.  Does that matter?)

Tried to install Flash with both SP1 and SP2 with same failed-install result.

    
  
Target Milestone: 3.4 → 3.4.2

    
  
Target Milestone: 3.4.2 → 3.4

    
    

    
  
(In reply to comment #40)
But don't all versions of Fx support install.rdf? Then the executable could be served only to SeaMonkey users.

    
    

    
  
John and Emmy - any update on the availability of an external installer?

    
    

    
  
Clint and noticed today that users now get a message indicating they have "Successfully installed" flash through PFS, but in fact when they restart the plug in is not installed (I would rather see a failure message than a success message). Renominating this for blocking final since IMO this is a bad user experience.

I am using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0, which is the RC1 candidate. This is currently seen on all platforms.
Flags: blocking-firefox3- → blocking-firefox3?

    
    

    
  
Yeah, I have also reproduced the issue with 3.0 RC1 on Ubuntu 8.04 (tried both as normal user and root) and on Windows XP.  You get a "plugin successfully installed" message and then a notice to restart the browser.  However, on restart, the plugin is still not installed.  This is completely broken functionality on a fairly common use case given how much flash there is in the web.  I think this should block Firefox 3 RC1.

    
  
Whiteboard: [RC2?]
Hardware: PC → All

    
    

    
  
When is Firefox 3.0 slated to go live in production?


    
    

    
  
John, we're expecting to ship RC1 in the next week or so...

Blocking on not serving the old version to Fx3 users, since it won't work.  We might be able to fix the error handling as well, but that won't fix the core issue (serving bad versions to users).
Flags: blocking-firefox3? → blocking-firefox3+
Whiteboard: [RC2?] → [server side]

    
  
Depends on: 433592

    
    

    
  
I filed bug 433592 to cover modifications to PFS needed to avoid serving .xpi's that won't work to appropriate platforms/versions.

    
    

    
  
Do the current Flash Player Windows and Mac (non-xpi) Standalone Flash Player installers work with Firefox 3.0?
Flags: blocking-firefox3+ → blocking-firefox3-
Whiteboard: [server side] → [needs new flash XPI from adobe]

    
    

    
  
I gather from this thread that if we provide a hash for the existing Flash Player Plug-in installer(s) that this would allow our Plug-in installer(s) to be delivered via the Firefox 3.0 Plugin Finder Service over http.

What is the preferred method for creating this hash?

    
    

    
  
sha1, which gets us:
1e6f7627784a5b791e99ae9ad63133dc11c7940b

But the user experience is degraded, since they get the external .exe running, the pfs dialog stays up, then the flash installer asks the user to close all browser windows (which will be existing windows + pfs window).  After closing them, they hit try again and the installer continues.

It's one step better than going to the manual download site and following the instructions -- and that's only better if you're a user who already knows how to install it and doesn't need instructions given on the adobe download site.

    
  
Whiteboard: [needs new flash XPI from adobe] → [needs new flash XPI from adobe] [relnote] [RC2?]

    
  
Keywords: relnote
Whiteboard: [needs new flash XPI from adobe] [relnote] [RC2?] → [needs new flash XPI from adobe][RC2?]

    
    

    
  
For what it's worth, this is still happening for me in RC1 on WinXP.

    
  
Depends on: 435788

    
    

    
  
Bug 433592 is blocking, this isn't, and there's no RC2 impact here, so removing that from the whiteboard.
Whiteboard: [needs new flash XPI from adobe][RC2?] → [needs new flash XPI from adobe]

    
    

    
  
After further testing, this bug ultimately depends on bug 435788, which is a problem with how the client handles installerLocation entries in PFS.  If we want to re-enable the easy installation method we're used to with the XPI, we'll have to fix that bug.

In the meantime, Flash will have to be offered via the manual installation URL for Firefox 3 versions on all platforms since it is not possible to fix this for the initial Firefox 3 launch.

    
  
Target Milestone: 3.4 → ---

    
    

    
  
There are some people who get this bug and ALSO get a message telling them that their installation has failed, whereas there are others who have reports of success but the plugin still does not work, are these separate bugs or the same?

    
    

    
  
I use Firefox 3 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 and the flash download/install process was seemless for me. Nor did I restart firefox. Just an FYI

    
    

    
  
I confirm, I just tested it on Fx3 RC3, this bug is still existing.
I created two profiles to be sure it isn't working.

I performed these steps on Litmus : https://litmus.mozilla.org/show_test.cgi?id=4062

Firefox detects that flash isn't installed, but after downloading, installing and restarting via the plugin manager, the Flash plugin is still missing.

    
    

    
  
I just wanted to mention that I had the same issue. The only way I found to resolve was to go to Adobe's website and download the installer and install it manually. Just thought it was worth mentioning. I am running Firefox 3.0 RC 3, which I downloaded today (6/13/08)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 

    
    

    
  
sorry seems fine to me

    
    

    
  
ok could someone please explain to me which operating system this is on because I never get this problem. does youtube count as flash content and could i also have a detailed explanation on what to do. thanks
regards,
jack

    
    

    
  
Due to the fixing of bug 433592 the PFS shouldn't be offering the non-installing XPI to Firefox 3 users anymore.  Thus, this is less of a problem and people just have to install manually for Firefox 3.

    
    

    
  
@Kevin, did you install your Firefox 3 over Firefox 2? If so, that might explain your success in installing Flash.


    
    

    
  
Fresh Install
Blocks: 444109
Blocks: 440281
Blocks: 455191

    
    

    
  
More than one year later and with FF 3.5 getting close this is still unfixed. Manual install is "hard" for many computer illiterate and, depending on the package selected, almost impossible for non-admin linux users.

This issue isnt alot worst because most people upgraded from FF2 to FF3, so they still have flash, but still, we are neglecting new users and look bad compared with IE... so IMHO, this should block ff3.5
Flags: blocking-firefox3.5?

    
    

    
  
I'd like to see this fixed too, fwiw.

    
    

    
  
morgamic, now that we can run installers again, what's needed here? Do you have a contact at Adobe or should we ask Kev to hook us up?
Flags: blocking-firefox3.5? → blocking-firefox3.5+
Priority: -- → P2

    
    

    
  
The two contacts I have are here:
https://intranet.mozilla.org/PFS

Emmmy Huang and Shafath Syed -- but I don't know if they're still there.  Any help would be appreciated.

We'd need them to provide the installers and assistance testing would be a bonus.

    
    

    
  
Having the same problem. Can not proceed with automatic install. Click on Manual then after download browser is still asking to install plugin.

    
    

    
  
Hi,

I'll check in with John P @ adobe, who is also cc'd on this bug, on what we can do. He's my installer guy.

thanks,
Emmy

    
    

    
  
I am only able to reproduce this behavior using Firefox 3. Firefox 2.x successfully installs via PFS. Both of these statements appear to be true for all platforms.

There were two reasons why the Flash Player was removed from PFS for Firefox 3 clients:
1. The Firefox 3 xpi requirements did not allow us to install the Flash Player to system directories (system32 on Windows), so we did not implement Firefox 3 compliant xpi installers.
2. The installerLocation and installerHash PFS procedures did not provide a good user experience. However, according to the following bug record it appears that those issues may have been fixed in the next version of Firefox (3.0.11):
https://bugzilla.mozilla.org/show_bug.cgi?id=435788

If Firefox 3 xpi's still won't allow us to install the Flash Player to system directories then maybe we should use installerLocation/installerHash to install the Flash Player via PFS.

Should I open a new bug record to investigate the installerLocation/installerHash option for Firefox 3.0.11?

    
    

    
  
Why not use this bug? .XPI installation will not work in FF3 and newer, and all plugins should be using native installers from now on.

    
    

    
  
Just asking. If you're fine with using this record to investigate the installerLocation/installerHash option for Flash Player, then so am I.

    
    

    
  
Sigh, this seems to have missed 3.5.1; we should really really try to resolve it soon, though.
Flags: wanted1.9.1.x+
Flags: blocking1.9.1.1?
Flags: blocking-firefox3.5-
Flags: blocking-firefox3.5+

    
    

    
  
We would like to use the installerHash PFS option but will need to set up an internal testing environment before committing to this installation process.

Can someone at Mozilla provide our team with instructions/tools to test the installerHash installation process internally?

    
    

    
  
John, there are instructions on testing PFS at https://wiki.mozilla.org/PFS... please let me know if you need more details.

    
    

    
  
poke/prod; it would be really nice to get this ASAP. John: any other specific help we can give you?
Flags: blocking1.9.1.1? → blocking1.9.1.1-

    
    

    
  
In house testing on Windows looks good. We're planning on using the PFS InstallerLocation/InstallerHash option for the Windows Player in the next security release. We'll investigate the same for the Mac and Linux in future releases. We will coordinate with the appropriate Mozilla engineer for the required PFS configuration changes when we're ready.

    
    

    
  


  
This is a dirty way to do it, but anything in this script is that way until we rewrite PFS.  Checked in so we can test on preview - r48456.

    
    

    
  
Either i'm verifying this wrong, or its confusingly broken.  After accepting the adobe installer EULA, it quickly goes to a PFS dialog page saying plugin isnt installed.  Then it doesnt install.

See http://www.grabup.com/uploads/771874ee512ae4e90d1543ee7ec6d74b.png

STR:
1) Point To Preview, by replacinng pfs.datasource.url with: https://pfs.mozilla.org/plugins/PluginFinderService.php?mimetype=%PLUGIN_MIMETYPE%&appID=%APP_ID%&appVersion=%APP_VERSION%&clientOS=%CLIENT_OS%&chromeLocale=%CHROME_LOCALE%&appRelease=%APP_RELEASE%
2) Restart browser for kicks, and open a site with no flash installed (eg. http://www.dailymotion.com)
3) Click a flash video, and look for the prompt that plugins are missing
4) Install missing plugins, Verify the adobe flash installer dialog appears.  Accept the EULA.
5) Something flashes on the dialog that looks like its installing, but then it goes to a dialog saying "no Plugins were installed"

This could seriously confuse the user, as they just accepted the EULA, and then find out their install didnt work and being pointed to manual installer.

    
    

    
  
(In reply to comment #124)
> Either i'm verifying this wrong, or its confusingly broken.  After accepting
> the adobe installer EULA, it quickly goes to a PFS dialog page saying plugin
> isnt installed.  Then it doesnt install.
> 
> See http://www.grabup.com/uploads/771874ee512ae4e90d1543ee7ec6d74b.png
> 
> STR:
> 1) Point To Preview, by replacinng pfs.datasource.url with:
> https://pfs.mozilla.org/plugins/PluginFinderService.php?mimetype=%PLUGIN_MIMETYPE%&appID=%APP_ID%&appVersion=%APP_VERSION%&clientOS=%CLIENT_OS%&chromeLocale=%CHROME_LOCALE%&appRelease=%APP_RELEASE%
> 2) Restart browser for kicks, and open a site with no flash installed (eg.
> http://www.dailymotion.com)
> 3) Click a flash video, and look for the prompt that plugins are missing
> 4) Install missing plugins, Verify the adobe flash installer dialog appears. 
> Accept the EULA.
> 5) Something flashes on the dialog that looks like its installing, but then it
> goes to a dialog saying "no Plugins were installed"
> 
> This could seriously confuse the user, as they just accepted the EULA, and then
> find out their install didnt work and being pointed to manual installer.

I agree. I became confused when this happened and the way it is explained to me makes me believe it was installed.

    
    

    
  
It's on preview.addons.mozilla.org right now, not pfs.  So to test you'd have to set your datasource to https://preview.addons.mozilla.org/services/pfs.php(plus the rest) -- https://wiki.mozilla.org/PFS

    
    

    
  
(In reply to comment #124)
> Either i'm verifying this wrong, or its confusingly broken.  After accepting
> the adobe installer EULA, it quickly goes to a PFS dialog page saying plugin
> isnt installed.  Then it doesnt install.
> 
> See http://www.grabup.com/uploads/771874ee512ae4e90d1543ee7ec6d74b.png
> 
> STR:
> 1) Point To Preview, by replacinng pfs.datasource.url with:
> https://pfs.mozilla.org/plugins/PluginFinderService.php?mimetype=%PLUGIN_MIMETYPE%&appID=%APP_ID%&appVersion=%APP_VERSION%&clientOS=%CLIENT_OS%&chromeLocale=%CHROME_LOCALE%&appRelease=%APP_RELEASE%

Pardon me, i copied the wrong link originally in the comment.   Yes, I was pointing my datasource to: https://preview.addons.mozilla.org/services/pfs.php?mimetype=%PLUGIN_MIMETYPE%&appID=%APP_ID%&appVersion=%APP_VERSION%&clientOS=%CLIENT_OS%&chromeLocale=%CHROME_LOCALE%&appRelease=%APP_RELEASE%

The results are the same otherwise, moves from adobe EULA page to "No plugins are installed" dialog window.

    
    

    
  
It might be worth noting that my steps above were ran against a Windows XPsp3 VM. 
I just ran this on a native Windows Vista machine, and it worked.   Changing the source to preview installed adobe flash 10.0.32.18.   However, i did notice that there was no Adobe EULA in the dialog windows, as it proceeded to directly download and install it.   

So something is fishy with the xpi installer.

    
    

    
  
Checked in r48625 to fix issues with XP.

    
    

    
  
I ran XP against preview, and flash seems to install nicely on Fx3.5.2.  However, i still dont see the adobe EULA shown at anytime during the installation.  Can someone comment if this is an issue?

Here's a screencast of the test.  http://www.screencast.com/t/aGQVEP9z

    
    

    
  
(In reply to comment #130)
> Here's a screencast of the test.  http://www.screencast.com/t/aGQVEP9z

Stephend point out the previous screencast was too zoomed in.  Try this one instead: http://screencast.com/t/d2iy7sQKhA6

    
    

    
  
We have ran the following test scenarios.  John from adobe, tells me the Fx2.0.0.20 should trigger the xpi installer, and the end User should see a update via pfs.  


Based on our tests, the installer for Fx2.0.0.20 on Vista and Win7 do NOT trigger the xpi installer.  Instead, it points the user to the Manual installer button to the flash website.

Tests:
        2.0.0.20  |  3.0.13  | 3.5.3
---------------------------------------
Xp    |  pass     |   pass   |  pass
Vista |  FAIL     |   pass   |  pass
Win7  |  FAIL     |   pass   |  pass
Linux |  pass     |   pass   |  pass
Mac   |  pass     |   pass   |  pass

Please advise on 2.0.0.20 behavior for XP and Vista.  Thanks.

    
    

    
  
The Vista and Win7 Firefox 2.x installation failure is expected. Please refer to the following bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=352762

    
    

    
  
This is fixed in PFS - r48649.  Push will be on Thursday @ 7pm along with AMO 5.0.8.
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: push-needed
Resolution: --- → FIXED

    
    

    
  
given comment 133, the tests have all passed on preview.  Will reverify this fix on prod after thurs 7pm.

    
    

    
  
(see also r48456, r48486, r48625 and r48649)

    
  
Target Milestone: --- → 5.0.8

    
  

        Attachment #392315 -
        Attachment is patch: true

        Attachment #392315 -
        Attachment mime type: application/octet-stream → text/plain

    
    

    
  
Retested against live pfs.

        2.0.0.20  |  3.0.13  | 3.5.3
---------------------------------------
Xp    |  pass     |   pass   |  pass
7     |  pass     |   pass   |  pass

Flash installer loads as expected, depending on which build and platform you are using.  Verified fix.
Status: RESOLVED → VERIFIED

    
    

    
  
Added Cheng to the bug.  We need to update the sumo docs to notify folks pfs is working under certain cases.  (eg. 2.0.0.x will still get manual installer on Vista and 7)

    
    

    
  
Sorry to raise again this problem: the PFS is currently working for Windows, but it doesn't seem to work in Linux and Mac environment (see this thread

https://support.mozilla.com/en-US/forum/3/518327?

in the SUMO contributors forum, page 5).
It seems that the PFS is triggered but the installation fails (missing packed plugin in XPI format, maybe?).

Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.2) Gecko/20100105 Firefox/3.6


Since we would like to complete the help page for Firefox 3.6, we now wish to know if this FPS is supposed to work even on Linux and Mac platforms.

If it is so, I think this bug should be reopened.
Thanks in advance.

    
    

    
  
PFS is supposed to work on Linux, Mac.
But Adobe Flash xpi is not supposed to work on any platform with Firefox >= 3.0.
So PFS should not offer xpi for Flash on those platforms.
Bug 527883 was filed.

    
    

    
  
Will this ever be fixed? It it wasn't sad it would be funny how long this is going on. This is still an issue on Linux and doesn't work! :(
Product: addons.mozilla.org → addons.mozilla.org Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: