Closed Bug 433592 Opened 14 years ago Closed 14 years ago
PFS shouldn't offer Flash .xpi for Firefox 3
Spin-off of bug 416396 to cover the negative user-experience. We will modify PFS to not serve the Flash .xpi for fx3 users on those platforms so they get pointed to the manual install link instead of installing the .xpi and not having it work.
Note that I tested this on Tiger using the latest nightly and the same things happens that happens on Linux and Windows.
So we're basically not offering this .xpi for any Firefox 3 users?
This is pretty terrible.
Yeah, it sucks. But, at the same time, the install.js approach didn't work on Vista at all, so this isn't exactly a new problem. We just removed the no-longer-adequate technology.
Whiteboard: [server side]
So today I took a look at what I could do with the existing .exe for Flash. I don't recommend we point at that because it doesn't improve user experience and what we really need to do is invest some time figuring out the PFS use-cases so it's an improvement over the manual install scenario. Doesn't seem like much effort has been put into it so far. See bug 416396 comment #75 for more on that. I also attempted to serve the apple .dmg.zip, but that again is not an improvement over the manual install scenario -- if anything it's more confusing because the PFS dialog is inaccurate and leaves the user stranded. So indeed, for now (or for Fx3) it looks like our best bet is to offer the manual installs. On the other hand, I think there are some adjustments we shoudl make prior to Fx3 to prepare for better PFS logic and server-side handling. I filed a bug 433615 to fix the lack of a version number in pfs.datasource.url for 3.0 final and subsequent releases where we'll want to key off of something besides build ids.
So... ultimately we have to make a decision about what to do here short-term: * just offer the manual link for everyone, which degrades Fx2 users who are used to the .xpi "easy" install use-case * or... find which specific build IDs coming in are Fx3 vs. Fx2 and alter PFS to only offer manual link to Fx3 builds (see bug 433615 -- pfs doesn't get versions!?) Long-term we need: * changes in the client so the installerLocation/installerHash stuff isn't hopelessly broken (see bug 416396 comment #75) * fix for bug 433615 so PFS isn't getting build ids in the appVersion part of pfs.datasource.url * some sort of roadmap for plugins in general Quick fix right now would be to just offer the manual update to everyone. Thoughts?
Status: NEW → ASSIGNED
Sorry, meant to link to bug 419928. In particular, see bug 419928 attachment 314482 [details] to see why the external installer doesn't work even for Fx3, leaving us with no good way to have an easy-install like we did in Fx2 for any plugins.
Although I would not necessarily be in favor of degrading the experience for FF2 users, there are enough complaints in Hendrix with a summary such as "never-ending adobe flash player install" that I think we need to make sure that we offer the user the correct feedback when installing the Flash plugin. So I guess I would vote for the specific build ID solution noted in Comment 6.
It's critical to fix this for release. Need smooth Flash installation. Adding [RC2?]
Whiteboard: [server side] → [server side][RC2?]
(In reply to comment #6) > Quick fix right now would be to just offer the manual update to everyone. > Thoughts? Take the quick fix, please. I don't think we're comfortable taking 419928 at this time.
Whiteboard: [server side][RC2?] → [server side]
Bug 433615 landed, so it looks like we should be able to utilize the version string now, which is great news. Should have a patch Friday AM.
What about Windows XP? The summary says "Vista", but XP also suffers from bug 416396.
Matt -- that is correct, will also offer the manual install link for XP as well.
It happens for each OS. So updating the summary...
Summary: PFS shouldn't offer Flash .xpi for Firefox 3 on Vista or Linux → PFS shouldn't offer Flash .xpi for Firefox 3
Issues have been reported on all platforms, so my patch will disable XPIs for all Firefox 3 installations.
Fixed some comments.
EULA stuff added an additional step and isn't required for a manual link.
Comment on attachment 323803 [details] [diff] [review] v4, correct patch this time... Tested and looks good. You might want to check if $appRelease is non-empty before doing the regex check for performance, but regardless r=fligtar.
Attachment #323803 - Flags: review?(fligtar) → review+
r14797, added check for var $appRelease.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
How do we test this? Do we need to change the value of |pfs.datasource.url| via about:config to point to some staging server?
You can change pfs.datasource.url to point to preview: https://preview.addons.mozilla.org/services/pfs.php Switch that in for: https://pfs.mozilla.org/plugins/PluginFinderService.php
Went through this with Tony, and verified it as FIXED with: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 In all cases--and via both the notification bar and the in-page "Flash-needed" link--we were pointed to the "Manual Install" button which took us to the appropriate page.
Status: RESOLVED → VERIFIED
Push is scheduled for tonight. Thanks Stephen.
Stephen, could you re-verify this? Had some reports that said otherwise in the press: http://news.cnet.com/8301-13554_3-9975202-33.html This could be related to the temporary AMO rollbacks, but would like to make sure this falls back to manual installation as expected.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
(In reply to comment #25) > Stephen, could you re-verify this? Had some reports that said otherwise in the > press: > http://news.cnet.com/8301-13554_3-9975202-33.html > > This could be related to the temporary AMO rollbacks, but would like to make > sure this falls back to manual installation as expected. The way I read that article -- "it always fell back to manual install, which worked", this wasn't broken; this is also the same experience as when I verified it with Tony in comment 23. Anyways, I've tried again and got identical behavior -- let me know if I should be doing something different (I thought that was the approach in comment 6).
Yep, verified that it doesn't hang. Thanks.
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.