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?
16 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
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.
I saw this in Mac OS9 build for 0908, but not in 0910.
snarfing. can't look at it right away though.
Assignee: varada → jfrancis
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
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.
Reproduced (well, seen it happen randomly) on Linux/x86, 20020916.
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 169446 has been marked as a duplicate of this bug. ***
Easy way to reproduce is shown in the dup #169446
Created attachment 100706 [details] [diff] [review] patch to nsHTMLeditoRules.cpp simple copy/paste spaz during deletion rewrite that went unnoticed...
Status: NEW → ASSIGNED
Whiteboard: [EDITORBASE] fixinhand; need r=,sr= ONELINER
*** Bug 170405 has been marked as a duplicate of this bug. ***
*** Bug 170598 has been marked as a duplicate of this bug. ***
Created attachment 100716 [details] [diff] [review] well, ok, two lines have to change
Attachment #100706 - Attachment is obsolete: true
*** Bug 170606 has been marked as a duplicate of this bug. ***
Comment on attachment 100716 [details] [diff] [review] well, ok, two lines have to change doh! firstname.lastname@example.org
Attachment #100716 - Flags: superreview+
Whiteboard: [EDITORBASE] fixinhand; need r=,sr= ONELINER → [EDITORBASE] fixinhand; need r= ONELINER
Comment on attachment 100716 [details] [diff] [review] well, ok, two lines have to change r=cmanske
Attachment #100716 - Flags: review+
I keep running into this on a daily basis. Will this be landing any time soon?
ooops, thought I had landed this a while ago. Fixed on trunk now.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
tested with 20021028 winxp trunk build, 20021029 linux trunk build, 20021025 macOSX trunk build this is fixed. verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.