Affected versions

• 81.0a1 (BuildId:20200815093117)

Affected platforms

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

Preconditions

• Ensure that the print.tab_modal.enabled pref is set to true

Steps to reproduce

1. Launch Firefox.
2. Access a random page.
3. Increase the number of copies by using the arrow stepper.
4. Print the page.

Expected result

• The “sheets of paper” section reflects the number of pages that will get printed (multiplied by the number of copies) and the number of papers printed reflects the number of given copies.

Actual result

• The “sheets of paper” section displays the number of papers that will be outputted if the number of copies is 1 (even though the number of copies has increased). Also the number of copies doesn’t seem to get printed on print to pdf (this is not supposed to be supported, see Bug 1659112) nor printed to actual paper.

Regression Range

• This seems to be a regression:
• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fb664f6d43ed943abc6effa00214073365f34fa4&tochange=f46205a42faecda0e5a73bdcde0a8e1caa0126d9
• Potential Regressor: Bug 1656939

Notes

• [Suggested Severity] S2.
• For further information regarding this issue please observe the screencast here (the screencast is above the 10MB limit)

Hi Mark!

It seems that mozregression pointed out Bug 1656939 - Match print form elements to the UX mocks r=sfoster for causing this regression.

Can you please take a look?

Thank you!

Is this when you type a number into the copies field or use the up/down arrows?

When I type a number or use up/down on the keyboard I see the sheets change and I do get the right number of papers out of the printer. But the arrow stepper buttons don't update the sheets of paper count for me.

Yes, it seems that this is only reproducible by increasing the number of copies using the arrow stepper.

(sorry, forgot to mention this. I've also updated the bug's description to reflect this)

Confirmed that the physical printer output is affected as well. Updating the description.

Also, Ubuntu is also as well.

Set release status flags based on info from the regressing bug 1656939

I just ran into this. The new PhotonNumber custom element does not produce a "change" event when you click up/down, which the containing element relies on to know when to call dispatchSettingChange with the new value.

In my patch https://phabricator.services.mozilla.com/D85349 for Bug 1653389, I added an "input" listener and tweaked the sheets of paper section a little to account for page range updates. That should fix the problem when a user types in an input, but the photon number stepper was still having problems. That may have been fixed in Bug 1659184

Hi Emma, as this is P1, can someone be assigned to it, please? Thank you

With my patch applied from Bug 1653389 and the fix from Bug 1659184, the problem no longer appears. Assigning myself to this bug, so I'll remember to close it out once Bug 1653389 lands.

(Since this will be fixed by bug 1653389, I'm removing the [print2020_v81] tag for easier tracking.)

This has been resolved by
https://hg.mozilla.org/mozilla-central/rev/dae38df00129 (Bug 1653389)
and
https://hg.mozilla.org/mozilla-central/rev/a2f26a86b17c (Bug 1659184)

I tried reproducing this issue on macOS 10.15 , Ubuntu 16.04 and Win10x64 with 82.0a1(20200830213209) , 81.0b4(20200829200810) . Confirming this issue as verified fixed.