Closed Bug 1679535 Opened 2 years ago Closed 4 months ago

Most of the new Print modal options are inaccessible on destination change if previously a print action was made using Foxit reader with the old modal

Categories

(Toolkit :: Printing, defect, P5)

All
Windows
defect

Tracking

()

RESOLVED DUPLICATE of bug 1756169
Tracking Status
firefox-esr78 --- unaffected
firefox84 --- wontfix
firefox85 --- wontfix
firefox86 --- wontfix

People

(Reporter: Anca, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [print2020][old-ui-])

Attachments

(3 files)

Attached image screencast_issue .gif

Affected versions

  • 84.0b5
  • 85.0a1 (2020-11-26)

Affected platforms

  • Windows 7

Steps to reproduce

Preconditions:

  • Have Foxit Reader installed with a version below 10 (on latest version the print to pdf function was removed, but some user will stick with the older ones for this functionality)
  1. Launch Firefox
  2. Have the print.tab_modal.enabled to false
  3. Print any page usimng Foxit reader option
  4. Set the print.tab_modal.enabled to true
  5. Ctrl + P on the same page
  6. Change the destination to any other option

Expected result

  • The selected destination is set, the modal is active

Actual result

  • step 5 - The print preview is totally grey
  • step 6 - Most of the options turns inaccessible, except Destination, Margins and Cancel button

Regression range

  • Not sure if this is a regression or not, it seems to reproduce intermittently on older builds, i’ve ended up with different pushlogs every time, but around 22/24 Oct; I will try asap to provide more relevant info here.

Additional notes

  • If Foxit reader is not used previously with the old modal this issue is not reproducible
  • The issue is reproducible only for the first changed destination, a second selection turns all the options active
  • The preview is broken permanently for Foxit Reader destination on any page (completely grey), restarting the browser doesn’t fix it

Suggested severity

  • S4
QA Whiteboard: [qa-regression-triage]
Has Regression Range: --- → no
Has STR: --- → yes
Severity: -- → S4
Priority: -- → P5

Can you attach the contents of about:support when you reproduce this? I'm curious what the preference values are when this happens.

Flags: needinfo?(anca.soncutean)
Attached file about:support content
Flags: needinfo?(anca.soncutean)
Attached image paper size culprit.png

Now I see that there is one paper size that triggers this issue and apparently is set as default when switching print.tab_modal.enabled back on.

With paper size set to the one mentioned in comment 3 I've ended up with the following regression:

Flags: needinfo?(bobowencode)
Regressed by: 1663940

(Moving bugs to 86, part 1.)

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

Hi,

AS per comment 4 is it ok to udpate "has regression range" to yes?
Thanks!
Clara

Flags: needinfo?(anca.soncutean)

(In reply to Clara Guerrero from comment #6)

Hi,

AS per comment 4 is it ok to udpate "has regression range" to yes?
Thanks!
Clara

Yes, I've missed that when I've provided the regression. Thank you!

Has Regression Range: no → yes
Flags: needinfo?(anca.soncutean)

Sorry about the delay here.
I've managed to reproduce this, it seems that the Foxit PDF driver returns a custom (ID 256) paper size that is 1mm x 1mm in its paper list.
Normally it has an empty name so we reject it at [1], but occasionally it has a fairly corrupt one, which we don't reject.

It's not clear to me why this then causes options to become inaccessible.
mstriemer - perhaps you might have ideas there?

Maybe we should revisit the validation again and maybe reject anything less than 5mm (50) at [1] and at [2].

[1] https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/widget/windows/nsPrinterWin.cpp#291
[2] https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/widget/nsPrintSettingsService.cpp#331-333

Flags: needinfo?(bobowencode) → needinfo?(mstriemer)
Whiteboard: [print2020_v86][old-ui-] → [print2020_v88][old-ui-]
Whiteboard: [print2020_v88][old-ui-] → [print2020][old-ui-]
See Also: → 1756169

I suspect this is fixed by bug 1756169 (in that the form should be usable now). Not quite a dupe since we could ignore this paper size, but it seems like it should also fix the issue.

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