Closed
Bug 1121456
Opened 11 years ago
Closed 11 years ago
PluginCheck for Firefox
Categories
(Plugin Check Graveyard :: UI, defect)
Plugin Check Graveyard
UI
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: espressive, Assigned: espressive, NeedInfo)
References
Details
I have been exploring the idea of changing the Plugin Check service to be for Firefox only.
I have sent out a few mails before and had some conversations on IRC in this regard and have had a general positive response to the idea.
I am definitely not a person that will advocate writing a service for a single browser vendor but, this is one of those cases where it just makes sense and the alternative, adds so much clutter and complexity it just is not worth continuing this way.
How can I say that? Well, I have been looking at the analytics for mozilla.org on production and specifically at the stats for the /plugincheck page.
I have used a combination of watching real time use stats and then looking at data over a longer period of time and here is an example of the data from the last two periods:
Dec 7, 2014 - Jan 6, 2015
Firefox accounts for 99.73% of all sessions
The next entry is Chrome accounting for 0.09% of all sessions
Internet Explorer is at 0.05% of all sessions
Nov 6, 2014 - Dec 6, 2014
Firefox accounts for 99.45% of all sessions
The next entry is Chrome accounting for 0.23% of all sessions
Internet Explorer is at 0.11% of all sessions
As you can see from this data, plugin check is clearly used, by a huge margin, by Firefox users and very, very few user from other browsers ever use the site. Chrome and Internet Explorer, as we know, manages updates of Flash (and the Java plugin?) plugin automatically, and testing Flash is one of the main reasons people visit plugincheck.
In terms of the effect on the maintainability of the various code bits (plugins.m.o, perfidies, bedrock), this is going to change a lot. In the client code for example, there is no need anymore to lug around 80% of the additional libs that is currently bundled.
There is no need to do browser detection and decide whether to use enumeration or not, and whether to do some IE specific things. We just don't use enumeration.
On the database side, we only need to track releases for Firefox. whilst we still need to obviously care about whether it is for Windows, Mac or Linux, we no longer have the browser splits and concerns over plugin versions being reported different in different browsers (which currently happens).
Bedrock will get a much lighter, much faster plugincheck page, with users receiving accurate relevant results they can rely on. There are many pros and few, if any, cons.
What will we do for someone with another browser visiting the plugincheck page?
Beyond informing them that plugincheck is meant only for Firefox users, we should definitely provide them with simple instructions on how to check whether there plugins are up to date in their chosen browser (probably limited to Chrome and IE, perhaps also Safari?)
We could also, provide links to the download pages of the 'Big 5' plugins that users are most likely concerned about i.e. Flash, Reader, Java, Silverlight, Quicktime
Looking at all of the above, considering all the bugs and problems we have been seeing on plugincheck in recent months, it is time we make the change and change plugin check to be a Firefox only service.
NB: Even though this is the intent right now, this does not mean that we will never again support other browsers but, that we want to ensure we are offering the best possible service to users and only then, can we again explore the possibility of supporting browsers from other vendors.
Schalk, I understand and agree with your idea of keeping things simple in order to better serve FF users. But, since all Windows machines are forced to have IE even if FF is the default browser, it was nice to have it working in IE too. You never know when a user will manually launch IE, so we need to keep it's plugins up-to-date too.
The stats above are from just the last 2-1/2 months, and plugincheck initially (for me anyway) stopped working for IE almost two years ago (April 2013), then was fixed for a while, until December 2013. It has not worked in IE 11 for almost 14 months.
I think the reason you don't see much use of plugincheck from other browsers is because it's been broken for the other browsers. I stopped going there with IE because I know it's not working. Do you have stats prior to April 2013? I suspect that prior to April 2013 you might see more IE users making use of it.
Again, I can appreciate the concept of only supporting FF, but it would be nice if it covered IE too, if possible. :)
Thanks,
Carl
| Assignee | ||
Comment 4•11 years ago
|
||
Hey Carl,
Thank you for your comment. I completely agree and the long term plan is to definitely support [all]browsers again where it makes sense. For now however, it makes most sense to me to get a service up that is reliable for it's end users and only then, explore how we can offer the same quality service to other browser users.
So this is not a, we will never support other browsers again scenario but a, how can we offer the best possible service to everyone. If that means stepping back and focusing on Firefox for now, than that makes sense to me in the long run.
| Assignee | ||
Updated•11 years ago
|
Updated•11 years ago
|
Flags: needinfo?(tabique_michael0203)
| Assignee | ||
Comment 5•11 years ago
|
||
This has landed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 6•10 years ago
|
||
Just for the record, I've helped on Plugin Check for the past maybe two years -- and this is the first I've heard that it was used for other browsers. May be the low usage rate is simply because people don't know about it. I'm a web developer in part of my work, so I do deliberately & regularly run other browsers. Nice to know the plugin check is common to all.
(BTW, Schalk, this explains why in the Adobe issue I was seeing MSIE folders also containing recent updates in the same manner as FF.)
Dan,
Plugin Check used to work for other browsers, but it currently does not.
Carl
You need to log in
before you can comment on or make changes to this bug.
Description
•