1112940 - Finetune click-to-focus behaviour for subject in compositions (increase pixels of clickable area which will set focus in subject)

Status: RESOLVED INVALID

(Thunderbird :: Message Compose Window, defect)

Description

[u314746]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141125180439

Steps to reproduce:

created a new mail
set the From field address
moved the cursor into the Subject field 
clicked to bring focus To subject


Actual results:

To field became highlighted


Expected results:

Expected Subject field to be the field of the focus.

This may not be the workflow that you usually follow but it's a valid one.  You have to move the cursor over ten pixels into the subject field (below the horizontal separator) before the subject will take the focus.  The pointer hot spot is well within the subject line and it still won't take focus over the To line which is 50+ pixels up.

This is with the new 31.3 version and is new behavior with the fields being visually grayed out.  Is there a way to disable this new functionality?

Comment 1

[Wayne Mery (:wsmwk)]

Does problem go away if you have Thunderbird started in safe mode?
https://support.mozilla.org/en-US/kb/safe-mode

Comment 2

[u314746]

Attachment: demonstration of issue

Comment 3

[u314746]

Started it up in safe mode and still get the same issue.  I've attached some screen shots while in safe mode.

Screen 1:  Very clearly within the boundaries of the "To:" field and click and "To:" doesn't take focus.

Screen 2:  Move a few pixels down and click, "To:" field has focus.

Screen 3:  Click in middle of "Subject:" field and it takes focus

Screen 4:  Move the pointer a few pixels up and I'm still well within the (user perceived) boundaries of the "Subject:" field.

Screen 5:  But when I click, the focus moves to "To:" Field  

Note:  the pointer has moved in the fifth picture as I bumped the mouse before screen capture but the behavior is repeatable.

Comment 4

[u314746]

Comment on attachment 8557142 [details]
demonstration of issue

Only half of this attachment is appearing for me.  If you can't see it, check here:

https://www.flickr.com/photos/127691229@N06/16403640551/

Comment 5

[Phoenix]

Is this still present in latest Thunderbird version?

Comment 6

[u314746]

Yes, still present

Comment 7

[Wayne Mery (:wsmwk)]

I see now what is happening. I don't think this is a bug, nor behavior that we should change,i.e. intended behavior. The mouse icon changing to an arrow clearly indicates you are no longer in the subject field.

invalid?

Comment 8

[u314746]

The mouse icon changing does indicate that you're in another field but the visual cues indicate that you in the subject field and that is where this is a bug.  The cursor behavior should match the user perception.

Comment 9

[Richard Marti (:Paenglab)]

Yes, invalid. With the arrow cursor, only the tip of it is the activation/deactivation point and outside the fields on screen 1 and screen 4 of your attachment. The body of the cursor does in any other program activate something, it's always the tip of this cursor. Maybe you need to change your cursor to a cross or something similar with the activation point in the center of the cursor (or edit the actual cursor to center this point).

Comment 10

[Thomas D. (:thomas8)]

Hmmm. This is certainly trivial and we might to chose to ignore/wontfix this, but I think our users have a point, i.e. this bug is valid. Please look at the unfocused recipient area (all grey). As comment 8 correctly points out, the visual impression is that the recipient area is divided by dark-grey lines into rectangular portions of equal size, and user has every reason to assume that these rectangular portions are identical with input/click target areas:

Portion 1: From top down to and including the first dark-grey line - From-field.
Portion 2: Between 1st line and and e.g. 3rd line - To-field.
Portion 3: Between 3rd line and 4th line - Subject-field.

The point being that the dark-grey lines separate the perceived input areas.
From that virgin state of the UI, it's very reasonable to assume that everything starting from the *first* row of pixels *below* any dark-grey line belongs to the *next* functional portion (or the next line for multi-line inputs like To).

The surprise comes four-fold:

1) Clicking up to 5 pixels *below* the last dark-grey line of To-field, i.e. clicking into what is clearly part of the perceived subject input area (portion 3), surprisingly does *not* focus the subject, but the to-field (whose actual input is might be more than one line away from current pointer position) - this bug.

