cursor disappears from compose window, this is bad on win32 / mac, since we cache the compose window

VERIFIED FIXED

Status

--
major
VERIFIED FIXED
16 years ago
10 years ago

People

(Reporter: sspitzer, Assigned: mozeditor)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [EDITORBASE] fixinhand; need r= ONELINER)

Attachments

(1 attachment, 1 obsolete attachment)

this happened to kerz last week, and now I see it every so often.

sometimes the cursor disappear from compose window, this is bad since we cache 
the compose window.

so even if you close, and do a new reply or new compose, we get the same bad 
window again.

varada, can you investigate?
Summary: cursor disappear from compose window, this is bad since we cache the compose window → cursor disappears from compose window, this is bad on win32 / mac, since we cache the compose window

Comment 1

16 years ago
Can you describe what happens before you see this problem(disappearance that
is)? Is this when you open a cached new window or reply or is it totally random?
I'm not 100% sure how to reproduce it.

it might happen when I have a compose window and I select all the text and
delete, and then click back to the addressing widget.

the cached compose window doesn't have anything to do with it (I don't think).

but it makes the problem worse, since with the cached compose window, you are
stuck with a bad window, until you quit the app.

cc bryner, maybe he's heard of this before.
OK, here's how I'm able to reproduce it, at least sometimes.

reply to a message, get the html compose window.
select all body text.
delete selected text.
delete a few more times.

cursor goes away.
ok, I can reproduce it, but it's a little tricky.

1) start up mail
2) reply
3) select all body text (using mouse)
4) delete selected text with delete key
5) hit delete a few more times, you'll get this once per delete when there is no
text:

###!!! ASSERTION: null args: 'aNode1 && aNode2 && aResult', file c:/builds/buffy
/mozilla/editor/libeditor/html/nsHTMLEditRules.cpp, line 7005

6) click in another window, like a dos prompt.
7) click back in the compose window.
8) hit delete again, curors disappears.

this might be a bug for jfrancis.

Comment 5

16 years ago
I saw this in Mac OS9 build for 0908, but not in 0910.
(Assignee)

Comment 6

16 years ago
snarfing.  can't look at it right away though.
Assignee: varada → jfrancis

Comment 7

16 years ago
I have experienced this bug in Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2a)
Gecko/20020905 simply by typing more than one line (i.e. some text,
hit return, some more text) in the compose window,
backspacing/deleting all the text and hitting backspace one more time. The cursor
disappears and no more text can be entered. If I try this with only a single line
of text (without a return), the bug does not occur.
raising priority.  I keep hitting this.
Severity: normal → major

Comment 9

16 years ago
Can someone change the "OS" filed to All please to give it more visibility,
since this is 100% reproduceable on Solaris, Linux. Still exists in todays
build 20020918 on Solaris and Linux.
 

Comment 10

16 years ago
Reproduced (well, seen it happen randomly) on Linux/x86, 20020916.
OS: Windows 2000 → All
Hardware: PC → All

Comment 11

16 years ago
*** Bug 169446 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
Easy way to reproduce is shown in the dup #169446
(Assignee)

Comment 13

16 years ago
Created attachment 100706 [details] [diff] [review]
patch to nsHTMLeditoRules.cpp

simple copy/paste spaz during deletion rewrite that went unnoticed...
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Whiteboard: [EDITORBASE] fixinhand; need r=,sr= ONELINER
(Assignee)

Comment 14

16 years ago
*** Bug 170405 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 15

16 years ago
*** Bug 170598 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 16

16 years ago
Created attachment 100716 [details] [diff] [review]
well, ok, two lines have to change
Attachment #100706 - Attachment is obsolete: true
(Assignee)

Comment 17

16 years ago
*** Bug 170606 has been marked as a duplicate of this bug. ***

Comment 18

16 years ago
Comment on attachment 100716 [details] [diff] [review]
well, ok, two lines have to change

doh!

sr=kin@netscape.com
Attachment #100716 - Flags: superreview+

Updated

16 years ago
Whiteboard: [EDITORBASE] fixinhand; need r=,sr= ONELINER → [EDITORBASE] fixinhand; need r= ONELINER

Comment 19

16 years ago
Comment on attachment 100716 [details] [diff] [review]
well, ok, two lines have to change

r=cmanske
Attachment #100716 - Flags: review+

Comment 20

16 years ago
I keep running into this on a daily basis.  Will this be landing any time soon?
(Assignee)

Comment 21

16 years ago
ooops, thought I had landed this a while ago.  Fixed on trunk now.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 22

16 years ago
tested with 20021028 winxp trunk build, 20021029 linux trunk build, 20021025
macOSX trunk build this is fixed. verified.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.