Closed Bug 1210617 Opened 6 years ago Closed 6 years ago

(e10s/Private Browsing) Saving any PDF file via inside the build-in PDF viewer in a Private Window, creates the relevant entry in 'Downloads' in the Normal window instead

Categories

(Firefox :: Private Browsing, defect)

44 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 45
Tracking Status
e10s m8+ ---
firefox45 --- fixed

People

(Reporter: rick3162, Assigned: Felipe)

References

Details

Attachments

(1 file)

Using FF 44.0a1 x64.

STR: (in a clean profile)
- launch Firefox: it will open a Normal window
- open a Private window and open any PDF file, eg http://www.cbu.edu.zm/downloads/pdf-sample.pdf
Now, as it's displayed in the build-in PDF viewer (and it's completely loaded), 
click the 'down arrow' button in the build-in viewer in order to download it . 
Observe that:
1. the 'down arrow' button remains pressed
2. the animation in the Downloads button doesn't appear: if you clicki the button, you see that there's no entry for that file in the panel.
- Now, switch to the Normal window and click on the Downloads button:
you'll see that the entry for the PDF file was added there, instead.


Pn the other hand, if you download the PDF file 
via rightclicking on the document in the build-in PDF viewer and pressing 'Save Page as' instead, 
then the issue doesn't occur.
Summary: (Private Browsing) Saving any PDF file via inside the build-in PDF viewer in a Private Window, creates the relevant entry in 'Downloads' in the Normal window instead → (e10s/Private Browsing) Saving any PDF file via inside the build-in PDF viewer in a Private Window, creates the relevant entry in 'Downloads' in the Normal window instead
This issue only occurs with e10s enabled, i.e. in e10s windows.
This sounds very similar to bug 1199841.
tracking-e10s: --- → ?
Depends on: 1199841
Kostas: you filed this bug just a few days ago. Did you notice whether this is a recent regression, or you can't tell for sure? (i.e., you used to do this often in the past and it worked fine, even with e10s on)
Flags: needinfo?(rick3162)
No, unfortunately I can't tell for sure.
Flags: needinfo?(rick3162)
felipe, were you going to pick this up?
Flags: needinfo?(felipc)
Yeah, and i'm hoping it's a dupe of bug 1199841, but we will see
Assignee: nobody → felipc
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(felipc)
The problem is that ExternalHelperAppParent implements nsIChannel but not PrivateBrowsingChannel, which makes nsExternalAppHandler::RetargetLoadNotifications miss the pb status when calling NS_UsePrivateBrowsing.
Attachment #8682054 - Flags: review?(jduell.mcbugs)
Comment on attachment 8682054 [details] [diff] [review]
fix-externalhandler-pbbrowsing

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

I think this should work.  I assume you've tested the patch manually?
Attachment #8682054 - Flags: review?(jduell.mcbugs) → review+
Flags: needinfo?(felipc)
Yep I did, it works.  I'm assuming that there's nothing that needs to be changed here given the new patch in bug 8690005?
Flags: needinfo?(felipc)
(In reply to :Felipe Gomes from comment #9)
> Yep I did, it works.  I'm assuming that there's nothing that needs to be
> changed here given the new patch in bug 8690005?

(Not sure how I came up with that number, but) I meant bug 1199841
https://hg.mozilla.org/mozilla-central/rev/bfd81e42d1dd
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 45
I have reproduced this bug with Firefox Nightly 44.0a1 (Build Id : 20151001030236) on Windows 7(64-bit) with the instructions from comment 0.

Verified as fixed with Firefox Release 45.0.2 (Build ID : 20160407164938)

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0

[testday-20160415]
You need to log in before you can comment on or make changes to this bug.