Onion service authorization prompt's key field does not get focus when clicked

If you click a different window while the onion service authorization prompt is displayed, there's no way to get its text field back in focus to enter the key without explicitly focusing the parent browser window first.

This can get extremely annoying because the popup stays on top of all other windows, which makes retrieving its parent quite frustrating.

To reproduce,

1. Open http://pierovlcy7baatz7xcaccbf2kanct3hvkhcgedz4cbrmcg2ybmjalxad.onion/ and wait for the authorization prompt
2. Move the focus to a different window
3. Click back onto the prompt (which should be visible because is rendered on top of all the other windows)
4. Try to type into the "Enter your privae key for this onion service" text field

/cc @pierov , @donuts

added 12.5 stable UX labels

assigned to @ma1

changed the description

changed title from Onion service authorization prompt's text fied does not get focus when clicked to Onion service authorization prompt's key field does not get focus when clicked

mentioned in merge request !691 (merged)

Adding also here, in addition to the MR: I think we could rework the whole thing for 13.0.

Forcing that kind of panel for the authentication doesn't seem correct to me. Other similar panels are the identity panel, the circuit display, the bookmarks, and, on Firefox, the tracking protection.

They are made to self-close when one changes window. Also, they don't grab user's attention enough, because they're missing fore example an overlay.

I think we should do an actual prompt, like the one for HTTP basic authentication (check for example https://review.torproject.net/).

@ma1 unless you're currently in the middle of this work for 13.0 stable let's plan on kicking this to 13.5 stable

@ma1 unless you're currently in the middle of this work for 13.0 stable let's plan on kicking this to 13.5 stable

WFM.

marked this issue as related to tor-browser-build#40891 (closed)

removed the relation with tor-browser-build#40891 (closed)

marked this issue as related to tor-browser-build#40888 (closed)

marked this issue as related to tor-browser-build#40848 (closed)

added 13.0 stable Next labels

added Desktop label

added Bug label

added Doing label

removed the relation with tor-browser-build#40848 (closed)

added 13.5 stable label and removed 12.5 stable Bug Desktop Doing Next UX labels

Sorry for the labeling spam, had to find the hard way what /relabel does

added Bug Desktop Doing Next UX labels and removed 13.0 stable label

removed Next label

added Roadmap::Future label

removed Doing label

removed 13.5 stable label

added 14.5 stable label

added 14.0 stable label

unassigned @ma1

assigned to @ma1

OK, it seems the fix 4a13c283 had been merged and release in 12.5.1 (July 5 2023), but got lost somewhere along the way - the code is not there anymore and the bug is again reproducible.

Reassigned to myself to check whether a cherry-pick of the old commit is enough to "refix" it.

Cherry-picking is not enough because of some minor conflicts, but they can be easily solved.

Spinning a related bug to fix the regression in 13.5, and a Roadmap::Future one for the overhaul @pierov was suggesting above.

This one can be closed per 12.5.1 changelog, I guess.

closed

removed 14.0 stable 14.5 stable Roadmap::Future labels

marked this issue as related to #42557 (closed)

mentioned in issue #42557 (closed)

marked this issue as related to #42558

mentioned in issue #42558

Note, I think this is only for X11 window system. Not a problem when the browser is forced to use wayland since the popup remains attached to the parent window. Not sure about other platforms. !691 (comment 2915985)

added Linux label