WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
53008
chrome.dll!WebCore::ApplyStyleCommand::applyInlineStyle ReadAV@NULL (087acf9f68b5cba71094dae9370bdc92)
https://bugs.webkit.org/show_bug.cgi?id=53008
Summary
chrome.dll!WebCore::ApplyStyleCommand::applyInlineStyle ReadAV@NULL (087acf9f...
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.
Top of Page
Format For Printing
XML
Clone This Bug