777388 - PDF Viewer settings not persistent

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, defect)

Description

[oscarguit]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120717110313

Steps to reproduce:

Trying to open several PDF files with PDF Viewer in Firefox 15b1, Mac OS X Lion 10.7.4


Actual results:

Some pdf files are not opened with PDF Preview 

Steps to reproduce the problem:

1. Check Preferences, Applications, if you search for PDF you have two entries with these settings:
   a. Portable Document Format (application/x-pdf) - Ask always
   b. Portable Document Format (PDF) - Preview in Firefox

2. Go to http://www.obets.ua.es/obets/libros/LibroReflexiones.pdf, it will open with PDF Viewer.

3. Go to http://www.aneca.es/content/download/10522/118049/file/academia_guiadeayuda_110310.pdf

4. Step 3 will not use PDF Viewer but t will show you the download window, with "Save file" and "Do it automatically for this type of archive" checked by default. Click Ok.

5. Now repeat steps 2 and 3. In both cases, Firefox will download the pdfs and PDF Viewer will not be used anymore. In Preferences, Applications you will find that settings for PDF have changed:
   a. Portable Document Format (application/x-pdf) - Ask always
   b. Portable Document Format (PDF) - Save file



Expected results:

I don't know the difference in the files from steps 2 and 3, but it seems to be treated as different file types. But in any case the action in one file type (download) should not affect the other file type (PDF Viewer)...

Comment 1

[Brendan Dahl [:bdahl]]

I can confirm. Further more, even if you uncheck the "Do it automatically for this type of archive" it still changes the content handler.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

This seems like a bug that should block us shipping pdf.js. Is there a tracking bug for that?

Comment 4

[oscarguit]

Just in case this information is useful, this problem was not present when I was using PDF Viewer as an add-on in FF 14.

Comment 5

[Yury Delendik (:yury)]

Attachment: Prevents updating the settings when internal handler is chosen

Comment 7

[Yury Delendik (:yury)]

Comment on attachment 650961 [details] [diff] [review]
Prevents updating the settings when internal handler is chosen

Tentatively assigning the reviewer based on the familiarity with Bug 752676.

Comment 8

[Marco Bonardo [:mak]]

Comment on attachment 650961 [details] [diff] [review]
Prevents updating the settings when internal handler is chosen

Review of attachment 650961 [details] [diff] [review]:
-----------------------------------------------------------------

I tried to follow all of the code paths here, and it looks correct, the comment is clear enough.
So basically, an internal handler may fallback to a download dialog, but we should not remember the download action in such a case since it's not user's action.  Though if at this point the user activates the checkbox we still save the action.  This makes sense to me.

Now, I'd probably ask for a test, but I'm not sure how much that may be time-consuming, considered it involves dialogs and adding a test-only handler or assuming pdf.js is available.  Plus considering the code is a quite straight early-return, it should be strong enough against goofy changes.  I'd say to just proceed with the fix, that looks quite important for proper functionality of pdf.js.

Comment 9

[Yury Delendik (:yury)]

Attachment: patch for checkin

try server https://tbpl.mozilla.org/?tree=Try&rev=2e2598a4b5d4

Comment 11

[Ryan VanderMeulen [:RyanVM]]

(In reply to Yury (:yury) from comment #9)
> try server https://tbpl.mozilla.org/?tree=Try&rev=2e2598a4b5d4

Green on Try.

https://hg.mozilla.org/integration/mozilla-inbound/rev/17ddc4d169e1

Comment 12

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/17ddc4d169e1

Comment 14

[Gabriela [:gaby2300]]

Verified fixed using Windows 7 and the latest Nightly.