search

keeleysam / tenfourfox

Automatically exported from code.google.com/p/tenfourfox
0 stars 0 forks source link

PDFs don't download or display (via pdfjs) when Schubert PDF Plugin is present in Library/Internet Plugins #188

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I think this is (in some or all cases) what people mean on Tenderapp when they 
complain that PDFs "don't download". We ship with plugins disabled, but there 
still seems to be some interaction with them. 

As long as this plugin is present in the root Library/Internet Plugins, 
clicking a PDF or visiting a link with a pdf results in the browser doing 
nothing. This happens with a completely fresh Firefox user profile.

After removing the plugin from Internet Plugins, the browser behaves as 
specified in Preferences/Applications ("Preview" if pdfjs is enabled, "Save as" 
or "Ask"). 

Not sure if this is our bug, but since we're the only ones shipping with 
plugins disabled, this should be fixed.

Test Link: http://www.color.org/version4pdf.pdf
Attached Schubert PDF Plugin for testing purpose.

Original issue reported on code.google.com by chtru...@web.de on 4 Nov 2012 at 10:53

Attachments:

GoogleCodeExporter commented 9 years ago 
That makes sense. I must be missing a setting somewhere.

Original comment by classi...@floodgap.com on 4 Nov 2012 at 10:55

GoogleCodeExporter commented 9 years ago 
to me

Original comment by classi...@floodgap.com on 4 Nov 2012 at 10:55

GoogleCodeExporter commented 9 years ago 
The same goes for unembedded QuickTime movies. If the link goes directly to a 
.mov or .mp4, there's no Open/Save dialog as long as the QuickTime plugin is in 
Internet Plugins. 

Example: 
http://imgsrc.hubblesite.org/hu/webb_telescope/behind_the_webb/db/15-the-golden-
touch/015_behind_webb_1280x720.mp4

Original comment by chtru...@web.de on 5 Nov 2012 at 12:01

GoogleCodeExporter commented 9 years ago 
I'm thinking we need to return NS_ERROR_CONTENT_BLOCKED_SHOW_ALT from 
nsPluginHost::InstantiateFullPagePluginInstance instead of NS_OK.

Original comment by classi...@floodgap.com on 5 Nov 2012 at 1:58

GoogleCodeExporter commented 9 years ago 
That didn't fix it.

Original comment by classi...@floodgap.com on 5 Nov 2012 at 2:26

GoogleCodeExporter commented 9 years ago 
Changing nsPluginDirDarwin.cpp/nsPluginsDir::IsPluginFile to return false 
unconditionally does fix the bug. This might change behaviour somewhat, so I'm 
not going to backport this to 10.0.11 (they'll just have to pull the plugin out 
of the folder). I'll have to hook this up to the master switch preference for 
17. Sigh.

Original comment by classi...@floodgap.com on 5 Nov 2012 at 2:44

GoogleCodeExporter commented 9 years ago

Original comment by classi...@floodgap.com on 5 Nov 2012 at 2:47

GoogleCodeExporter commented 9 years ago 
So the pref works, but if plugins are ever enabled at all, it gets cached and 
if they get turned off again the problem reasserts. However, I think that is 
good enough for the shipped configuration since people who turn them on are 
likely to keep them on.

Original comment by classi...@floodgap.com on 5 Nov 2012 at 3:17

GoogleCodeExporter commented 9 years ago 
Can this cache be flushed somehow (just in case we get another Tenderapp 
question)? 

Also, I found that enabling plugins in about:config, and then disabling all of 
them manually in the Add-ons manager doesn't cause this problem. That's what I 
usually do (leaving only Flash enabled because German news portals don't seem 
to be interested in offering Flash alternatives at all, and I do need the 
content), so I never noticed the bug.

Original comment by chtru...@web.de on 5 Nov 2012 at 12:43

GoogleCodeExporter commented 9 years ago 
Restarting the app will flush things out.

Original comment by classi...@floodgap.com on 5 Nov 2012 at 2:08

GoogleCodeExporter commented 9 years ago 
Shipp'd

Original comment by classi...@floodgap.com on 20 Nov 2012 at 6:10