265582 - Shift-Tab from message body no longer shifts focus back to Subject

Status: VERIFIED DUPLICATE of bug 300284

(MailNews Core :: Composition, defect)

Description

[Ulf Dunkel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041019
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041019

When opening a new mail in the composer, I can jump the edit cursor from the To:
field to the Subject field and to the first message line by pressing [Tab].

But pressing [Shift][Tab] should also let the edit cursor jump back from the
first message line to the Subject field and to the recipients list (which worked
fine before).

This is even worse when replying on mails. I often have to edit the given
subject line and therefore am used to let the edit cursor jump upwards from the
first message line to the subject field by pressing [Shift][Tab].

Reproducible: Always
Steps to Reproduce:
See above in Details description.
Actual Results:  
Pressing [Shift][Tab] in the first message line has no effect.

Expected Results:  
The edit cursor should jump back to the Subject field.

Comment 1

[Mike Cowperthwaite]

Confirmed; reproduced with:
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041019

However, the problem only exists if the body is empty; if you type something, 
Shift-Tab now works.

The other workaround, of course, is just to use the mouse, 

Comment 2

[Ulf Dunkel]

@Mike:
This is not true. The problem exists even if the body has some content already.
I use to reply with auto-positioning the mouse cursor in the first line. When
replying to an email, the body is filled of course when you start replying.

Comment 3

[Mike Cowperthwaite]

(In reply to comment #2)
> @Mike:
> This is not true.

It is true!  It's just not completely accurate.

> The problem exists even if the body has some content already.
> I use to reply with auto-positioning the mouse cursor in the first line. When
> replying to an email, the body is filled of course when you start replying.

I didn't try the quoted-text cases, and you're right -- if there is some quoted 
text, things behave oddly.  In fact, if there is any text, things behave oddly:  
Shift-tab shifts the focus back to Subject only when the caret is on the end of 
a non-empty line.  With the caret on an empty line, or in the middle of any 
text, Shift-tab is ignored.

Incidentally, this is true for plain-text editing and for HTML editing.

Comment 4

[Ulf Dunkel]

OK, agreed. Could someone please assign this bug?

Comment 5

[Wayne Mery (:wsmwk)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041128
and Thunderbird version 0.6+ (20041115)

This bug is a dup of bug 178352

Current behavior is [shift] [tab] does work in subject, i.e. it jumps back to an
empty address field.

But when cursor is positioned on ANY line at the START of the line, then back
tab does not work to jump back to subject.

Comment 6

[Mike Cowperthwaite]

(In reply to comment #5)
> This bug is a dup of bug 178352

Actually not -- this symptom is easy to demonstrate, and does not occur in 
Moz 1.7, which came well after that bug was opened.  And that bug is about the 
Ctrl-Tab being ignored in the Subject, not the body.

Interesting that it's occurring in the TB trunk builds; it's not in the Aviary 
builds.

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

*** This bug has been marked as a duplicate of 300284 ***

Comment 8

[Ulf Dunkel]

(In reply to comment #7)
> 
> *** This bug has been marked as a duplicate of 300284 ***

This is always a funny treatment, as an older bug should never be a duplicate of
a younger one but just the other way round. So 300284 should rather be a
duplicate of this bug. But nevertheless, I saw that these bugs are fixed now.
Can't wait to test the new nightly.

Comment 9

[Jaime Mitchell (use [e-mail] for email)]

(In reply to comment #8)
> This is always a funny treatment, as an older bug should never be a duplicate of
> a younger one but just the other way round. 

Only if the bugs are equal, as the newer bug had the patch that fixes the
problem the dupe direction is correct.