spaces toolbar customization dialog does not disappear when clicking outside of the dialog
Categories
(Thunderbird :: Toolbars and Tabs, defect)
Tracking
(Not tracked)
People
(Reporter: soeren.hentzschel, Unassigned)
References
(Blocks 1 open bug)
Details
STR:
- Open the customization dialog for the spaces toolbar.
- Click somewhere outside of the dialog.
Expected:
The customization dialog disappers. If you compare it with the customization dialog for the area above the e-mails (the area with the buttons to reply, forward, archive, …) which looks very similar, the dialog disappears when you click somewhere outside of the dialog.
Actual:
The customization dialog stays open and in the foreground.
|
||
Comment 1•3 years ago
|
||
Yeah. I think it was set up like this in the implementation because otherwise the customization popup would loose focus and close when the color-picker was opened.
|
||
Comment 2•3 years ago
|
||
This is by design since platforms will open a color picker, therefore moving the focus away from the customize popup and closing it, which is very inconvenient and a horrible experience.
Pressing Esc will close that popup, but since during color customization many outside interactions are to be expected (OS color dialog, color picker from outside the app, etc), we decided to keep this open.
|
Reporter | |
Comment 3•3 years ago
•
|
||
I get the point, but what I think is confusing is the inconsistency between similar elements. So if you don't want to change the behaviour of that dialog for the above reasons, I guess the behaviour of the dialog that I described as "dialog for the area above the e-mails (the area with the buttons to reply, forward, archive, …)" should be changed (sorry, I don't know the official term for that). For me it does not really matter if the dialog stays open or not. But I expect the same behaviour of the same kinds of dialogs. What do you think about that, Alessandro?
|
|
||
Comment 4•3 years ago
|
||
I see your point, which specifically targets UX consistency and is intrinsically correct.
The problem is that the "incorrect" popup is the spaces toolbar one, which should close when registering an outside click, as all our popup panels behave the same. That's the "outsider" which unfortunately we can't control due to OS specific color pickers.
I wouldn't change all other popup panels because 1 has a forced inconsistency dictated by the OS.
This is also temporary, as we're moving away from XUL (which is the tech used for those panels) and implementing a pure HTML solution for those, which will allow us to better control its behavior and prevent closing when a color picker is opened from within itself.
Description
•