Closed Bug 1663639 Opened 4 years ago Closed 4 years ago

[Win] Printed pages are blank when using a new profile

Categories

(Core :: Printing: Output, defect, P1)

Firefox 81
Desktop
Windows
defect

Tracking

()

VERIFIED FIXED
Tracking Status
firefox81 --- disabled
firefox82 --- verified
firefox83 --- verified

People

(Reporter: vlucaci, Unassigned)

References

(Blocks 1 open bug)

Details

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

Attachments

(1 file)

Attached file New Text Document.txt

Affected versions

  • 81.0b7 (20200906164749)
  • 82.0a1

Affected platforms

  • Windows 10x64
  • Windows 7x64

Steps to reproduce

  1. Launch FF.
  2. Go to any random page.
  3. Trigger the new Print Modal.
  4. Print.

Expected result

  • Printed page is the same as the page displayed in Print Preview.

Actual result

  • Printed page is blank.

Suggested Severity

  • Seeing as how this blocks testing as well as a vital functionality part for an important OS, I would suggest an S1 for this.

Regression range

  • I did not manage to reproduce this issue on an earlier build from when the feature was implemented, nor was I able to reproduce this issue with 81.0b6 using the exact STR so this seems like a very recent regression.
  • This issue does not occur while searching for a regression using mozreg.

Additional notes

  • This issue does not occur for macOS or Ubuntu
  • This issue does not reproduce on the latest nightly 82.0a1 (2020-09-07)
  • Attached there is a Raw Browser Data.
  • This issue appears to only occur with a clean profile.
  • Uncaught (in promise) undefined
    TypeError: tab is undefinedLinkHandlerParent.jsm:46:15 receiveMessage resource:///actors/LinkHandlerParent.jsm:46 are caught in browser console.
OS: Windows 10 → Windows
Summary: [Win10] Printed pages are blank → [Win] Printed pages are blank

(In reply to Vlad Lucaci, QA (:vlucaci) from comment #0)

  • 81.0b7 (20200906164749)

Presumably b7, where the pref is off by default, was the test that led you to mark this [old-ui-]. Did you also test b7 with the pref on? It would be helpful if you could note the pref state along with the versions you test to eliminate any doubt about combinations. :-)

(In reply to Vlad Lucaci, QA (:vlucaci) from comment #0)

  • This issue does not reproduce on the latest nightly 82.0a1 (2020-09-07)

Actually, now I'm quite confused. Did this only happen in in 2020-09-06, but is now fixed in 2020-09-07?

Summary: [Win] Printed pages are blank → [Win] Printed pages are blank when using a new profile

Trigger the new Print Modal.

I'm assuming this means with the pref ON. But yes, would be good to have more clarity there. I'm just going to P1 this so it gets on our list for upcoming discussions.

Severity: -- → S1
Priority: -- → P1

From the attachment in comment 0

[
 "experimental-features-print-preview-tab-modal",
 "print.tab_modal.enabled",
false
],
Whiteboard: [print2020_v81] [old-ui-] → [print2020_v81] [old-ui+]

Huh, I didn't read the comment 0 carefully.
(In reply to Vlad Lucaci, QA (:vlucaci) from comment #0)

Steps to reproduce

  1. Launch FF.
  2. Go to any random page.
  3. Trigger the new Print Modal.
Whiteboard: [print2020_v81] [old-ui+] → [print2020_v81] [old-ui-]

If I did correctly do a proper confirmation (I did download zip files from treeherder and used it), unsetting EARLY_BETA_OR_EARLIER caused this issue. Is there any printing relevant stuff controlled by IS_EARLY_BETA_OR_EARLIER other than print.tab_modal.enabled?

Odd, I did flip all prefs marked by IS_EARLY_BETA_OR_EARLIER in StaticPrefList.yaml, but still this issue happens on 81.0b8... Quite odd.

Gosh, there are a bunch of ifdef EARLY_BETA_OR_EARLIER in our code. I will check them one by one.

This is indeed quite odd.
I tried a local built beta. Actually this issue happened there, but once after I used the system dialog from the new print preview UI, the issue has been solved. Even after with new profiles, the issue has never happened again so far. So I am now thinking using the system dialog stores something important information somewhere other than our profile data (Windows registry?).

Unfortunately I can no longer reproduce the issue on my Windows laptop.

Note for people who tries to solve/investigate this issue. DO NOT OPEN THE SYSTEM DIALOG, DO NOT OPEN THE OLD PRINT PREVIEW.

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

(In reply to Vlad Lucaci, QA (:vlucaci) from comment #0)

  • 81.0b7 (20200906164749)

Presumably b7, where the pref is off by default, was the test that led you to mark this [old-ui-]. Did you also test b7 with the pref on? It would be helpful if you could note the pref state along with the versions you test to eliminate any doubt about combinations. :-)

Yes, the issue was encountered while testing with the preff ON.

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

(In reply to Vlad Lucaci, QA (:vlucaci) from comment #0)

  • This issue does not reproduce on the latest nightly 82.0a1 (2020-09-07)

Actually, now I'm quite confused. Did this only happen in in 2020-09-06, but is now fixed in 2020-09-07?

No. This issue was encountered on 81.0b7 , but on Nightly 2020-09-07 I was unable to reproduce.

Whiteboard: [print2020_v81] [old-ui-] → [print2020_v82] [old-ui-]

Bob: Any ideas here? Comment 9 seems to be the best lead.

Flags: needinfo?(bobowencode)

(In reply to Sean Voisen (:svoisen) from comment #11)

Bob: Any ideas here? Comment 9 seems to be the best lead.

I can reproduce this on the latest Beta (with modal enabled) but not on Nightly (both with a fresh profile).
So, given Vlad can no longer reproduce either (comment #10), should we just resolve?

I can try and find the patch that fixed it if we really want?

Flags: needinfo?(bobowencode) → needinfo?(svoisen)

(In reply to Bob Owen (:bobowen) from comment #12)

I can reproduce this on the latest Beta (with modal enabled) but not on Nightly (both with a fresh profile).
So, given Vlad can no longer reproduce either (comment #10), should we just resolve?

Will close and we can reopen if discovered again

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(svoisen)
Resolution: --- → FIXED
Flags: qe-verify+

Hello,

I was unable to reproduce this issue on Win10x64, Win7x64 (and macOS 10.15 and Ubuntu 18, even though this issue was Win specific) with 82.0(20201012131351) and 83.0a1(20201013094053).

We have wrote a regression test (as per comment 14) and will re-open if this issue is to resurface in the future.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: