[macOS] Copies default value is not deleted with ease if the value is not highlighted
Categories
(Toolkit :: Printing, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox79 | --- | unaffected |
firefox80 | --- | unaffected |
firefox81 | --- | verified |
firefox82 | --- | verified |
People
(Reporter: emilghitta, Assigned: mstriemer)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [print2020_v81] [old-ui-])
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
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
- Launch Firefox.
- Open any webpage.
- Hit CTRL + P.
- Tab through the options until you reach the Copies section.
- Press the -> arrow key to remove the focus from the default value.
- 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:
-
Potential regressor: Bug 1660296
Reporter | ||
Comment 1•4 years ago
|
||
Hi Jonathan!
It seems that mozregression pointed out Bug 1660296 for causing this regression.
Can you please take a look?
Thank you!
Comment 2•4 years ago
|
||
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.
Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
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
Pushed by mstriemer@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c2814762d721 Only update the copies count when it's valid r=emalysz
Comment 7•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Comment 8•4 years ago
|
||
Comment on attachment 9171937 [details]
Bug 1661020 - Only update the copies count when it's valid r?emalysz
approved for 81.0b3
Updated•4 years ago
|
Comment 9•4 years ago
|
||
bugherder uplift |
Reporter | ||
Comment 10•4 years ago
|
||
This is verified fixed using Firefox 81.0b3 (BuildId:20200827203325) and Firefox 82.0a1 (BuildId:20200827212940) on macOS 10.14.
Comment 11•4 years ago
|
||
Updated•4 years ago
|
Description
•