Closed Bug 386872 Opened 17 years ago Closed 17 years ago

No cursor (caret) visible in mail compose window

Categories

(Core :: DOM: Editor, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: toscha, Unassigned)

References

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070408 Thunderbird/3.0a1pre ID:2007070408 When you write/reply a mail/posting no cursor (caret) is visible in the compose area. However, the cursor is there in the Subject: and To: fields. Reproducible: Always Steps to Reproduce: 1. Open new mail 2. Position 'unvisible' cursor in compose area (mouse or tab) 3. Start writing Actual Results: Characters appear, but no cursor is visible at writing position. Expected Results: Cursor should mark current writing position. Has been reported also for today's SeaMonkey trunk, both Windows and Linux.
(In reply to comment #0) > Has been reported also for today's SeaMonkey trunk, both Windows and Linux. Bug appears yesterday on SM. My first 'bad' SM-build was: 2007070310.
Version: unspecified → Trunk
Two data points: 1. In Linux it seems that this bug was introduced in the 6-28 build. In the 6-27 build the caret is present; in the 6-28 and subsequent builds it is not. 2. Ditto for the Firefox trunk: In 6-27 with caret browsing enabled, the caret is visible; beginning with the 6-28 build, it is not. I think this bug should, therefore, be reclassified to core and its description broadened to include Firefox. But I'll leave that to someone else -- or wait to see if anyone disagrees. :-)
Sounds like just-fixed bug 386820
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Are we sure this is a dup? Bug 386820 was reported fixed on 7/04, but the 20070705 builds still show this bug.
Cannot test builds after 20070705 because of bug 387111.
I believe the fact that "Edit Message as New" opens with a blank message is probably related to this.
Reopening. 20070715 trunk still shows the issue despite a fix for bug 386820.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: major → minor
This is still present in the 207090404 builds of Thunderbird Trunk. Although the behaviour is a bit different now: As soon as the mouse is physically clicked on some text (e. g. in a quoted message), the caret appears.
Comment 2 seems to suggest this was a regression of bug 237964, but I'm not completely sure that was tested with Thunderbird, though.
Martijn: The bug here originally was reported on Thunderbird, mentioning that it's also seen on SeaMonkey. It can easily be reproduced in SeaMonkey by opening a mail compose window and using only the tab key (no mouse) to focus the mail body area. After pressing tab a few times without seeing where the focus actually is, press some other keys and verify that you actually taped some tab characters into the mail body and the other characters appear after those - no caret visible though. It's like we'd use an invisible caret. Clicking into the area once brings up a visible caret there and it works fine. I guess that in Thunderbird the same steps work for reproducing this.
Ok, thanks, I can reproduce it indeed when pressing the tab key. Not when I focus the Compose Window with a mouse click.
Moving to a Core component where I can request the right blocking flags (and because I'm pretty sure this is a core bug). This has been driving me up the wall for weeks now. Peter, can you look into this, please? I've verified by local backout that this is a regression from bug 237964.
Severity: minor → normal
Component: Message Compose Window → Editor
Keywords: regression
Product: Thunderbird → Core
QA Contact: message-compose → editor
Flags: blocking1.9?
Need to check whether this will be fixed by my patch for bug 335856. It could very well be a different problem.
Depends on: 335856
That patch does seem to fix this bug.
Fixed by the fix for bug 335856.
Status: NEW → RESOLVED
Closed: 17 years ago17 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.