281299 - Dead zone at the left side of To:, Subject: and other edit boxes where clicking doesn't put cursor at front of line

Status: VERIFIED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Doug Hockin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

There's a dead zone at the left side of To: and Subject: where clicking doesn't
put cursor at front of line.  If you have text already in the field and want to
place the cursor at the very beginning, you can't click in the white space to
the left of the first character, as nothing happens -- the cursor stays where it is.
You have to click at the left side of the first char to get the cursor at the
beginning and that's hard if the first character is very narrow.  If you can't
click in that white zone before the first character, then it shouldn't be there.


Reproducible: Always

Steps to Reproduce:
1.  Put some text in the To: or Subject: field
2.  Try to get cursor at beginning by clicking in the white zone before first char.
3.

Actual Results:  
Cursor doesn't move.

Expected Results:  
Cursor should move to before first char.

Comment 1

[Mike Cowperthwaite]

This is true, altho the two fields are slightly different.

In the Subject field, the cursor changes to a text cursor when the mouse is 
positioned at the far right, but clicking at that point won't move the caret; 
this is the same problem as described in bug 178115.

In the addressing fields, the (worthless -- bug 181886) icon in the field is 
completely dead, but the cursor doesn't change to a text cursor until it's in 
the active zone.

There are similar issues in a message display's envelope, if you want to select 
header text; there is a big empty space between the header name and the header 
content, where you might like to be able to start the drag for text selection, 
but cannot.

The workarounds are either to select from the end to the beginning, or to use 
the keyboard after getting the focus into the field.  Or to be really patient 
when trying to select at the beginning of the field with the mouse.

Or, add something like this to userChrome.css:
 *|.textbox-input
 {
   padding-left: 1ex  !important;
 }

This will put a 1ex-wide gap to the left of the text where you can click and 
move the caret.  If 1ex is too wide, try maybe 6px or 2pt.

The change as described will change *all* the edit fields with class
 .textbox-input
If you want to restrict it to the fields in the compose window only, use:
 #addresses-box *|*.textbox-input {...}

Comment 2

[Aaron Lawrence]

For the envelope (header fields) I favour a more drastic approach: make the
whole thing a HTML area. Then the header can be freely selected and copied, as
needed. For instance, you can SEE the text name of an email, but you can only
COPY the actual address, because the email link is some kind of special control
not a real link. Grrr....
I don't recall if I ever submitted a bug for that.

Comment 3

[Wayne Mery (:wsmwk)]

still true

Comment 4

[Wayne Mery (:wsmwk)]

still true - easier to reproduce with address field, vs subject field

Comment 5

[Wayne Mery (:wsmwk)]

Still reproduces with To: field. But I'm not reproducing this with Subject field.
See comment 1

Comment 6

[Hartmut Welpmann [:welpy-cw]]

Attachment: Bug 281299 - Indicate text cursor in address container only where applicable. r=Paenglab

Comment 7

[Hartmut Welpmann [:welpy-cw]]

I think the different behavior of address and subject field is due to the former's ability to generate address pills. While my patch doesn't remove the "dead zone", at least the text cursor is only shown where it can actually used.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3cc5eb28c1c1
Indicate text cursor in address container only where applicable. r=Paenglab

Comment 9

[Wayne Mery (:wsmwk)]

Seems better. Thanks.