Firefox download permission dialog shows cursor (weird vertical bar) after the size

NEW
Unassigned

Status

()

P5
normal
a year ago
a year ago

People

(Reporter: Atoll, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

a year ago
Created attachment 8899503 [details]
Screen Shot 2017-08-21 at 08.39.07.png

I'm not sure why there's a vertical bar after the size here, but it's been there since at least Nightly (2017-08-15) on OS X 10.12.6.

Comment 1

a year ago
It's a readonly textbox, and presumably it's getting focused as the only focusable control in the dialog. I don't know if there's a way to prevent this without breaking text selection.
Component: General → Downloads Panel
Summary: Firefox download permission dialog shows a weird vertical bar after the size → Firefox download permission dialog shows cursor (weird vertical bar) after the size
(Reporter)

Comment 2

a year ago
Is text selection of the string "(1.0MB)" intentional here? AFAIK, the common desktop and mobile platforms have mechanisms for offering readonly text that can be selected by the user without displaying a cursor.

Also, the "Save File" button is a focusable control, and is in fact the default behavior of the dialog; why does focus not go there instead?

Comment 3

a year ago
(In reply to Richard Soderberg  [:atoll] from comment #2)
> Is text selection of the string "(1.0MB)" intentional here? AFAIK, the
> common desktop and mobile platforms have mechanisms for offering readonly
> text that can be selected by the user without displaying a cursor.

Probably, but I'm not an expert on the history of the component. I'm just sorting out your bugs and trying to clarify them where that seems appropriate...

> Also, the "Save File" button is a focusable control,

Only if you enabled button focus ("full keyboard access", as opposed to focus only moving between textboxes and lists) on OS X - this is not the default (or at least wasn't, last time I checked).

> and is in fact the
> default behavior of the dialog; why does focus not go there instead?

I imagine the focus algorithm for window opening picks the first focusable element unless otherwise instructed.
(Reporter)

Comment 4

a year ago
Ah, I see. Yes, technically, I can understand *why* this bug would occur - thank you for the explanation! I still assert it's a bug to be fixed, though, under the same general category of "UX work incomplete" as bug 1392302 and bug 1392305.

Updated

a year ago
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.