[webkit-reviews] review granted: [Bug 47808] chrome.dll!WebCore::RangeBoundaryPoint::toPosition ReadAV at NULL (cf0d0f28bc56f2591cc74f71b46036ea) : [Attachment 75242] fixes the crash

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 1 11:09:13 PST 2010


Darin Adler <darin at apple.com> has granted Ryosuke Niwa <rniwa at webkit.org>'s
request for review:
Bug 47808: chrome.dll!WebCore::RangeBoundaryPoint::toPosition ReadAV at NULL
(cf0d0f28bc56f2591cc74f71b46036ea)
https://bugs.webkit.org/show_bug.cgi?id=47808

Attachment 75242: fixes the crash
https://bugs.webkit.org/attachment.cgi?id=75242&action=review

------- Additional Comments from Darin Adler <darin at apple.com>
View in context: https://bugs.webkit.org/attachment.cgi?id=75242&action=review

>>>> WebCore/editing/InsertListCommand.cpp:163
>>>> +			      return;
>>> 
>>> Do you think it is likely for this to regress again?  This check doesn't
seem to buy us much.
>> 
>> I'm sure there are other bugs in moveParagraph (which uses
DeleteSelectionCommand, ReplaceSelectionCommand, etc...) and
moveParagraphWithClones, and exiting early is better than crashing since a user
won't lose data.  Because the user can observe that not all paragraphs are
listified or unlistified, they should be able to report bugs if this assertion
hits.
> 
> Won't we only get bug reports for debug builds (and if someone decides to
file the bug)?	In the wild, we only get reports of the app crashes.  I'm
worried that this is papering over future bugs.

I think that “papering over” is OK in this case.


More information about the webkit-reviews mailing list