Closed Bug 52150 Opened 25 years ago Closed 25 years ago

Mail, IM, and Composer Composition: Caret not present

Categories

(MailNews Core :: Composition, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: kmurray1115, Assigned: sfraser_bugs)

References

Details

(Keywords: regression, Whiteboard: [nsbeta3++] [pdtp1])

Attachments

(2 files)

Build ID: 2000091108 1. Start Netscape 6 2. Start Netscape Mail 3. Press "New Message" 4. Enter addressee(s) 5. Enter Subject 6. In body, look for cursor 7. No cursor, blinking or otherwise Expected results: Cursor should exist to show placeholder when typing text.
I was about to file a new bug on this one... I see this all the time. Nominating for nsbeta3, coz most of the users may not know where he/she is typing. Particularly users who make lot of typos and it will be a pain for them to go back and correct charecters/words without knowing the current position of the cursor.
Keywords: nsbeta3
isn't this the recent bug 51747 (marked fixed on the 7th)
Suresh, how do you pass from the subject to the body? Click, tab or enter?
I used the mouse and clicked on the body to start typing.
Looks like a focus problem, reassign to editor team, cc'ing saari
Assignee: ducarroz → beppe
this belongs to Simon
Assignee: beppe → sfraser
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
Works okay when using the mouse, but tabbing will produce a cursor in the body, which then promptly disappears a moment later. This one is new to me.
kin, sfraser debugged, it seems to be a focus issue, assigning to saari, cc trudelle. saari sfraser can help explain the underlying issue
Assignee: sfraser → saari
Whiteboard: [nsbeta3+]
nsbeta3+, p2 for M18
Priority: P3 → P2
Whiteboard: [nsbeta3+]
This is probably a dup of 51837.
*** Bug 51837 has been marked as a duplicate of this bug. ***
It looks like this is a Composer related issue. For example, open up Composer and just start into typing. No cursor visible. Now switch to some other app other than Mozilla, then come back. Cursor visible! Similar symptoms with mail composition as well.
note: simon has a good test case to see the problem in his comments in the duplicate bug reported.
Keywords: mailtrack
Summary: Mail Composistion: Cursor not present → Mail Composition: Cursor not present
Fixed the mail weirdness, a JS typo. Composer seems to be something else.
Status: NEW → ASSIGNED
Pretty much fixed I think...
Should we resolve as such, or nsbeta3-/future, ...? What problems remain?
Whiteboard: [nsbeta3+] → [nsbeta3+] fixed?
The original bug with mail compose is fixed. I thought that the editor cursor issue was fixed (it worked on hyatt's machine last night) but doesn't appear to be fixed with my windows build. I'm also looking at why the fixes for xul text fields didn't work fully on the mac, and why initial focus on new windows is broken on mac.
*** Bug 53050 has been marked as a duplicate of this bug. ***
*** Bug 53086 has been marked as a duplicate of this bug. ***
Mail Compose bug not fixed using 2000091805 build.
Whiteboard: [nsbeta3+] fixed? → [nsbeta3+] not fixed yet!
Pdt believes that this should be a P1. Resetting priority.
Priority: P2 → P1
Whiteboard: [nsbeta3+] not fixed yet! → [nsbeta3+] not fixed yet![pdtp1]
*** Bug 53110 has been marked as a duplicate of this bug. ***
Mail compose works fine on windows. Which bug are you talking about?
when you open a new IM, mail or composer window, the caret is not present/rendered. I am able to get it to render if I lose focus in the window and then regain focus. I can dup this easily on win98. I will try on mac and linux
it's a caret, not a cursor.
Summary: Mail Composition: Cursor not present → Mail Composition: Caret not present
My win2k build works fine today. I'll look at a 98 machine.
Okay, in editor there is still a problem on Windows and linux with the initial focus. Working on it...
Keywords: regression
tossing to simon to check for focus on editor init
Assignee: saari → sfraser
Status: ASSIGNED → NEW
Beth - Can you change this bug summary to reflect that the issue is not only with Mail, but with IM and Composer. You just do not see a caret when you open up a new email message, a new IM message, or a new blank document.
I know how to fix this. Fairly simple change
Status: NEW → ASSIGNED
*** Bug 53467 has been marked as a duplicate of this bug. ***
*** Bug 53491 has been marked as a duplicate of this bug. ***
*** Bug 53592 has been marked as a duplicate of this bug. ***
*** Bug 53544 has been marked as a duplicate of this bug. ***
*** Bug 53535 has been marked as a duplicate of this bug. ***
Platforms/OS: All I see this on Mac
OS: Windows NT → All
Hardware: PC → All
*** Bug 53770 has been marked as a duplicate of this bug. ***
This is Peter's
QA Contact: esther → pmock
Summary: Mail Composition: Caret not present → Mail, IM, and Composer Composition: Caret not present
Two parts to the patch: nsEditorShell.cpp needs some code in PrepareDocumentForEditing() to make the caret visible if the editor's content window is already focussed; this is necessary because we can't rely on a focus event coming after this time. hyatt/ saari recommended this change. nsWebShellWindow.cpp The nsEditorShell changes were not sufficient, on Mac at least, because, when loading a blank page, we'd get into PrepareDocumentForEditing(), set up the caret etc, only to get a later Blur() event as a side-effect of the window activate handling code. This was a significant part of the bug; there could be ordering problems such that editor setput would happen *before* the window activate event was handled, with the result that focus is snatched away from the editor, and given to the top-level XUL document. This patch ensures that this focus change is not "remembered". saari will test the nsWebShellWindow patch across platforms.
Assignee: sfraser → saari
Status: ASSIGNED → NEW
Marking nsbeta3++ with a note that this patch still needs reviewing. Please get this done as soon as possible so that we don't risk slipping PR3.
Whiteboard: [nsbeta3+] not fixed yet![pdtp1] → [nsbeta3++] not fixed yet![pdtp1]
Simon's patch fixes the problem for me on Linux.
I just did thorough testing with kin on linux, and things look good.
I checked the nsWebShellWindow.cpp change out on all platforms, and it looks to be golden. Tossing back to simon for final review/approval mojo.
Assignee: saari → sfraser
Fix checked in, trunk and branch.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
*** Bug 54368 has been marked as a duplicate of this bug. ***
*** Bug 54591 has been marked as a duplicate of this bug. ***
Verified as fixed on branched builds of win32, linux, and macos using the following builds: win32 commercial seamonkey build 2000-092809-mn6 installed on P500 Win98 linux commercial seamonkey build 2000-092810-mn6 installed on P200 RedHat 6.2 macos commercial seamonkey build 2000-092812-mn6 installed on G3/400 OS 9.04 Caret is present in Mail (plain text & html editor), page composer, and instant messenger. The caret displays correctly when switching between windows. Great work Simon! :)
Whiteboard: [nsbeta3++] not fixed yet![pdtp1] → [nsbeta3++] [pdtp1] vtrunk
per mtg with asa, wait until trunk builds are verified also before marking this bug verified.
Keywords: vtrunk
Whiteboard: [nsbeta3++] [pdtp1] vtrunk → [nsbeta3++] [pdtp1]
Verified Fixed in win32 Mozilla Trunk build 2000100204 on NT, linux Mozilla Trunk build 2000100208 on RedHat6.2 and Mac Mozilla Trunk build 2000100208 on OS9. Caret is present anc accounted for in Message Compose as well as page Composer. Setting bug status to Verified and removing the vtrunk keyword.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: