92481 - Crash while editing a selection that starts/ends in anonymous content - N621 [@ nsWSRunObject::GetWSNodes]

Status: VERIFIED WONTFIX

(Core :: DOM: Editor, defect, P1)

Description

[Yuying Long]

Build: 07-25 branch build on Win2k-CN, WinME-Ja, WinXP-Ja and Linux RH6.2-Ja
Not reproduce on: 07-25 Mac9.0-Ja

Steps to reproduce:
1. Launch browser, and go http://www.donga.com
2. Hightlight the parts of Stock and IT in the middle of the page.
3. Copy these parts to Composer - you will find the "Stock" is paste to the
right bottom of page.
4. Hightlight the "Stock" table - be sure hight the whole part.

Result:
Crash

Talcback ID: 
Win2k-CN: 33376076, 33375893, 33375808, 33375717, 333733949
WinME-Ja and WinXP-Ja: 33376586, 33376493
Linux: 33376527, 33376362

One of them:
------------------------------------------------------
Incident ID 33376076 
Stack Signature nsWSRunObject::GetWSNodes 2d41704a  
Bug ID  
Trigger Time  2001-07-26 13:46:57  
User Comments  4th crash  
Build ID 2001072506  
Product ID Netscape6.10  
Platform ID Win32  
Stack Trace  
nsWSRunObject::GetWSNodes
[d:\builds\seamonkey\mozilla\editor\base\nsWSRunObject.cpp, line 688] 
nsWSRunObject::nsWSRunObject
[d:\builds\seamonkey\mozilla\editor\base\nsWSRunObject.cpp, line 101] 
nsHTMLEditRules::AdjustWhitespace
[d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditRules.cpp, line 5438] 
nsHTMLEditRules::AfterEditInner
[d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditRules.cpp, line 400] 
nsHTMLEditRules::AfterEdit
[d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditRules.cpp, line 314] 
nsHTMLEditor::EndOperation
[d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditor.cpp, line 3571] 
nsPlaintextEditor::DeleteSelection
[d:\builds\seamonkey\mozilla\editor\base\nsPlaintextEditor.cpp, line 941] 
nsHTMLEditorLog::DeleteSelection
[d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditorLog.cpp, line 143] 
nsTextEditorKeyListener::KeyPress
[d:\builds\seamonkey\mozilla\editor\base\nsEditorEventListeners.cpp, line 243] 
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1598] 
nsDocument::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 2906] 
nsGenericElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsGenericElement.cpp, line 1696] 
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5569] 
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5496] 
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 377] 
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350] 
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350] 
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2056] 
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68] 
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 724] 
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 741] 
nsWindow::DispatchKeyEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2390] 
nsWindow::OnKeyDown
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2458] 
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp

Comment 1

[Yuying Long]

This is a regression: Not reproduce on N6.1PR1, seems it happened on soemtime
between 06-18(no crash) and 06-22(crash).

Comment 2

[rubydoo123]

asking Kin to debug

Comment 3

[Yuying Long]

Just in case, I forgot complete the comments in step 4 of original descrition:
4. Hightlight the "Stock" table - be sure highlight the whole part, then delete it.

Comment 4

[greer]

Adding topcrash keyword and the signature so that we can track this on the 
talkback reports.

Comment 5

[kinmoz]

FYI I'm having a hard time getting this to crash reliably so it's a bit tough to 
figure out what is going wrong.

ylong, can you get it to crash every time?

Comment 6

[Yuying Long]

Yes, I got this crash every time here - but please note, when I copied this file
to Composer, I always get the last 2 Korean characters reflow  to the bottom of
table, not like last time when I went to your cube, it not has been reflow. 

Comment 7

[Yuying Long]

Attachment: Attach html file of this page in case they will change it later

Comment 8

[kinmoz]

Attachment: Smaller test case.

Comment 9

[kinmoz]

Attachment: Even smaller test case.

Comment 10

[kinmoz]

Ok I figured out how to repro the crash with a smaller test case. To get the 
crash to happen, you must load the 08/01/01 19:22 attatchment in Composer, then 
hilite the text and the button in the table. The trick is that you have to get 
the text in the button to hilite too! Once everything is hilited, hitting delete 
will cause the crash.

Cc'ing mjudge, since the text inside the button should not be getting hilited.

We are crashing because we are setting the selection into the text node inside 
of the button. I believe this text node is anonymous content.

Comment 11

[kinmoz]

Attachment: Patch that prevents the crash. (Rev 1)

Comment 12

[kinmoz]

I just attatched a patch that reenables some code in 
nsFrame::GetContentAndOffsetsFromPoint() that was commented out by 
[e-mail] in nsFrame.cpp revision 3.232.

I talked to mjudge and he said he's not sure why he commented out.

Before checking in this patch, I need to do some performance impact analysis on 
selection in large flat documents, for example lxr document listings.

The code that I want to enable, prevents us from delving into a child frame 
who's content is not in the actual content tree ... a.k.a. anonymous content. 
This will prevent non-collapsed selections from spanning content in the content 
tree *and* content that is anonymous.

GetContentAndOffsetsFromPoint() is used to do a top down look through the frame 
tree to find the closest piece of content to a given point. You can trigger 
calls like this when selecting by clicking/dragging in the dead spot of a doc 
(where there is no content) ... in cases like that, the event system hands a 
point in a parent like <BODY> or <TD> and we have to drill down till we find 
what we think they were closest to. 

Comment 13

[kinmoz]

Hmmm I think reenabling this code breaks caret placement/snapping when clicking 
in dead spots within a text widget.

Comment 14

[Jay Patel [:jay]]

Adding N610 to summary, since this is a topcrash for Netscape 6.10.  This crash
is still around though, since there are quite a few crashes showing up on the
MozillaTrunk as well.  This would be a good crash to fix for the next release.

Comment 15

[kinmoz]

Moving to 0.9.6.

Changing summary from:

    Crash when try to delete a table that copied from browser - N610 [@
nsWSRunObject::GetWSNodes]

To:

    Crash while editing a selection that starts/ends in anonymous content - N610
[@ nsWSRunObject::GetWSNodes]

Comment 16

[kinmoz]

Yippee mjudge is back ... handing over to him.

Mike, this is that bug I was talking to you about earlier this week where 
selection is allowing one of it's endpoints to end in anonymous content. That 
should never happen and causes the editor grief.

Comment 17

[mjudge]

milestone

Comment 18

[Syd Logan]

plussing

Comment 19

[saari (gone)]

check out the patch, make sure it is still valid 

Comment 20

[greer]

Updating summary (N621 still shows this with 86 incidents in talkback) and 
keyword.

Comment 21

[mjudge]

the bug here is that for some reason NS_FRAME_GENERATED_CONTENT is not getting 
set on the frames that are being generated to make this anonymous content.  If 
that flag was set then it would not be necessary to "drill" up.  

I will check out when these frames are set up and if we can simply put a 
NS_FRAME_GENERATED_CONTENT flag on the frames.

Comment 22

[mjudge]

Well I wasted some of my time here.  This will be fixed. to test go to Prefs-
>Debug and select XBL controls.  notice that generated content is not 
selectable.  If the XBL controls wont be turned on then we must find a way to 
set the user-select flag to false on the content of the buttons and not the 
buttons themselves.  Marking as wontfix since the fix for 57209 will fix this.

Comment 23

[sujay]

v