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

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

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:

• Last good revision: 24648c48a49cc229f8839d19c22fb2626f767c82
• First bad revision: b32cb06ef2aeaa939af0484498fcbfd74db05790
• Pushlog:
  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=24648c48a49cc229f8839d19c22fb2626f767c82&tochange=b32cb06ef2aeaa939af0484498fcbfd74db05790

(Moving bugs to 86, part 1.)

Hi,

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

(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!

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

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.