Integrate plugin check logic with FHR



6 years ago
3 months ago


(Reporter: mconnor, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [measurement:client])



6 years ago
We have the data, we know the bad versions, we should find a way to incorporate this logic into the web-facing report.  Thanks to Ibai/Lawrence for pointing this out!
Let me know if I can help with anything here.
While I like the idea, don't we already have logic in the browser itself to look/prompt for out of date plugins? What's the value add by having this in about:healthreport? Will users visit about:healthreport enough to warrant the effort involved here? I guess what I'm really asking is for prioritization.
The browser must have a mechanism to detect out of date plugins (at least some) because the alert that comes down from the chrome it's one of the main drivers of traffic to the plugin-check site. That said, I think that it doesn't capture all the plugins that Plugincheck has implemented. 

Also, eventually from SUMO we will like to drive traffic to about:healthreport so users can understand why their browser is slow and help us help them. It would be nice to have some type of information about their outdated plugins that may be causing performance issues. The Help menu already has access to it so it will drive some decent traffic.

Lot's of potential. Priority: As it is today, we may survive with a link to the plugincheck page but down the road it would be nice to have this functionality embed into the FHR to show those plugins that need to be updated.
Related bug 861888.

In terms of value, I think this is pretty high on the user value list. If we're going to have a health report, it should report on the health of the system. Plug-ins seem like a natural fit and good place to start as 1) plug-ins are a frequent source of security and stability issues and 2) Mozilla doesn't control the update mechanism for plug-ins. As well, we also already have this data, which in many cases is half the battle.

Comment 5

6 years ago
To pile on in terms of comment 2, just because the browser has logic elsewhere doesn't mean it's out of scope for FHR.  IMO FHR should include all relevant info for the health of a Firefox instance.
+1 to comment 5. From the user perspective, IMHO FHR should become the one stop place for everything "my Firefox is not working as it should".

That includes, but is not limited to:
- Performance overview (the initial goal of FHR)
- Plugin status
- Quick fixes like Firefox Reset access
- Context for crashes?

We have the opportunity to make the majority of SUMO's troubleshooting information unnecessary and leave SUMO as an educational platform.
Blocks: 1031506
Priority: -- → P5
Whiteboard: [measurement:client]
See; component deprecated.
Last Resolved: 3 months ago
Resolution: --- → INCOMPLETE


3 months ago
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.