User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:184.108.40.206) Gecko/2009011913 Firefox/220.127.116.11 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:18.104.22.168) Gecko/2009011913 Firefox/22.214.171.124 (.NET CLR 3.5.30729) If you have Adobe Acrobat plug-in installed in your Firefox, the browser loads PDF documents automatically without any warnings. That's ok. But when I setup the Firefox (in Options->Programs->File Types dialog), selecting "Ask" for the following documents: "Adobe Acrobat Document", after clicking OK I gone do some test by openning a PDF file, and I didn't get any warnings or messabe box asking if I really wanna load this document! With the recent problem with malwares in PDF docs, I was worried with loading them into my browser without any warnings. Then when I was disabling things related things to this issue I found out this little bug that can pwn any people that trust on Firefox! Reproducible: Always Steps to Reproduce: 1.In Options dialog box, go to "Programs" (or "Programas" in pt-br language) tab, select "Adobe Acrobat Document" and check "Ask" (or "Perguntar" in pt-br), click OK. 2.Visit any direct link to a PDF document (eg: http://www.mozilla.com/press/firefox-3-reviewers-guide.pdf) Actual Results: The browser still loads the PDF document without any warnings! Expected Results: The browser should not load automatically the documents that I have configured in the Options>Programs dialog box. It should prompt me with a message box confirmation with Yes and No buttons. I'm using the Firefox last version until this time (3.0.6) with PT-BR language. I have Adobe Reader 8 application installed on my Windows XP SP2 and the Firefox's plug-in "Adobe Acrobat" as a complement.
If you leave the plugin installed, I think you're vulnerable to pages using <embed> or <object> anyway. But it is kinda weird that having the plugin installed overrides the "ask" selection in this case.
Component: Security → File Handling
Product: Firefox → Core
QA Contact: firefox → file-handling
You say you're using Fierfox 3.0.6, but your user agent string shows Firefox 126.96.36.199?
he spoofed his UA, just look at the "rv:188.8.131.52 , Gecko/2009011913" part. I'm not sure that the "always ask" option ever worked with plugins, the option AFAIK only works with helper applications. Firefox always asks (the first time) for helper applications but never for plugins. remove the plugin and use the Acrobat plugin as helper application and it should work. I think this is a dupe of bug 94035
Summary: [Emergency] Firefox3 is loading PDF files automatically even if we setup it to ask before to load the document! → Firefox3 is loading PDF files automatically even if we setup it to ask before to load the document!
(In reply to comment #2) > You say you're using Fierfox 3.0.6, but your user agent string shows Firefox > 184.108.40.206? Why does it matter? Keep the useless comments for you. (In reply to comment #3) > Firefox always asks (the first time) for helper applications but never for > plugins. > remove the plugin and use the Acrobat plugin as helper application and it > should work. That's true, but the users who have adobe acrobat reader installed on their systems can get confused and they can think that the browser config will protect them against the load of these documents. A suggestion to fix this issue without any coding is to put a text/hint alerting that the "Programs" tab doesn't work with pluggins. And it's another issue, not a dupe!
>Why does it matter? Keep the useless comments for you. The used build does matter for bug reports and it's confusing if your UA is spoofed. Your attitude is wrong, Jesse is a respected member of the Mozilla security group. >That's true, but the users who have adobe acrobat reader installed on their >systems can get confused and they can think that the browser config will >protect them against the load of these documents. The Ui is confusing and the whole plugin handling in the applications panel is broken. You can't for example choose the used plugin if you have 2 plugins for the same mime-type and in that case the application panel list sometimes the wrong plugin. We should consider to remove plugin handling until bug 19118 is fixed.
Another fix would be in the Firefox UI to remove the "always ask" for mime-types that are covered by a plugin
Giving a good summary which contains the correct strings we use on the UI would be nice. That would make it easier to search without filing dupes. This also happens with Firefox 220.127.116.11. So no reason to call it firefox3 in the title. Updated summary and confirmed bug. Workaround: Select another helper application and "Always ask" afterward to make this feature work.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Firefox3 is loading PDF files automatically even if we setup it to ask before to load the document! → Firefox is loading PDF files automatically even if "always ask" was set before loading the document
Version: unspecified → 1.8 Branch
>Workaround: Select another helper application and "Always ask" afterward to >make this feature work. Your wording is wrong, or it sounds wrong. The plugin will be deactivated if you select a helper application. The "always ask" option works with helper applications but not plugins. If you select a helper application you can't use the plugin anymore, the link will be opened with a helper application which could be the external Acrobat reader.
Yes, I missed a "select" in-front of "Always ask". Sorry. Here a copy of my comment in bug 481714 how it can be performed: Steps: 1. Install Adobe Acrobat Reader 2. Create a new profile in Firefox 3. Load PDF: http://www.irs.gov/pub/irs-pdf/f1040ez.pdf?portlet=3 4. Open the preferences window and change the action to another helper application (e.g. Foxit Reader) 5. Load PDF again 6. Set action to "Always ask" 7. Load PDF again After step 5 the pdf is loaded in the given external helper application and after step 7 the expected dialog pops-up.
Summary: Firefox is loading PDF files automatically even if "always ask" was set before loading the document → "Always ask" doesn't work for Plugins
(In reply to comment #11) Shouldn't the option "always ask" be exclusive of whether "plugin" or "helper" was previously selected? You should be able to configure each MIME type (or file extension) to exactly one of the following options: o Always Ask o Save to Disk o Use Helper App o Use Plugin The current implementation seems to always use the plugin, unless plugins.disable_full_page_plugin_for_types (in about:config) contains the MIME type. Only then will Firefox decide whether to ask, save, or use the Helper App. bug 19118 is related, but more about configuring the details of when "Use Plugin" is selected.
Comment on attachment 600398 [details] [diff] [review] patch You have to request review from someone. I'm trying Benjamin
Attachment #600398 - Flags: review?(benjamin)
Comment on attachment 600398 [details] [diff] [review] patch Not sure who to redirect this review to, but Firefox prefs definitely aren't me!
Attachment #600398 - Flags: review?(benjamin) → review?(gavin.sharp)
Hi kernp25 - thanks for the patch. Could you take a moment to explain, at a high level, what your patch changes and why? It would really help potential reviewers to have some context about why you changed the code the way you did.
Comment on attachment 600398 [details] [diff] [review] patch Can't review this without additional information, so I'm taking this out of my queue for the moment - feel free to re-request.
This is really a bug and needs to be fixed!!! Look at my patch and then you will see what you must change in order to fix this.
Steps to Reproduce: 1) Go to Options->Programs->File Types 2) choose pdf plugin after this choose always ask 3) Now open a pdf file e.g. http://www.energy.umich.edu/sites/default/files/pdf-sample.pdf Now you will see that the action has not changed. Again go to Options->Programs->File Types choose now save file (or preview in firefox) then now choose always ask again, and finally it will work!!! So, there is something wrong in http://dxr.mozilla.org/mozilla-central/source/browser/components/preferences/applications.js
There is something wrong with preferredAction and alwaysAskBeforeHandling
Attachment #600398 - Flags: review?(gavin.sharp) → review?(bmcbride)
Comment on attachment 600398 [details] [diff] [review] patch Review of attachment 600398 [details] [diff] [review]: ----------------------------------------------------------------- Oy, this file is a bit arcane. Patch needs updated, but the fix seems "right" in the sense that it will no longer auto-load the plugin when you set it to "Always Ask", and the unfortunate limitations of that option with regards to plugins. * Patch is using Windows file endings, so doesn't apply automatically * Patch is a little bitrotten due to mozilla-central changeset 04811425fc1d (see below) * Also needs to make these changes to the new in-content version of the preferences (browser/components/preferences/incontent/applications.js) ::: browser/components/preferences/applications.js @@ +1613,3 @@ > var handlerInfo = this._handledTypes[typeItem.type]; > > + let action = parseInt(aActionItem.getAttribute("action")); For safetly, always specify the radix argument when using parseInt, ensuring it uses 10. @@ +1616,5 @@ > + > + // Set the plugin state if we're enabling or disabling a plugin. > + if (action == kActionUsePlugin) > + handlerInfo.enablePluginType(); > + else if (handlerInfo.plugin && !handlerInfo.isDisabledPluginType) Patch needs updating - this was changed to .pluginName in October 2013. (And issue because of the way the patch has been generated - this isn't really a change line.)
Attachment #600398 - Flags: review?(bmcbride) → review-
Going to fix up the patch, since it's just mechanical updating. (In reply to Blair McBride [:Unfocused] from comment #26) > For safetly, always specify the radix argument when using parseInt, ensuring > it uses 10. Oops, this wasn't patch of the patch.
Assignee: nobody → kernp25
Status: NEW → ASSIGNED
Created attachment 8444321 [details] [diff] [review] Patch v1.1 r+ with the patch updated to solve the issues mentioned in comment 26.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in before you can comment on or make changes to this bug.