236796 - Browser freezes/crashes on selecting text combined with xbl generated text

Status: RESOLVED FIXED

(Core :: XBL, defect, P1)

Description

[Martijn Wargers (dead)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040302 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040302 Firefox/0.8.0+

See upcoming testcase.
Select the text on the second line, starting somewhere in the string "binding
content".
When you reach the string "span inside div" the browser becomes unresponsive,
cpu time reaches 99%. Only thing left to do is to kill the browser.

Reproducible: Always
Steps to Reproduce:
1. See above.
2.
3.

Actual Results:  
Crash/freeze

Expected Results:  
Select the text

Comment 1

[Martijn Wargers (dead)]

Attachment: Select the text in order to get the freeze/crash

I've made the testcase more simple, so you can forget that part of above
comments.

Just select some of the anonymous node and some part of the 'real' node and you
will see the freeze/crash.

Comment 2

[Martijn Wargers (dead)]

Attachment: No crash because anonymous div ends before children-tag

This is almost the same as the crasher, but in this case the anonymous div ends
before the xbl:children tag.
In that case it does not freeze/crash.
Selecting of text in any of these testcases sucks by the way.

Comment 3

[Rene Pronk]

Confirming with Mozilla 1.7a and WinXP. It doesn't crash here but it does hang.
I get the following assertion many times in nsContentSubtreeIterator::Next()

http://lxr.mozilla.org/seamonkey/source/content/base/src/nsContentIterator.cpp#1522

1513   PRInt32 i = mEndNodes.IndexOf((void*)nextNode);
1514   while (i != -1)
1515   {
1516     // as long as we are finding ancestors of the endpoint of the range,
1517     // dive down into their children
1518     nsIContent *cChild = nextNode->GetChildAt(0);
1519     if (!cChild) {
1520       // XXX: Is this check necessary?
1521 
1522       NS_ERROR("Iterator error, expected a child node!");
1523 
1524       return;
1525     }
1526 
1527     // should be impossible to get a null pointer.  If we went all the 
1528     // down the child chain to the bottom without finding an interior node, 
1529     // then the previous node should have been the last, which was
1530     // was tested at top of routine.
1531     nextNode = cChild;
1532     i = mEndNodes.IndexOf(nextNode.get());
1533   }


pausing Mozilla gives the following stacktrace:

NTDLL! 77f75a58()
nsDebugImpl::Assertion(nsDebugImpl * const 0x002e6d38, const char * 0x015a2d18,
const char * 0x015a2d10, const char * 0x015a2cd0, int 1522) line 272
nsDebug::Assertion(const char * 0x015a2d18, const char * 0x015a2d10, const char
* 0x015a2cd0, int 1522) line 109
nsContentSubtreeIterator::Next() line 1522 + 26 bytes
nsTypedSelection::selectFrames(nsTypedSelection * const 0x02ecfb58,
nsIPresContext * 0x02d433e8, nsIDOMRange * 0x02ed76b8, int 1) line 5050
nsTypedSelection::Extend(nsTypedSelection * const 0x02ecfb58, nsIDOMNode *
0x02ee2164, int 2) line 6442
nsSelection::TakeFocus(nsSelection * const 0x02ecf880, nsIContent * 0x02ee2148,
unsigned int 2, unsigned int 2, int 1, int 0) line 2782
nsSelection::HandleClick(nsSelection * const 0x02ecf880, nsIContent *
0x02ee2148, unsigned int 2, unsigned int 2, int 1, int 0, int 0) line 2546 + 35
bytes
nsSelection::HandleDrag(nsSelection * const 0x02ecf880, nsIPresContext *
0x02d433e8, nsIFrame * 0x02ef32f0, nsPoint & {...}) line 2625 + 37 bytes
nsFrame::HandleDrag(nsFrame * const 0x02ef32f0, nsIPresContext * 0x02d433e8,
nsGUIEvent * 0x0012f73c, nsEventStatus * 0x0012f538) line 1807
nsFrame::HandleEvent(nsFrame * const 0x02ef32f0, nsIPresContext * 0x02d433e8,
nsGUIEvent * 0x0012f73c, nsEventStatus * 0x0012f538) line 974
PresShell::HandleEventInternal(nsEvent * 0x0012f73c, nsIView * 0x02ef3a78,
unsigned int 1, nsEventStatus * 0x0012f538) line 6133 + 33 bytes
PresShell::HandleEvent(PresShell * const 0x02ecd23c, nsIView * 0x02ef3a78,
nsGUIEvent * 0x0012f73c, nsEventStatus * 0x0012f538, int 1, int & 1) line 5981 +
25 bytes
nsViewManager::HandleEvent(nsView * 0x02ef3a78, nsGUIEvent * 0x0012f73c, int 1)
line 2275
nsViewManager::DispatchEvent(nsViewManager * const 0x02b4db88, nsGUIEvent *
0x0012f73c, nsEventStatus * 0x0012f630) line 2014 + 20 bytes
HandleEvent(nsGUIEvent * 0x0012f73c) line 79
nsWindow::DispatchEvent(nsWindow * const 0x02ef383c, nsGUIEvent * 0x0012f73c,
nsEventStatus & nsEventStatus_eIgnore) line 1064 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f73c) line 1085
nsWindow::DispatchMouseEvent(unsigned int 300, unsigned int 1, nsPoint *
0x00000000) line 5207 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 300, unsigned int 1, nsPoint *
0x00000000) line 5462
nsWindow::ProcessMessage(unsigned int 512, unsigned int 1, long 1310887, long *
0x0012fbe8) line 3981 + 28 bytes
nsWindow::WindowProc(HWND__ * 0x000f02ea, unsigned int 512, unsigned int 1, long
1310887) line 1346 + 27 bytes
USER32! 77d43a50()
USER32! 77d43b1f()
USER32! 77d43d79()
USER32! 77d43ddf()
nsAppShellService::Run(nsAppShellService * const 0x00a650b8) line 484
main1(int 1, char * * 0x002e2638, nsISupports * 0x00a04dd8) line 1291 + 32 bytes
main(int 1, char * * 0x002e2638) line 1678 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()

