Closed Bug 167585 Opened 22 years ago Closed 22 years ago

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

Tracking

(Not tracked)

Status:

VERIFIED FIXED

People

(Reporter: sspitzer, Assigned: mozeditor)

References

Details

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

Attachments

(1 file, 1 obsolete file)

patch to nsHTMLeditoRules.cpp 22 years ago Joe Francis 826 bytes, patch		Details \| Diff \| Splinter Review
well, ok, two lines have to change 22 years ago Joe Francis 864 bytes, patch	cmanske : review+ kinmoz : superreview+	Details \| Diff \| Splinter Review

(not reading, please use seth@sspitzer.org instead)

Reporter

Description

•

22 years ago

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?

(not reading, please use seth@sspitzer.org instead)

Reporter

Updated

•

22 years ago

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

varada

Comment 1

•

22 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?

(not reading, please use seth@sspitzer.org instead)

Reporter

Comment 2

•

22 years ago

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.

(not reading, please use seth@sspitzer.org instead)

Reporter

Comment 3

•

22 years ago

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.

(not reading, please use seth@sspitzer.org instead)

Reporter

Comment 4

•

22 years ago

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.

hirata masakazu

Comment 5

•

22 years ago

I saw this in Mac OS9 build for 0908, but not in 0910.

Joe Francis

Assignee

Comment 6

•

22 years ago

snarfing. can't look at it right away though.

Assignee: varada → jfrancis

Brant Nelson

Comment 7

•

22 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.

(not reading, please use seth@sspitzer.org instead)

Reporter

Comment 8

•

22 years ago

raising priority. I keep hitting this.

Severity: normal → major

Mitch

Comment 9

•

22 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.

Calum Mackay