1681891 - Print preview - focus ring not triggered on-click

Status: RESOLVED WONTFIX

(Toolkit :: Printing, defect, P3)

Description

[Cristian Fogel [:cfogel]]

Attachment: Screen Recording 2020-12-11 at 10.43.55.mov

Affected versions

• 85.0a1(2020-12-10); 84.0;

Affected platforms

• macOS 10.15;

Steps to reproduce

1. Launch Firefox, access any page;
2. CTRL+P to trigger print preview;
3. Click on either Portrait/Landscape button(s);
4. Press the Left-Right keys on the keyboard;

Expected result

• toggle between Landscape/Portrait is working;

Actual result

• keyboard (left/right arrow) toggle between Landscape/Portrait is not working;

Regression range

• First bad: 2020-07-21;
• Last good: 2020-07-20;
• Pushlog: URL;
• Potential regressor: visible with addition of this section in the new modal - bug 1652861;

Additional notes

• S4 as suggested severity;
• attached recording to illustrate the issue;
• later edit: not reproducible on Windows 10, Ubuntu 20.

Comment 1

[Julien Cristau [:jcristau]]

Can we set a priority/severity on this?

Comment 2

[Mark Striemer [:mstriemer]]

I think this is the expected behaviour on macOS. Clicking a form element doesn't focus it there, but on Windows it should (but we hide the focus styles).

On Windows/Ubuntu when I click a portrait/landscape button I can switch between them with the arrow keys, but on macOS the arrow keys do nothing. The same behaviour can be seen with the sidebar items in about:addons (click then up/down to move, works on Linux/Win but not macOS) or the types of trackers blocked in about:addons (this is actually backed by radio inputs like the landscape/portrait buttons here).

Is this still reproducing for you on Windows/Linux? If it isn't then I think this is fixed.

Comment 3

[Cristian Fogel [:cfogel]]

Indeed it is limited to macOS, string wasn't updated from my template.
Did a double check anyway and it is limited to macOS.

Now, as far as consistency could we swap this into an enhancement suggestion and probably run it by UX?
As it might be a bit more intuitive, even though it's borderline edge-case use scenario.

Or it's intended as is? In that case, indeed we can close the bug.

Comment 4

[Mark Striemer [:mstriemer]]

Sounds like this is the expected behaviour on macOS then. I don't think we should diverge from how these inputs would normally behave there.