The default bug view has changed. See this FAQ.

PDF Viewer settings not persistent

RESOLVED FIXED in Firefox 17

Status

()

Firefox
PDF Viewer
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: oscarguit, Assigned: yury)

Tracking

(Depends on: 1 bug)

15 Branch
Firefox 17
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [testday-20121101])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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)...
(Reporter)

Updated

5 years ago
Component: Untriaged → PDF Viewer
I can confirm. Further more, even if you uncheck the "Do it automatically for this type of archive" it still changes the content handler.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

5 years ago
Duplicate of this bug: 777407
This seems like a bug that should block us shipping pdf.js. Is there a tracking bug for that?
Blocks: 748923
(Reporter)

Comment 4

5 years ago
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.
(Assignee)

Comment 5

5 years ago
Created attachment 650961 [details] [diff] [review]
Prevents updating the settings when internal handler is chosen
Assignee: nobody → async.processingjs
(Assignee)

Updated

5 years ago
Duplicate of this bug: 768444
(Assignee)

Updated

5 years ago
Status: NEW → ASSIGNED
Depends on: 741517
OS: Mac OS X → All
Hardware: x86 → All
(Assignee)

Comment 7

5 years ago
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.
Attachment #650961 - Flags: review?(mak77)
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.
Attachment #650961 - Flags: review?(mak77) → review+
(Assignee)

Comment 9

5 years ago
Created attachment 653464 [details] [diff] [review]
patch for checkin

try server https://tbpl.mozilla.org/?tree=Try&rev=2e2598a4b5d4
Attachment #650961 - Attachment is obsolete: true
(Assignee)

Updated

5 years ago
Duplicate of this bug: 775214
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
(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
Flags: in-testsuite-
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/17ddc4d169e1
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 17

Updated

5 years ago
Duplicate of this bug: 777390

Updated

5 years ago
Depends on: 787820
(Assignee)

Updated

5 years ago
Depends on: 790643
Verified fixed using Windows 7 and the latest Nightly.
Whiteboard: [testday-20121101]
You need to log in before you can comment on or make changes to this bug.