Closed
Bug 386872
Opened 17 years ago
Closed 17 years ago
No cursor (caret) visible in mail compose window
Categories
(Core :: DOM: Editor, defect)
Core
DOM: Editor
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.
Comment 1•17 years ago
|
||
(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.
Reporter | ||
Updated•17 years ago
|
Version: unspecified → Trunk
Comment 2•17 years ago
|
||
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. :-)
Comment 3•17 years ago
|
||
Sounds like just-fixed bug 386820
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Comment 4•17 years ago
|
||
Are we sure this is a dup? Bug 386820 was reported fixed on 7/04, but the 20070705 builds still show this bug.
Comment 5•17 years ago
|
||
Cannot test builds after 20070705 because of bug 387111.
Comment 6•17 years ago
|
||
I believe the fact that "Edit Message as New" opens with a blank message is probably related to this.
Comment 7•17 years ago
|
||
Reopening. 20070715 trunk still shows the issue despite a fix for bug 386820.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•17 years ago
|
Severity: major → minor
Comment 8•17 years ago
|
||
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 9•17 years ago
|
||
Comment 2 seems to suggest this was a regression of bug 237964, but I'm not completely sure that was tested with Thunderbird, though.
Blocks: contenteditable
Comment 10•17 years ago
|
||
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.
Comment 11•17 years ago
|
||
Ok, thanks, I can reproduce it indeed when pressing the tab key. Not when I focus the Compose Window with a mouse click.
Comment 12•17 years ago
|
||
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
Updated•17 years ago
|
Flags: blocking1.9?
Comment 13•17 years ago
|
||
Need to check whether this will be fixed by my patch for bug 335856. It could very well be a different problem.
Comment 14•17 years ago
|
||
That patch does seem to fix this bug.
Comment 15•17 years ago
|
||
Fixed by the fix for bug 335856.
Status: NEW → RESOLVED
Closed: 17 years ago → 17 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
Flags: blocking1.9+
You need to log in
before you can comment on or make changes to this bug.
Description
•