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

Status: REOPENED

(Firefox :: Downloads Panel, defect, P5)

Description

[:Atoll]

Attachment: 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

[:Gijs (he/him)]

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.

Comment 2

[:Atoll]

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

[:Gijs (he/him)]

(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.

Comment 4

[:Atoll]

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.