Closed Bug 1659343 Opened 4 years ago Closed 4 years ago

Subsequent password dialogs don't keep Cancel button in exactly same horizontal position by some px although buttons look centered

Categories

(Thunderbird :: Mail Window Front End, defect)

Thunderbird 81
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: psnmbox, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

Configuration with two accounts on the same mail server, both require authentication but passwords not stored.
After launch the first password entry dialog appears.
Do not enter anything, but prepare mouse to press Cancel.

Actual results:

To see the issue cleary, place mouse cursor at the upper right corner of the Cancel button.
Mouse left click will close the dialog, and the dialog for the second account appears, but this time the right side of Cancel button was about 10 pixels to the left from the mouse cursor.

Expected results:

It might be expected that dialogs keep on-screen position - centered, maybe.
Otherwise it looks odd and somewhat incovenient when button jumps away from the mouse cursor.

Whilst it's true that the buttons are not centered pixel-perfect as comparing screenshots of password dialogs from two similar accounts has shown (pop/imap for same account, maybe 5px off horizontally in my test), I don't think we're going to invest developer time to polish this.
It's much more likely that user will be moving his mouse by some px in between clicks than misclicking because of an rather unfounded expectation that two sequential dialogs must look exactly the same to the very pixel.
Unless of course if you're coding robots to do the clicks for you...

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Component: Untriaged → Mail Window Front End
Resolution: --- → WONTFIX
Summary: Password dialogs shifts left on Cancel → Subsequent password dialogs don't keep Cancel button in exactly same horizontal position by some px although buttons look centered

Doubtful, that a textbook task of centering a dialog within screen or owner window, should require anything that could be called with a big word "development" (here could be a link to MSDN article with an example code).
In my opinion, professionally designed software should not feature strangely jumping dialogs in its GUI.

I took a second look at the dialog, and got an idea of explanation.
Presumably the dialog width changes according to account string length, but placement is calculated only once, for the first dialog.
In that case, next dialogs may be off-center.

You need to log in before you can comment on or make changes to this bug.