Bug 8083 - REGRESSION: Repro crash when dragging to select over a new text field
Summary: REGRESSION: Repro crash when dragging to select over a new text field
Status: VERIFIED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P1 Normal
Assignee: Nobody
URL:
Keywords: Regression
Depends on:
Blocks:
 
Reported: 2006-03-30 09:38 PST by mitz
Modified: 2006-03-31 01:07 PST (History)
2 users (show)

See Also:


Attachments
Test case (crasher) (96 bytes, text/html)
2006-03-30 09:39 PST, mitz
no flags Details
patch (1.22 KB, patch)
2006-03-30 11:05 PST, Adele Peterson
justin.garcia: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2006-03-30 09:38:48 PST
TOT crashes when dragging to make a selection that contains a new text field. Backtrace:

Thread 0 Crashed:
0   com.apple.WebCore              	0x01adb554 WebCore::Node::rootEditableElement() const + 36 (Node.cpp:1043)
1   com.apple.WebCore              	0x01a7bce8 WebCore::Selection::adjustForEditableContent() + 688 (Selection.cpp:323)
2   com.apple.WebCore              	0x01a7ce0c WebCore::Selection::validate() + 3684 (Selection.cpp:264)
3   com.apple.WebCore              	0x01a7d158 WebCore::Selection::Selection[in-charge](WebCore::Position const&, WebCore::Position const&, WebCore::EAffinity) + 160 (Selection.cpp:65)
4   com.apple.WebCore              	0x01a80890 WebCore::SelectionController::setExtent(WebCore::VisiblePosition const&) + 100 (SelectionController.cpp:653)
5   com.apple.WebCore              	0x018c8200 WebCore::Frame::handleMouseMoveEventPart2(WebCore::MouseEventWithHitTestResults const&) + 560 (Frame.cpp:1856)
6   com.apple.WebCore              	0x018c82b8 WebCore::Frame::handleMouseMoveEvent(WebCore::MouseEventWithHitTestResults const&) + 40 (Frame.cpp:1866)
7   com.apple.WebCore              	0x018dbdb8 WebCore::FrameMac::handleMouseMoveEvent(WebCore::MouseEventWithHitTestResults const&) + 3372 (FrameMac.mm:1726)
8   com.apple.WebCore              	0x018edcf4 WebCore::FrameView::handleMouseMoveEvent(WebCore::PlatformMouseEvent const&) + 876 (FrameView.cpp:636)
9   com.apple.WebCore              	0x018d6ec8 WebCore::FrameMac::mouseDragged(NSEvent*) + 388 (FrameMac.mm:1958)
10  com.apple.WebCore              	0x019085e8 -[WebCoreFrameBridge mouseDragged:] + 52 (WebCoreFrameBridge.mm:1050)
11  com.apple.WebKit               	0x0037d66c -[WebHTMLView mouseDragged:] + 288 (WebHTMLView.m:2725)
12  com.apple.AppKit               	0x9377c5c0 -[NSWindow sendEvent:] + 6424
13  com.apple.Safari               	0x00021d24 0x1000 + 134436
14  com.apple.AppKit               	0x93724ef4 -[NSApplication sendEvent:] + 4172
15  com.apple.Safari               	0x00021828 0x1000 + 133160
16  com.apple.AppKit               	0x9371c330 -[NSApplication run] + 508
17  com.apple.AppKit               	0x9380ce68 NSApplicationMain + 452
18  com.apple.Safari               	0x0005cbec 0x1000 + 375788
19  com.apple.Safari               	0x0005ca94 0x1000 + 375444
Comment 1 mitz 2006-03-30 09:39:21 PST
Created attachment 7396 [details]
Test case (crasher)
Comment 2 Justin Garcia 2006-03-30 10:38:06 PST
I'm guess: adjustForEditableContent finds that the extent is in a different root editable element than the base (the extent is inside a textfield and the base is not), then it tries to climb out of the the extent root in order to change the extent to the first visible position after the extent root.  But it can't climb out of extent root because it's a shadow node.
Comment 3 Adele Peterson 2006-03-30 11:05:11 PST
Created attachment 7398 [details]
patch
Comment 4 Adele Peterson 2006-03-30 11:08:02 PST
Comment on attachment 7398 [details]
patch

Justin - do we need to worry about this for the base node?
Comment 5 Justin Garcia 2006-03-30 11:55:25 PST
Comment on attachment 7398 [details]
patch

adele & i talked about this and she's going to add a similar piece of code for the case where the selection starts in editable content.  we also talked about how we this fix doesn't work if an editable shadow node was inside another editable shadow node.  she could just put this adjustment inside the do {} loop and both cases would be fixed.
Comment 6 mitz 2006-03-31 01:07:30 PST
Verified in r13594 nightly