Closed Bug 830410 Opened 11 years ago Closed 11 years ago

Plugin block request: PDF Browser Plugin 2.4.2 and below


(Toolkit :: Blocklist Policy Requests, defect)

Not set





(Reporter: scoobidiver, Assigned: jorgev)



(Whiteboard: [plugin])


(1 file)

Plugin name: PDF Browser Plugin
Plugin versions to block: 2.4.2
Applications, versions, and platforms affected: Firefox 18 and above, Mac OS X 10.6 and above
Block severity: (hard/soft)

How does this plugin appear in about:plugins?

Homepage and other references and contact info:

Reasons: Top crasher in 18.0 (bug 693892)
Are the crashes only in the plugin process? If so I'm not sure that the blocklist would actually be better than just letting the plugin crash.
The crashes are in plugin code but per the signature summary 17.391% are running it in-process and hence get browser-crashes.
Not sure yet whether we want a CTP block or a hardblock, see bug 693892 comment 19
Reading the crash comment tea leaves, the affected version crashes every time it is used, so this should be a hardblock.

gfritzsche, can you paste the about:plugins data so Jorge can construct the block?
Flags: needinfo?(georg.fritzsche)
File: PDF Browser Plugin.plugin
Version: 2.4.2
Description: View PDF documents within your web browser.
Flags: needinfo?(georg.fritzsche)
Assignee: nobody → jorge
The block is staged now:
Keywords: qawanted
QA Contact:
Summary: Plugin block request: PDF Browser Plugin 2.4.2 → Plugin block request: PDF Browser Plugin 2.4.2 and below
QA Contact: → jbecerra
I tested this on staging, but I am not sure this is behaving like a hard block. Once I get the blocklist updated and try to load a PDF page I get a plugin crash message, and there is a corresponding crash in about:crashes

I tested this on Mac OS X with Firefox 18 and

Could someone double check this?
Reading comment #2 I get the impression this block makes things a lot better since the browser keeps running and only the plugin crashes, but I still want confirmation that this is the intended behavior for this block.
Oh, so 2.4.2 is available if you just guess the file name, nice.

While i'm not sure on how exactly a hard-block is supposed to look like, the intent here is to avoid the plugin crashes (which will take down the browser if the plugin is not run out-of-process).
(In reply to juan becerra [:juanb] from comment #7)
> Created attachment 702410 [details]
> about:addons and plugin crash page

You should have seen a dialog telling you that the plugin was blocked for your security, and the default action for that dialog should be to disable the plugin. Did you see the dialog? Did you change anything in it or enable the plugin after the fact?
I did not see the dialog at any point.
I've retested this due to the fact that earlier I had installed the latest version, then I installed the blocked version on top of it (without removing first). Now what I see is that when I start up the browser the PDF Browser Plugin is listed as disabled in about:addons and when I try to open a PDF document I get prompted to save the file.

I'm confident this is OK now, but, out of curiosity, why didn't my earlier testing work?
(In reply to juan becerra [:juanb] from comment #12)
> I'm confident this is OK now, but, out of curiosity, why didn't my earlier
> testing work?

Might be an edge case in the add-ons manager block code. Not sure if this bug is already reported or not. Adding a couple of people who should know.
The block is now live:
Closed: 11 years ago
Resolution: --- → FIXED
I've verified this in production.
Keywords: qawanted
Product: → Toolkit
You need to log in before you can comment on or make changes to this bug.