Bug 15942

Summary: REGRESSION: Selecting "Edit Html" tab in Blogger causes crash (Assertion failed: isRange())
Product: WebKit Reporter: Jubal Kessler <jubal-webkit-20111123>
Component: HTML EditingAssignee: mitz
Status: RESOLVED FIXED    
Severity: Normal CC: ap, mitz
Priority: P1 Keywords: NeedsReduction, Regression
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.4   
Attachments:
Description Flags
Screenshot of affected Blogger edit mode
none
crash report for this bug
none
Reduction
none
Check if the selection has been cleared by layout aroben: review+

Description Jubal Kessler 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.
Comment 1 Jubal Kessler 2007-11-11 07:51:41 PST
Created attachment 17185 [details]
Screenshot of affected Blogger edit mode
Comment 2 Jubal Kessler 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.
Comment 3 Jubal Kessler 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. :-)

Comment 4 Jubal Kessler 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.
Comment 5 Jubal Kessler 2007-11-11 08:31:29 PST
Last revision of the day. This bug does _not_ affect Safari 3.0.3.
Comment 6 Matt Lilek 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

Comment 7 mitz 2007-11-11 14:13:08 PST
Created attachment 17189 [details]
Reduction
Comment 8 Jubal Kessler 2007-11-11 15:26:08 PST
The reduction didn't crash either the build I first used (r27663) or the latest build (r27863).
Comment 9 mitz 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.
Comment 10 mitz 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.
Comment 11 Adam Roben (:aroben) 2007-11-11 21:27:13 PST
Comment on attachment 17190 [details]
Check if the selection has been cleared by layout

r=me
Comment 12 mitz 2007-11-12 14:04:45 PST
Fixed in <http://trac.webkit.org/projects/webkit/changeset/27706>.