512480 - consider special blocklist ping from session restore

Status: NEW

(Firefox :: Session Restore, defect)

Description

[chris hofmann]

Bug 512122  shows a case where firefox appears to have been attacked by rogue .dlls that resulted in users being unable to start their browser.

we blocklisted the problem plugin in bug 512412 and are monitoring the effectiveness of the block.   Looking at early results the block seems to be having some positive effect
  on the peak day we got about 18k crash reports before the block 
  currently we seem to be running at about 120 crashes per hour or around 2880 per day.

Thats an improvement but we might want to try and do better for future cases.

On measure might be to send a special block list ping from session restore.  Its largely overkill for most situations, but would be effective in getting users back on their feet in a situation like the NPFFAddOn.dll crash, and reduce the delay in delivering a fix for a serious crash on start up problem to zero.

That would leave us getting only crashes from users that have disabled blocklisting.

Comment 1

[chris hofmann]

we might want some level throttling on this to avoid repeated checks in the same hour or day...

if session-restore has run 2 or 3 times today 
  try pinging again tomorrow

or

if session-restore has run in the last X hours
  try pinging again later
  might want to also indicate that this install has a frequent crash problem

that last item could trigger some general recommendations to help avoid startup crashes that disable the browser and/or direction on where to report these kinds of problems on sumno

Comment 2

[Frank Griswold [:griswolf] [:fgriswold]]

Note bug #511243 and bug #470620: If we use blocklist pings to estimate usage, we will want to factor extra pings into that calculation.

Comment 3

[chris hofmann]

hence the term "special ping."   these should not be factored into usage estimates.

Comment 4

[chris hofmann]

begin start up, update the blocklist, load plugins 

would be the most reliable way.  maybe it could happen this way in session restore mode, along with throttling measures listed above.

this would probably be pretty taxing on start up when in session restore mode, and maybe on the servers so definitely some trade offs to look at.

The ramp down rate in crashes shown in Bug 512122 is moving in the right direction, but it seems like we do need a way to improve the reliability and speed that we could knock out crashes like this.