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.
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,
Severity: normal → minor
Status: UNCONFIRMED → NEW
Component: Mail Back End → Composition
Ever confirmed: true
@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.
(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.
Severity: minor → normal
Summary: Shift-Tab from first line of new message no longer jumps back to Subject line. → Shift-Tab from message body no longer shifts focus back to Subject
OK, agreed. Could someone please assign this bug?
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.
(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.
*** This bug has been marked as a duplicate of 300284 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
(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.
(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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.