Closed Bug 1663019 Opened 4 years ago Closed 2 years ago

Print headers and footers & Print Backgrounds options are available for pdf documents

Categories

(Toolkit :: Printing, defect, P3)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1752379
Tracking Status
firefox81 --- disabled
firefox82 --- wontfix
firefox83 --- affected

People

(Reporter: emilghitta, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [print2020] [old-ui-] )

Affected versions

  • 82.0a1 (BuildId:20200903094553)
  • 81.0b5 (BuildId:20200901203141)

Affected platforms

  • Windows 10 64bit
  • Ubuntu 18.04 64bit
  • macOS 10.14

Steps to reproduce

  1. Launch Firefox.
  2. Access the following link
  3. Hit Ctrl + P
  4. Access the “Options” section.

Expected result

  • The Print headers and footers & the Print Backgrounds are not available for pdf files.

Actual result

  • The Print headers and footers & the Print Backgrounds are available for pdf files but they seem not to be applied on PDF documents (Print headers and footers at least).

Regression Window

  • I don’t think that this is a regression.

Additional Information

  • It seems that Chrome hides those options for pdf documents
  • [Suggested Severity] S3 or S4
Has STR: --- → yes

(In reply to Emil Ghitta, QA [:emilghitta] from comment #0)

Expected result

  • The Print headers and footers & the Print Backgrounds are not available for pdf files.

Why not. Shouldn't the user be the one to choose what they want?

Actual result

  • The Print headers and footers & the Print Backgrounds are available for pdf files but they seem not to be applied on PDF documents (Print headers and footers at least).

That sounds like the bug to me.

Flags: needinfo?(camelia.badau)
Priority: -- → P2

(In reply to Jonathan Watt [:jwatt] from comment #1)

Why not. Shouldn't the user be the one to choose what they want?

I agree. Since Chrome, Microsoft Edge & Opera seems to not support that option for pdf documents in their print previews I thought that this may be a limitation and the option shouldn't exist for PDF documents.

Flags: needinfo?(camelia.badau)

I disagree… I think PDFs should be printed the way they're rendered, and are mostly used for documents that are already laid out and formatted. I worry that people will forget to un-check the checkbox, and complain about the extra crap that Firefox adds at the bottom.

But in the end, it's probably @shorlander's call, and perhaps he's thought about it already and has an answer. 🙂

Flags: needinfo?(shorlander)
See Also: → 1662534
Whiteboard: [print2020_v81] [old-ui-] → [print2020_v82][old-ui-]
Priority: P2 → P3

In terms of practicalities, the way to fix this is probably to add a contentType to WindowGlobalParent that mirrors document.contentType, and then check for sourceBrowsingContext.currentWindowContext.contentType == "application/pdf" in PrintEventHandler.init().

Moving to 83.

Whiteboard: [print2020_v82][old-ui-] → [print2020_v83][old-ui-]
Severity: -- → S4
Whiteboard: [print2020_v83][old-ui-] → [print2020_v84][old-ui-]
Whiteboard: [print2020_v84][old-ui-] → [print2020_v85] [old-ui-]

(Moving bugs to 86, part 1.)

Whiteboard: [print2020_v85] [old-ui-] → [print2020_v86][old-ui-]

Moving things to 88, cause we're mostly on Proton these days…

Whiteboard: [print2020_v86][old-ui-] → [print2020_v88] [old-ui-]
Whiteboard: [print2020_v88] [old-ui-] → [print2020] [old-ui-]

I think this may count as a regression of 743252.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:mstriemer, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(stephen) → needinfo?(mstriemer)
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(mstriemer)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.