Comment 4

[Rene Pronk]

Hangs -> critical

Comment 5

[Boris Zbarsky [:bzbarsky]]

Probably the same as bug 236270

Comment 6

[Boris Zbarsky [:bzbarsky]]

Please retest this in tomorrow's build...

Comment 7

[Martijn Wargers (dead)]

Well, it seems like it's not fixed with the patch for bug 236270.

Using Gecko/20040305 Firefox/0.8.0+
--bug 236270 freeze/crash
Using Gecko/20040309 Firefox/0.8.0+
--bug 236270 works

Using Gecko/20040305 Firefox/0.8.0+
--this bug freeze/crash
Using Gecko/20040309 Firefox/0.8.0+
--this bug freeze/crash

Comment 8

[Boris Zbarsky [:bzbarsky]]

To jst.  I bet we used to return an error after that assert and that made
selection happy or something....  Now we need to set IsDone() and fix the damn
selection code to not be broken...

Better yet, we need to decide how to make anonymous content work with selection,
since clearly with XBL that's going to be happening.

Comment 9

[Johnny Stenback (:jst)]

Yeah, I bet you're right. Investigating.

Comment 10

[Johnny Stenback (:jst)]

Attachment: Mark the iterator done in this case too (until our selection code is fixed).

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 143540 [details] [diff] [review]
Mark the iterator done in this case too (until our selection code is fixed).

r+sr=bzbarsky, but there may not be a selection-side fix short of not using
content iterators, or using smarter ones that know about XBL anonymous
content...

Comment 12

[Johnny Stenback (:jst)]

Yup, that may very well be the answer, to make the iterators aware of anonymous
content. But that should be dealt with in othre bugs. Thanks for the reviews!

Comment 13

[Johnny Stenback (:jst)]

Comment on attachment 143540 [details] [diff] [review]
Mark the iterator done in this case too (until our selection code is fixed).

Requesting 1.7b approval, no need to have our beta lock up when selecting text
if the text happens to be anonymous content.

Comment 14

[chris hofmann]

Comment on attachment 143540 [details] [diff] [review]
Mark the iterator done in this case too (until our selection code is fixed).

a=chofmann for 1.7b

Comment 15

[Boris Zbarsky [:bzbarsky]]

Yeah, definitely.  I'm not suggesting we make radical changes to selection for
1.7.  ;)

Comment 16

[Johnny Stenback (:jst)]

Fix checked in.