2) So the adaptive user concludes that apparently there are some rows of pixels reserved *below* each dark-grey line which surprisingly still belong to the click target area of the line *above* (although it's very counter-intuitive to click *below* the line whilst you really want to write *above* of the line). So you can click below the line using arrow pointer (sic!), and to-field above will get focused. However, the same trick does *not* work for other fields (surprise #2): Trying to click even only 1 pixel below the dark-grey line of From-field does *not* focus subsequent To-field (or whichever flavor), but nothing.

3) Surprise #3: Enters Auto-BCC (between From and To), and the behaviour is different again:
a) _From_
b) _BCC__
c) _To___
d) ______
e) Subject
Now, clicking 1 pixel below From's dark grey line still does nothing.
But clicking just 1 pixel below *BCC* will focus subsequent To-field. To-field really always wins in every direction (technically it's not To-field, but depending on which control, and which row of that control we are in).

4) Not only are the margins below the line and the actual next input field different in behaviour, but they are also different in size:
- Margin between From and BCC is smallest
- Margin between BCC and To is 1 pixel bigger
- Margin between last line of To and Subject is 1 or two pixels bigger again.
You can easily see that when you hover and get the white background of hover state.

In an ideal pixel-perfect world, such surprises and inconsistencies should be avoided.
Clicking anywhere *below* a dark-grey line, even just one pixel, should obviously focus whichever input is *below*, i.e. that visual rectangular portion in which user has actually clicked - this bug.

That said, and knowing the nightmarish control structure of the header, we may not be willing or able to be pixel-perfect.
Which would render this bug wontfix, not invalid.

Just my 2 cents.

Comment 11

[Thomas D. (:thomas8)]

More inconsistencies:
- The "From:"-Label of From-field has a button-style hover effect (border and background color), indicating that you can click it to focus from-field - does anyone see that?
- However, label of Subject-field, in spite of being equally clickable, does *not* have that hover effect.
- With two or more recipients entered, clicking 1 or two pixels after the colon of any top recipient will surprisingly focus the *last* recipient, not the recipient at pointer position.
- However, clicking 1 or two pixels after the colon of From: or Subject: does nothing. Iow, similar to this bug (and iirc we might have another bug for that), there's a non-responsive spot between the colon of "Subject:" and the actual Subject input field. I.e. if you happen to miss the subject input by one pixel to the left, you don't win.

Which leads to the technical explanation of the whole mystery of this bug:
We're using some sort of tabular control, but only for the recipients. From and Subject are separate and different controls. Clicking anywhere within the recipients tabular control will focus that control, which defaults to focusing the first blank row of the recipient control.
On the other hand, From: and Subject: are label controls which are geographically and functionally distinct from their adjacent input fields.

Comment 12

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #10)

> 2) So the adaptive user concludes that apparently there are some rows of
> pixels reserved *below* each dark-grey line which surprisingly still belong
> to the click target area of the line *above* (although it's very
> counter-intuitive to click *below* the line whilst you really want to write
> *above* of the line). So you can click below the line using arrow pointer
> (sic!), and to-field above will get focused. However, the same trick does
> *not* work for other fields (surprise #2): Trying to click even only 1 pixel
> below the dark-grey line of From-field does *not* focus subsequent To-field
> (or whichever flavor), but nothing.

Logical Errata: Last sentence of 2) should read:

Trying to click even only 1 pixel below the dark-grey line of From-field does *not* focus *From-field* above (nor subsequent To-field, or whichever flavor), but nothing.

Comment 13

[Richard Marti (:Paenglab)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #11)
> More inconsistencies:
> - The "From:"-Label of From-field has a button-style hover effect (border
> and background color), indicating that you can click it to focus from-field

It was to enable the customize the from address. But it seems it works no more. Best would be to remove this functionality. Please can you file a bug?

Comment 14

[Thomas D. (:thomas8)]

Btw, this bug is a direct result of our design decision to let "modern" mono-flat design override good and useful traditional UI standard that input fields should be indicated (by borders and/or white background color) even in non-hovered state.

Comment 15

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #13)
> (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment
> #11)
> > More inconsistencies:
> > - The "From:"-Label of From-field has a button-style hover effect (border
> > and background color), indicating that you can click it to focus from-field
> 
> It was to enable the customize the from address. But it seems it works no
> more. Best would be to remove this functionality. Please can you file a bug?

Yes, I don't understand the original rationale of that buttonize-on-hover effect of From: label, and the effect should be removed, but not the accessor/focusing functionality of the associated label. It always works to shift the focus into from dropdown but the dotted focus indicator is initially missing both for clicking the button and clicking the input field. Only Alt+r surprisingly succeeds to create the dotted focus indicator, and after that, both clicks will correctly have the focus indication, too.