WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
VERIFIED FIXED
8083
REGRESSION: Repro crash when dragging to select over a new text field
https://bugs.webkit.org/show_bug.cgi?id=8083
Summary
REGRESSION: Repro crash when dragging to select over a new text field
mitz
Reported
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
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
View All
Add attachment
proposed patch, testcase, etc.
mitz
Comment 1
2006-03-30 09:39:21 PST
Created
attachment 7396
[details]
Test case (crasher)
Justin Garcia
Comment 2
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.
Adele Peterson
Comment 3
2006-03-30 11:05:11 PST
Created
attachment 7398
[details]
patch
Adele Peterson
Comment 4
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?
Justin Garcia
Comment 5
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.
mitz
Comment 6
2006-03-31 01:07:30 PST
Verified in
r13594
nightly
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug