WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 15942
REGRESSION: Selecting "Edit Html" tab in Blogger causes crash (Assertion failed: isRange())
https://bugs.webkit.org/show_bug.cgi?id=15942
Summary
REGRESSION: Selecting "Edit Html" tab in Blogger causes crash (Assertion fail...
Jubal Kessler
Reported
2007-11-11 07:51:01 PST
Version: WebKit-SVN-
r27663
This bug crashes WebKit and Safari, and appears to be reproducible. Not entirely sure which component this one falls into. I put 'forms' for now; please change if that's incorrect. In Blogger, in both vanilla Safari 3.0.3 and WebKit build
r27663
(2007-11-10), if I "edit" a blog post (edit = click on pencil icon, which puts me into a forms view wherein I can select whizzy-wig editing or raw HTML editing), I find that I am unable to select any other view excep the default, which is whizzy-wig. (whizzy-wig = WYSIWYG = What You See is What You Get. Sorry if everyone reading this bug knows what it means; I assume absolutely nothing about my audience.) Please see the attached screenshot. In the screenshot, one can see two tabs on the upper right-hand side of the text-entry area. As I mentioned, the default editing mode is whizzy-wig, but the "Edit Html" tab is focused -- and this is incorrect. The linked/underlined "Compose" tab is the active mode and should be focused. Now, I wish to edit the HTML code for this blog entry, and I click on "Edit Html" tab. This action causes the browser to die/go away/crash. (I will repeat the action after filing this bug, and formally send the crash report that way.) There are two "bad" consequences of this bug: 1. I cannot edit Blogger posts in HTML mode using Safari/WebKit. 2. Attempting to edit causes Safari/WebKit to die. I didn't find any related bugs for WebKit, and I have no access to Radar. How to reproduce: 1. Use an existing Blogger account at blogger.com, or create a new account. 2. Choose the "Simple II" template. (This step may not matter because this bug report is about Blogger in _editing_ mode, and I don't know if the template matters in this view.) 3. Create a new blog post. 4. Type in some text. 5. Click the "Edit Html" tab.
Attachments
Screenshot of affected Blogger edit mode
(103.63 KB, image/png)
2007-11-11 07:51 PST
,
Jubal Kessler
no flags
Details
crash report for this bug
(25.40 KB, text/plain)
2007-11-11 08:00 PST
,
Jubal Kessler
no flags
Details
Reduction
(631 bytes, text/html)
2007-11-11 14:13 PST
,
mitz
no flags
Details
Check if the selection has been cleared by layout
(3.48 KB, patch)
2007-11-11 17:04 PST
,
mitz
aroben
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Jubal Kessler
Comment 1
2007-11-11 07:51:41 PST
Created
attachment 17185
[details]
Screenshot of affected Blogger edit mode
Jubal Kessler
Comment 2
2007-11-11 08:00:51 PST
Created
attachment 17186
[details]
crash report for this bug Crash report after (1) typing in multi-line text, then (2) clicking "Edit Html" tab. I believe (1) is necessary to wrap the text in HTML tags, which seems to induce the crash after (2). If only a single line of unstyled text is typed in, no HTML tags are applied, and the crash does _not_ happen.
Jubal Kessler
Comment 3
2007-11-11 08:14:39 PST
Also, I am: - running a MacBook rev 1 (Intel) - running Mac OS X 10.4.10 I was formerly running SafariStand until a few days ago. I'd removed it by deleting the "SafariStand" folders inside ~/Library/InputManagers and ~/Library/Safari, then logging out and back in. This was before I installed this WebKit nightly. I don't think it's related, but in the interests of full disclosure, there it is. Good luck. :-)
Jubal Kessler
Comment 4
2007-11-11 08:27:20 PST
Sorry for the multiple revisions to this bug. I've just realized that in Safari/WebKit, Blogger defauls to HTML-editing mode. This is a bug; I believe the default editing mode should be rich text, and I can confirm this behavior in Firefox. What is _not_ a bug:the "Edit Html" tab is correctly focused because HTML-editing mode is, in fact, active. I have changed the Subject line to reflect this. The crash is still there, and happens according to the reproduction steps I'd mentioned earlier. _Please_ inform me if these steps cannot be reproduced on your end to effect a crash. So: bug #1: Blogger defaults to the wrong editing mode when creating a new post, or editing an existing one bug #2: Blogger crashes, see previous entries in this bug report.
Jubal Kessler
Comment 5
2007-11-11 08:31:29 PST
Last revision of the day. This bug does _not_ affect Safari 3.0.3.
Matt Lilek
Comment 6
2007-11-11 09:23:02 PST
Confirmed with
r27668
. When I go into blogger and edit a post, clicking the "Edit HTML" tab hits the assertion failure below. Bumping to P1 since it crashes in release builds and is a regression from Safari 3.0.4 on Leopard. ASSERTION FAILED: isRange() (/WebKit/WebCore/editing/Selection.cpp:151 WTF::PassRefPtr<WebCore::Range> WebCore::Selection::toRange() const) Thread 0 Crashed: 0 com.apple.WebCore 0x023261bb WebCore::Selection::toRange() const + 297 (Selection.cpp:151) 1 com.apple.WebCore 0x01e6fe5d WebCore::enclosingDeletableElement(WebCore::Selection const&) + 61 (DeleteButtonController.cpp:104) 2 com.apple.WebCore 0x01e7111b WebCore::DeleteButtonController::enable() + 145 (DeleteButtonController.cpp:284) 3 com.apple.WebCore 0x023d3a24 WebCore::createMarkup(WebCore::Node const*, WebCore::EChildrenOnly, WTF::Vector<WebCore::Node*, 0ul>*) + 252 (markup.cpp:922) 4 com.apple.WebCore 0x01f2e2b1 WebCore::HTMLElement::innerHTML() const + 43 (HTMLElement.cpp:223) 5 com.apple.WebCore 0x0202263c WebCore::JSHTMLElement::getValueProperty(KJS::ExecState*, int) const + 672 (JSHTMLElement.cpp:183) 6 com.apple.WebCore 0x02023032 KJS::JSValue* KJS::staticValueGetter<WebCore::JSHTMLElement>(KJS::ExecState*, KJS::JSObject*, KJS::Identifier const&, KJS::PropertySlot const&) + 62 (lookup.h:152) 7 com.apple.JavaScriptCore 0x00459a52 KJS::PropertySlot::getValue(KJS::ExecState*, KJS::JSObject*, KJS::Identifier const&) const + 132 (property_slot.h:49) 8 com.apple.JavaScriptCore 0x0040c7fc KJS::JSObject::get(KJS::ExecState*, KJS::Identifier const&) const + 74 (object.cpp:163) 9 com.apple.JavaScriptCore 0x0043c2c1 KJS::DotAccessorNode::evaluate(KJS::ExecState*) + 127 (nodes.cpp:683) 10 com.apple.JavaScriptCore 0x00439248 KJS::AssignDotNode::evaluate(KJS::ExecState*) + 136 (nodes.cpp:2706) 11 com.apple.JavaScriptCore 0x00438723 KJS::ExprStatementNode::execute(KJS::ExecState*) + 133 (nodes.cpp:3101) 12 com.apple.JavaScriptCore 0x004194c6 KJS::statementListExecute(WTF::Vector<WTF::RefPtr<KJS::StatementNode>, 0ul>&, KJS::ExecState*) + 108 (nodes.cpp:3036) 13 com.apple.JavaScriptCore 0x0041961e KJS::BlockNode::execute(KJS::ExecState*) + 92 (nodes.cpp:3077) 14 com.apple.JavaScriptCore 0x004358ab KJS::FunctionBodyNode::execute(KJS::ExecState*) + 47 (nodes.cpp:3969) 15 com.apple.JavaScriptCore 0x0040c72a KJS::FunctionImp::execute(KJS::ExecState*) + 38 (function.cpp:252) 16 com.apple.JavaScriptCore 0x0043f694 KJS::FunctionImp::callAsFunction(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 384 (function.cpp:93) 17 com.apple.JavaScriptCore 0x0042a1bc KJS::JSObject::call(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 222 (object.cpp:95) 18 com.apple.JavaScriptCore 0x00449233 KJS::FunctionCallResolveNode::evaluate(KJS::ExecState*) + 661 (nodes.cpp:834) 19 com.apple.JavaScriptCore 0x00437370 KJS::ReturnNode::execute(KJS::ExecState*) + 268 (nodes.cpp:3489) 20 com.apple.JavaScriptCore 0x004194c6 KJS::statementListExecute(WTF::Vector<WTF::RefPtr<KJS::StatementNode>, 0ul>&, KJS::ExecState*) + 108 (nodes.cpp:3036) 21 com.apple.JavaScriptCore 0x0041961e KJS::BlockNode::execute(KJS::ExecState*) + 92 (nodes.cpp:3077) 22 com.apple.JavaScriptCore 0x004358ab KJS::FunctionBodyNode::execute(KJS::ExecState*) + 47 (nodes.cpp:3969) 23 com.apple.JavaScriptCore 0x0040c72a KJS::FunctionImp::execute(KJS::ExecState*) + 38 (function.cpp:252) 24 com.apple.JavaScriptCore 0x0043f694 KJS::FunctionImp::callAsFunction(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 384 (function.cpp:93) 25 com.apple.JavaScriptCore 0x0042a1bc KJS::JSObject::call(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 222 (object.cpp:95) 26 com.apple.JavaScriptCore 0x00449233 KJS::FunctionCallResolveNode::evaluate(KJS::ExecState*) + 661 (nodes.cpp:834) 27 com.apple.JavaScriptCore 0x00439248 KJS::AssignDotNode::evaluate(KJS::ExecState*) + 136 (nodes.cpp:2706) 28 com.apple.JavaScriptCore 0x00438723 KJS::ExprStatementNode::execute(KJS::ExecState*) + 133 (nodes.cpp:3101) 29 com.apple.JavaScriptCore 0x004194c6 KJS::statementListExecute(WTF::Vector<WTF::RefPtr<KJS::StatementNode>, 0ul>&, KJS::ExecState*) + 108 (nodes.cpp:3036) 30 com.apple.JavaScriptCore 0x0041961e KJS::BlockNode::execute(KJS::ExecState*) + 92 (nodes.cpp:3077) 31 com.apple.JavaScriptCore 0x004358ab KJS::FunctionBodyNode::execute(KJS::ExecState*) + 47 (nodes.cpp:3969) 32 com.apple.JavaScriptCore 0x0040c72a KJS::FunctionImp::execute(KJS::ExecState*) + 38 (function.cpp:252) 33 com.apple.JavaScriptCore 0x0043f694 KJS::FunctionImp::callAsFunction(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 384 (function.cpp:93) 34 com.apple.JavaScriptCore 0x0042a1bc KJS::JSObject::call(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 222 (object.cpp:95) 35 com.apple.JavaScriptCore 0x00448296 KJS::FunctionCallDotNode::evaluate(KJS::ExecState*) + 794 (nodes.cpp:966) 36 com.apple.JavaScriptCore 0x00438723 KJS::ExprStatementNode::execute(KJS::ExecState*) + 133 (nodes.cpp:3101) 37 com.apple.JavaScriptCore 0x004194c6 KJS::statementListExecute(WTF::Vector<WTF::RefPtr<KJS::StatementNode>, 0ul>&, KJS::ExecState*) + 108 (nodes.cpp:3036) 38 com.apple.JavaScriptCore 0x0041961e KJS::BlockNode::execute(KJS::ExecState*) + 92 (nodes.cpp:3077) 39 com.apple.JavaScriptCore 0x004358ab KJS::FunctionBodyNode::execute(KJS::ExecState*) + 47 (nodes.cpp:3969) 40 com.apple.JavaScriptCore 0x0040c72a KJS::FunctionImp::execute(KJS::ExecState*) + 38 (function.cpp:252) 41 com.apple.JavaScriptCore 0x0043f694 KJS::FunctionImp::callAsFunction(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 384 (function.cpp:93) 42 com.apple.JavaScriptCore 0x0042a1bc KJS::JSObject::call(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 222 (object.cpp:95) 43 com.apple.JavaScriptCore 0x00448296 KJS::FunctionCallDotNode::evaluate(KJS::ExecState*) + 794 (nodes.cpp:966) 44 com.apple.JavaScriptCore 0x00438723 KJS::ExprStatementNode::execute(KJS::ExecState*) + 133 (nodes.cpp:3101) 45 com.apple.JavaScriptCore 0x00438610 KJS::IfNode::execute(KJS::ExecState*) + 236 (nodes.cpp:3129) 46 com.apple.JavaScriptCore 0x004194c6 KJS::statementListExecute(WTF::Vector<WTF::RefPtr<KJS::StatementNode>, 0ul>&, KJS::ExecState*) + 108 (nodes.cpp:3036) 47 com.apple.JavaScriptCore 0x0041961e KJS::BlockNode::execute(KJS::ExecState*) + 92 (nodes.cpp:3077) 48 com.apple.JavaScriptCore 0x004358ab KJS::FunctionBodyNode::execute(KJS::ExecState*) + 47 (nodes.cpp:3969) 49 com.apple.JavaScriptCore 0x0040c72a KJS::FunctionImp::execute(KJS::ExecState*) + 38 (function.cpp:252) 50 com.apple.JavaScriptCore 0x0043f694 KJS::FunctionImp::callAsFunction(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 384 (function.cpp:93) 51 com.apple.JavaScriptCore 0x0042a1bc KJS::JSObject::call(KJS::ExecState*, KJS::JSObject*, KJS::List const&) + 222 (object.cpp:95) 52 com.apple.WebCore 0x023ba087 WebCore::JSAbstractEventListener::handleEvent(WebCore::Event*, bool) + 621 (kjs_events.cpp:115) 53 com.apple.WebCore 0x01ec7fb9 WebCore::EventTargetNode::handleLocalEvents(WebCore::Event*, bool) + 357 (EventTargetNode.cpp:167) 54 com.apple.WebCore 0x01ec76f1 WebCore::EventTargetNode::dispatchGenericEvent(WTF::PassRefPtr<WebCore::Event>, int&, bool) + 1187 (EventTargetNode.cpp:225) 55 com.apple.WebCore 0x01ec847e WebCore::EventTargetNode::dispatchEvent(WTF::PassRefPtr<WebCore::Event>, int&, bool, WebCore::EventTarget*) + 330 (EventTargetNode.cpp:309) 56 com.apple.WebCore 0x01ec84fb WebCore::EventTargetNode::dispatchEvent(WTF::PassRefPtr<WebCore::Event>, int&, bool) + 75 (EventTargetNode.cpp:293) 57 com.apple.WebCore 0x01ec91b7 WebCore::EventTargetNode::dispatchMouseEvent(WebCore::AtomicString const&, int, int, int, int, int, int, bool, bool, bool, bool, bool, WebCore::Node*, WTF::PassRefPtr<WebCore::Event>) + 699 (EventTargetNode.cpp:481) 58 com.apple.WebCore 0x01ec990b WebCore::EventTargetNode::dispatchMouseEvent(WebCore::PlatformMouseEvent const&, WebCore::AtomicString const&, int, WebCore::Node*) + 497 (EventTargetNode.cpp:398) 59 com.apple.WebCore 0x01ec01d1 WebCore::EventHandler::dispatchMouseEvent(WebCore::AtomicString const&, WebCore::Node*, bool, int, WebCore::PlatformMouseEvent const&, bool) + 147 (EventHandler.cpp:1259) 60 com.apple.WebCore 0x01ec0a24 WebCore::EventHandler::handleMouseReleaseEvent(WebCore::PlatformMouseEvent const&) + 894 (EventHandler.cpp:1090) 61 com.apple.WebCore 0x01ec51fd WebCore::EventHandler::mouseUp(NSEvent*) + 435 (EventHandlerMac.mm:523) 62 com.apple.WebKit 0x001ca8e8 -[WebHTMLView mouseUp:] + 274 (WebHTMLView.mm:3224) 63 com.apple.AppKit 0x94538e39 -[NSWindow sendEvent:] + 5520 64 com.apple.Safari 0x000329d3 0x1000 + 203219 65 com.apple.AppKit 0x94505a2c -[NSApplication sendEvent:] + 2766 66 com.apple.Safari 0x000324a8 0x1000 + 201896 67 com.apple.AppKit 0x94463705 -[NSApplication run] + 847 68 com.apple.AppKit 0x944309ba NSApplicationMain + 574 69 com.apple.Safari 0x00002876 0x1000 + 6262
mitz
Comment 7
2007-11-11 14:13:08 PST
Created
attachment 17189
[details]
Reduction
Jubal Kessler
Comment 8
2007-11-11 15:26:08 PST
The reduction didn't crash either the build I first used (
r27663
) or the latest build (
r27863
).
mitz
Comment 9
2007-11-11 17:00:18 PST
(In reply to
comment #8
)
> The reduction didn't crash either the build I first used (
r27663
) or the latest > build (
r27863
). >
It does fail the assertion (and many others that follow) in debug builds. Crashing may require an extra effort which is not necessary for the reduction.
mitz
Comment 10
2007-11-11 17:04:37 PST
Created
attachment 17190
[details]
Check if the selection has been cleared by layout In the blogger.com case (and in the layout test in the patch), the selection is cleared because the frame containing it is being detached.
Adam Roben (:aroben)
Comment 11
2007-11-11 21:27:13 PST
Comment on
attachment 17190
[details]
Check if the selection has been cleared by layout r=me
mitz
Comment 12
2007-11-12 14:04:45 PST
Fixed in <
http://trac.webkit.org/projects/webkit/changeset/27706
>.
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