Bug 53008

Summary: chrome.dll!WebCore::ApplyStyleCommand::applyInlineStyle ReadAV@NULL (087acf9f68b5cba71094dae9370bdc92)
Product: WebKit Reporter: Berend-Jan Wever <skylined>
Component: HTML EditingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED CONFIGURATION CHANGED    
Severity: Normal CC: ahmad.saleem792, ap, bfulgham, rniwa
Priority: P1    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Windows Vista   
Attachments:
Description Flags
Repro none

Berend-Jan Wever
Reported 2011-01-24 07:12:26 PST
Created attachment 79921 [details] Repro Chromium: http://code.google.com/p/chromium/issues/detail?id=70605 Repro: <body onload=" document.execCommand('SelectAll'); document.designMode='on'; document.execCommand('underline'); document.execCommand('Bold'); "><svg><text>x This code hits ApplyStyleCommand::applyInlineStyle twice. The second time it does so, splitEnd is true in: bool splitEnd = isValidCaretPositionInTextNode(end); if (splitEnd) { if (shouldSplitTextElement(end.node()->parentElement(), style)) splitTextElementAtEnd(start, end); else splitTextAtEnd(start, end); start = startPosition(); end = endPosition(); endDummySpanAncestor = dummySpanAncestorForNode(end.node()); } After this code runs, start.isNull() is true. This causes a NULL pointer in an inline function later on. Adding the below check after the above code fixes this issue: if (start.isNull()) return; However, I don't understand the code well enough to determine if this is a proper fix for this issue, or if the problems is more fundamental.
Attachments
Repro (164 bytes, text/html)
2011-01-24 07:12 PST, Berend-Jan Wever 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1 2011-01-24 09:00:39 PST
The problem is that when the second call to splitTextEnd calls updateStartEnd, it sets the ending selection but start and end becomes null for whatever reason. This is probably a bug in VisiblePosition::canonicalPosition. Namely, next and prev are both null but they shouldn't be because the position is at ["x", 0] as in: BODY 0x1160e83d0 svg 0x1160f79e0 text 0x1166078a0 U 0x116d78410 * #text 0x116671bb0 "x" #text 0x116607d20 "\n" and this should clearly a valid candidate.
Ahmad Saleem
Comment 2 2022-07-20 16:44:51 PDT
I think following check as per Description is now added: https://github.com/WebKit/WebKit/blob/50d7e0b0b808afca93e5ede9cd7c0d44b1ed8130/Source/WebCore/editing/ApplyStyleCommand.cpp#L345 Although Code is not matching 1:1 but I think it is now present and the crash is not reproducible when opening "repo" on Safari 15.6 on macOS 12.5. I think this can be considered as "RESOLVED CONFIGURATION CHANGED"? Thanks!
Note You need to log in before you can comment on or make changes to this bug.