1661020 - [macOS] Copies default value is not deleted with ease if the value is not highlighted

Status: VERIFIED FIXED

(Toolkit :: Printing, defect, P1)

Description

[Emil Ghitta, QA [:emilghitta]]

Affected versions

• 82.0a1 (BuildId:20200824215021)
• 81.0b1 (BuildId:20200824150741)

Affected platforms

• macOS 10.14

Unaffected platforms

• Ubuntu 20.04 64bit
• Windows 10 64bit

Steps to reproduce

1. Launch Firefox.
2. Open any webpage.
3. Hit CTRL + P.
4. Tab through the options until you reach the Copies section.
5. Press the -> arrow key to remove the focus from the default value.
6. Try to delete the value via backspace.

Expected result

• Like in Windows & Ubuntu, the value can be successfully deleted even though it is not selected and the leading value starting with a different number (like ex: 2 for 20 copies) can be easily entered.

Actual result

• The default value (1) cannot be easily delete (the keyboard only user has to enter another value next to the default one and navigate to the first one in order to delete it || the keyboard user has to refocus the Copies field and to directly input the leading value).

Regression Window

• This seems to be a regression:

• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=89bbbe5e6369e1ce2b75ddf75cd201782ce362b2&tochange=3ea0ca6e62185703a20b27fe1e7b7a062e9c4d2a

• Potential regressor: Bug 1660296

Comment 1

[Emil Ghitta, QA [:emilghitta]]

Hi Jonathan!

It seems that mozregression pointed out Bug 1660296 for causing this regression.

Can you please take a look?

Thank you!

Comment 2

[Jonathan Kew [:jfkthame]]

Hmm, it does seem a bit awkward. So does the behavior I see prior to bug 1660296 landing, though, or on Windows: if the cursor is after a single-digit number in the Copies field, and I press backspace, the number isn't simply deleted (as might be expected), instead it changes to 0, the field is highlighted as invalid, and the rest of the panel disabled. If I then press backspace again, the zero is deleted and the invalid state is cleared (although "empty" isn't really a valid number of copies!)

I'll try to look into why this changed, but I think more generally the behavior here is a bit weird.

Comment 3

[Mark Striemer [:mstriemer]]

Attachment: Bug 1661020 - Only update the copies count when it's valid r?emalysz

Comment 4

[Blake Winton (:bwinton) (:☕️)]

Marking as P1, cause we're about to fix it (hopefully 😉)…

Comment 5

[Mark Striemer [:mstriemer]]

Comment on attachment 9171937 [details]
Bug 1661020 - Only update the copies count when it's valid r?emalysz

Beta/Release Uplift Approval Request

• User impact if declined: Clearing the copies field can be difficult since it is repopulated with the default value when cleared.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce: See comment 0.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This adds a simple validity check before updating the copies setting.
• String changes made/needed: No

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c2814762d721
Only update the copies count when it's valid r=emalysz

Comment 7

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/c2814762d721

Comment 8

[Julien Cristau [:jcristau]]

Comment on attachment 9171937 [details]
Bug 1661020 - Only update the copies count when it's valid r?emalysz

approved for 81.0b3

Comment 9

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/8fc8081d72b6

Comment 10

[Emil Ghitta, QA [:emilghitta]]

This is verified fixed using Firefox 81.0b3 (BuildId:20200827203325) and Firefox 82.0a1 (BuildId:20200827212940) on macOS 10.14.

Comment 11

[Maria Berlinger [:mberlinger], Services QA]

https://testrail.stage.mozaws.net/index.php?/cases/view/1084717