Closed Bug 1664413 Opened 1 year ago Closed 8 months ago

Printing doesn't use current session cookies when in private mode

Categories

(Core :: Printing: Output, defect)

80 Branch
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox80 --- wontfix
firefox81 --- fixed
firefox82 --- fixed

People

(Reporter: paulo+mozilla, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [print2020][layout:print-triage:p2])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36

Steps to reproduce:

Trying to print a page which requires sessions cookies. The page contains images that also require session cookies to be rendered.

Actual results:

The page itself renders fine on the browser window, including its images, but the printing itself shows broken images. Web server logs shows that the request for the images do not send the session cookies.

This happens in private mode or when using the "Never member history" setting.

On Mac, it's enough to do a PDF preview of the print to reproduce the problem.

Expected results:

Session cookies should be sent for (image) requests when printing the content of the current window — even when using private mode.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Printing: Output
Product: Firefox → Core

Do you have a page where we could reproduce this by any chance? It'd be helpful.

To be clear, this works in non-private mode, right?

Attached file print-issue.tar.gz

I'm attaching some basic php files that can reproduce the issue on demand.

  1. Unzip them in a folder on a machine with php
  2. run php -S 127.0.0.1:8080
  3. go to http://localhost:8080/1.php (in Private mode)
  4. follow button to 2.php
  5. try printing that page with the image. Image will be broken because session cookies are not sent.

Note: this can also be reproduced in non-private mode if "Never remember history" is being used.

Severity: -- → S3
Whiteboard: [print2020][layout:print-triage:p2]

Thanks forma the test case! I'll poke.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Flags: needinfo?(emilio)
Resolution: --- → INVALID

Err, fail from my phone :)

Assignee: nobody → emilio
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---

For the record: I looked at this today and couldn't print the image even on a clean, non-private session, but turns out I get:

Uncaught Error: Call to undefined function imagecreatefromjpeg() in /home/emilio/Downloads/print-issue/3.php:4

So I'll see how to enable that php function somehow.

Hmm, I got around that, but I can print the image just fine in Nightly, but somehow not on release... Can you confirm it works for you as well using a build from nightly.mozilla.org?

Ok, so this had to break in bug 1648064, because before that we didn't have image requests done for printing at all.

But it is fixed in Nightly, and I bisected this as follows:

$ mozregression --bad 2020-07-23 --arg="-private-window" -a http://localhost:8080/1.php --find-fix

And I got this fix range:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2969f3de028f013d30ea20bfccc13670ef8e195f&tochange=3afa7dd98397977db72ea93ba1253a327a1dcbaf

Which points to bug 1636728. Which makes some amount of sense, because before that we were minting a whole browsing context for printing which didn't preserve the origin attributes (container, private browsing mode, etc...) from the original doc.

So I think the only thing left here is adding an automated test to make sure this doesn't break again... Given this only happened for actual print output this is not the most trivial thing to test, though...

Depends on: 1636728
Flags: needinfo?(emilio)
Regressed by: 1648064

FWIW, I can confirm that it works on nightly.

Do I understand correctly that 81.0, when released, will have this fixed?

(In reply to paulo+mozilla from comment #10)

Do I understand correctly that 81.0, when released, will have this fixed?

I believe so. Can you confirm whether this is fixed in v81 for you?

Flags: needinfo?(paulo+mozilla)

Yes, I confirm it works as expected on v81.0 when using Private Window. Thanks for the fix/follow up.

Flags: needinfo?(paulo+mozilla)
Status: REOPENED → RESOLVED
Closed: 1 year ago8 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.