Last modified: 2013-08-27 19:48:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T52043, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 50043 - VisualEditor: Chromium (< 30) crashes when attempting to cut content containing <link> or <style>
VisualEditor: Chromium (< 30) crashes when attempting to cut content containi...
Status: RESOLVED FIXED
Product: VisualEditor
Classification: Unclassified
ContentEditable (Other open bugs)
unspecified
All All
: High major
: VE-deploy-2013-08-29
Assigned To: Roan Kattouw
: upstream
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-23 09:32 UTC by This, that and the other (TTO)
Modified: 2013-08-27 19:48 UTC (History)
13 users (show)

See Also:
Web browser: Google Chrome
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description This, that and the other (TTO) 2013-06-23 09:32:25 UTC
1. Use Chrome 27 to edit [[Pancytopenia#External links]] in VE
2. Try to cut the {{Commons category}} template (using Ctrl+X/Cmd+X or right click/Cut)

The browser tab crashes.

Seen on Windows and Mac.

No idea how to find any debugging info about the crash.
Comment 1 James Forrester 2013-06-23 16:50:16 UTC
The content makes its way into the clipboard, but yes, I can reproduce.
Comment 2 Joe Schmedley 2013-07-07 04:23:34 UTC
(Chrome 27, Windows) I can't seem to text-select the template, and don't see "Cut" on the right-click menu when the cursor is over the template. However, I do get an error tone when I select the template and press Ctrl-X.
Comment 3 Joe Schmedley 2013-07-07 04:25:02 UTC
Also crashes when I try to cut multiple templates in Chrome. For example, if I select the two hatnotes at the top of https://en.wikipedia.org/wiki/Mauritius
Comment 4 Elitre 2013-07-12 21:20:45 UTC
I don't think I manage to remove templates only with CTRL-X, but if I select some text along and then try to cut, Chrome's tab will crash as well.
Comment 5 Krinkle 2013-07-17 14:08:53 UTC
It seems when I put a breakpoint in onCut and onCopy and step through slowly, it doesn't crash.
Comment 6 Oliver Keyes 2013-07-17 17:34:23 UTC
This also happens on Chrome 28 with reference blocks, looks like. Not sure if the same problem - try cutting the ref block on https://en.wikipedia.org/wiki/Lumpectomy
Comment 7 Marechal Ney 2013-07-18 01:13:29 UTC
I experience the same bug on Chrome 28.  Chrome crashes (displaying its characteristic "Aw snap" error page) when I try to cut certain templates, notably {{citation needed}}, {{who}}, and other in-line templates.  This does not happen with copying.  In addition, I could not reproduce the bug in my own userspace, only in article space.
Comment 8 John Mark Vandenberg 2013-07-23 02:11:53 UTC
I experienced this on [[Narayana_Gosain_Temple]] which cutting '==References==\n{{reflist}}\n", which may have also cut "{{coord missing|Odisha}}" which follows it.
Comment 9 Tim Starling 2013-08-01 07:07:21 UTC
I think this is probably the most important bug in VE at the moment, and it's sad to see no progress being made on it, so I got a backtrace from stock Chromium in Ubuntu 12.04:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcd87e700 (LWP 2767)]
WebCore::AppendNodeCommand::AppendNodeCommand (this=0x14b6f1e5eea0, parent=..., node=...)
    at third_party/WebKit/Source/core/editing/AppendNodeCommand.cpp:39
39	third_party/WebKit/Source/core/editing/AppendNodeCommand.cpp: No such file or directory.
(gdb) bt
#0  WebCore::AppendNodeCommand::AppendNodeCommand (this=0x14b6f1e5eea0, parent=..., node=...)
    at third_party/WebKit/Source/core/editing/AppendNodeCommand.cpp:39
#1  0x000055555752af66 in create (node=..., parent=...)
    at third_party/WebKit/Source/core/editing/AppendNodeCommand.h:37
#2  WebCore::CompositeEditCommand::appendNode (this=0x14b6f44c0800, node=..., parent=...)
    at third_party/WebKit/Source/core/editing/CompositeEditCommand.cpp:372
#3  0x0000555557535512 in WebCore::DeleteSelectionCommand::makeStylingElementsDirectChildrenOfEditableRootToPreventStyleLoss (this=0x14b6f44c0800) at third_party/WebKit/Source/core/editing/DeleteSelectionCommand.cpp:431
#4  0x0000555557538582 in WebCore::DeleteSelectionCommand::handleGeneralDelete (this=0x14b6f44c0800)
    at third_party/WebKit/Source/core/editing/DeleteSelectionCommand.cpp:445
#5  0x000055555753a2e5 in WebCore::DeleteSelectionCommand::doApply (this=0x14b6f44c0800)
    at third_party/WebKit/Source/core/editing/DeleteSelectionCommand.cpp:836
#6  0x00005555575273d2 in WebCore::CompositeEditCommand::apply (this=0x14b6f44c0800)
    at third_party/WebKit/Source/core/editing/CompositeEditCommand.cpp:202
#7  0x000055555725c6f4 in deleteSelectionWithSmartDelete (smartDelete=false, this=<optimized out>)
    at third_party/WebKit/Source/core/editing/Editor.cpp:340
#8  WebCore::Editor::deleteSelectionWithSmartDelete (this=<optimized out>, smartDelete=false)
    at third_party/WebKit/Source/core/editing/Editor.cpp:335
#9  0x000055555726498a in WebCore::Editor::cut (this=0x14b6f2019180)
    at third_party/WebKit/Source/core/editing/Editor.cpp:982
#10 0x000055555726c08f in executeCut (frame=0x14b6f2d5cc00, source=<optimized out>)
    at third_party/WebKit/Source/core/editing/EditorCommand.cpp:301
#11 WebCore::executeCut (frame=0x14b6f2d5cc00, source=<optimized out>)
    at third_party/WebKit/Source/core/editing/EditorCommand.cpp:297
#12 0x00005555569cd7ee in WebKit::WebFrameImpl::executeCommand (this=0x14b6f2d7ca80, name=..., value=...)
    at third_party/WebKit/Source/WebKit/chromium/src/WebFrameImpl.cpp:1243
#13 0x00005555583d50e1 in content::RenderViewImpl::handleCurrentKeyboardEvent (this=<optimized out>)
    at content/renderer/render_view_impl.cc:2201
#14 0x0000555556a155ba in WebKit::EditorClientImpl::handleKeyboardEvent (this=0x14b6f2bd45a0, evt=0x14b6f379f700)
    at third_party/WebKit/Source/WebKit/chromium/src/EditorClientImpl.cpp:643
#15 0x00005555573f9d13 in WebCore::EventHandler::defaultKeyboardEventHandler (this=0x14b6f1464c80, 
    event=0x14b6f379f700) at third_party/WebKit/Source/core/page/EventHandler.cpp:3121
#16 0x0000555556acdad8 in WebCore::Node::defaultEventHandler (this=0x14b6f40364e0, event=0x14b6f379f700)
    at third_party/WebKit/Source/core/dom/Node.cpp:2546
---Type <return> to continue, or q <return> to quit---
#17 0x0000555556b13822 in dispatchEventPostProcess (preDispatchEventHandlerResult=0x0, this=0x7fffcd87bdb0)
    at third_party/WebKit/Source/core/dom/EventDispatcher.cpp:208
#18 WebCore::EventDispatcher::dispatch (this=0x7fffcd87bdb0)
    at third_party/WebKit/Source/core/dom/EventDispatcher.cpp:127
#19 0x0000555556b1337e in WebCore::EventDispatcher::dispatchEvent (node=<optimized out>, mediator=...)
    at third_party/WebKit/Source/core/dom/EventDispatcher.cpp:56
#20 0x0000555556ace21b in WebCore::Node::dispatchEvent (this=0x14b6f40364e0, event=...)
    at third_party/WebKit/Source/core/dom/Node.cpp:2426
#21 0x0000555556abd15d in WebCore::EventTarget::dispatchEvent (this=0x14b6f40364e0, event=..., ec=<optimized out>)
    at third_party/WebKit/Source/core/dom/EventTarget.cpp:148
#22 0x00005555573fc181 in WebCore::EventHandler::keyEvent (this=0x14b6f1464c80, initialKeyEvent=...)
    at third_party/WebKit/Source/core/page/EventHandler.cpp:3006
#23 0x00005555569f3ccb in WebKit::WebViewImpl::handleKeyEvent (this=0x14b6f2bd4500, event=...)
    at third_party/WebKit/Source/WebKit/chromium/src/WebViewImpl.cpp:987
#24 0x00005555569f743b in WebKit::WebViewImpl::handleInputEvent (this=0x14b6f2bd4500, inputEvent=...)
    at third_party/WebKit/Source/WebKit/chromium/src/WebViewImpl.cpp:2024
#25 0x00005555583f92b3 in content::RenderWidget::OnHandleInputEvent (this=0x14b6f2b41000, 
    input_event=0x14b6f38f7898, is_keyboard_shortcut=true) at content/renderer/render_widget.cc:756
#26 0x00005555583f7c5e in DispatchToMethod<content::RenderWidget, void (content::RenderWidget::*)(WebKit::WebInputEvent const*, bool), WebKit::WebInputEvent const*, bool> (method=<optimized out>, obj=0x14b6f2b41000, arg=...)
    at ./base/tuple.h:553
#27 Dispatch<content::RenderWidget, content::RenderWidget, void (content::RenderWidget::*)(WebKit::WebInputEvent const*, bool)> (func=
    (void (content::RenderWidget::*)(content::RenderWidget * const, const WebKit::WebInputEvent *, bool)) 0x5555583f90e0 <content::RenderWidget::OnHandleInputEvent(WebKit::WebInputEvent const*, bool)>, obj=0x14b6f2b41000, msg=
    0x14b6f38d9f88, sender=<optimized out>) at ./content/common/input_messages.h:39
#28 content::RenderWidget::OnMessageReceived (this=0x14b6f2b41000, message=...)
    at content/renderer/render_widget.cc:311
#29 0x00005555583ed784 in content::RenderViewImpl::OnMessageReceived (this=0x14b6f2b41000, message=...)
    at content/renderer/render_view_impl.cc:1124
#30 0x00005555566c8fa8 in content::MessageRouter::RouteMessage (this=<optimized out>, msg=...)
    at content/common/message_router.cc:49
#31 0x0000555556651a8b in OnMessageReceived (msg=..., this=0x14b6f14bcb88) at content/common/child_thread.cc:271
#32 content::ChildThread::OnMessageReceived (this=0x14b6f14bcb88, msg=...) at content/common/child_thread.cc:236
---Type <return> to continue, or q <return> to quit---
#33 0x00005555566280ba in IPC::ChannelProxy::Context::OnDispatchMessage (this=0x14b6f14bde00, message=...)
    at ipc/ipc_channel_proxy.cc:261
#34 0x0000555556296fae in Run (this=0x7fffcd87d958) at ./base/callback.h:396
#35 base::MessageLoop::RunTask (this=0x7fffcd87da50, pending_task=...) at base/message_loop.cc:484
#36 0x000055555629a70b in base::MessageLoop::DeferOrRunPendingTask (this=0x7fffcd87da50, pending_task=...)
    at base/message_loop.cc:496
#37 0x000055555629ad13 in DoWork (this=<optimized out>) at base/message_loop.cc:688
#38 base::MessageLoop::DoWork (this=0x7fffcd87da50) at base/message_loop.cc:667
#39 0x000055555629b459 in base::MessagePumpDefault::Run (this=0x14b6f149b7e0, delegate=0x7fffcd87da50)
    at base/message_pump_default.cc:29
#40 0x00005555562aa202 in base::RunLoop::Run (this=0x7fffcd87da10) at base/run_loop.cc:45
#41 0x0000555556296444 in base::MessageLoop::Run (this=<optimized out>) at base/message_loop.cc:321
#42 0x00005555562bb330 in base::Thread::ThreadMain (this=0x14b6f14a45a0) at base/threading/thread.cc:197
#43 0x00005555562b8001 in base::(anonymous namespace)::ThreadFunc (params=0x14b6f0a23650)
    at base/threading/platform_thread_posix.cc:95
#44 0x00007ffff3df9e9a in start_thread (arg=0x7fffcd87e700) at pthread_create.c:308
#45 0x00007ffff1ef0ccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#46 0x0000000000000000 in ?? ()
(gdb) info locals
No locals.
(gdb) up
#1  0x000055555752af66 in create (node=..., parent=...)
    at third_party/WebKit/Source/core/editing/AppendNodeCommand.h:37
37	third_party/WebKit/Source/core/editing/AppendNodeCommand.h: No such file or directory.
(gdb) info locals
No locals.
(gdb) up
#2  WebCore::CompositeEditCommand::appendNode (this=0x14b6f44c0800, node=..., parent=...)
    at third_party/WebKit/Source/core/editing/CompositeEditCommand.cpp:372
372	third_party/WebKit/Source/core/editing/CompositeEditCommand.cpp: No such file or directory.
(gdb) info locals
No locals.
(gdb) up
#3  0x0000555557535512 in WebCore::DeleteSelectionCommand::makeStylingElementsDirectChildrenOfEditableRootToPreventStyleLoss (this=0x14b6f44c0800) at third_party/WebKit/Source/core/editing/DeleteSelectionCommand.cpp:431
431	third_party/WebKit/Source/core/editing/DeleteSelectionCommand.cpp: No such file or directory.
(gdb) info locals
rootEditableElement = {m_ptr = 0x0}
nextNode = {m_ptr = 0x14b6f3107ee0}
range = {m_ptr = 0x14b6f3e7f980}
node = {m_ptr = 0x14b6f2d83180}
Comment 10 Inez Korczyński 2013-08-01 07:30:06 UTC
It seems that this bug has to do with link html tag.

In both examples (Pancytopenia and Lumpectomy) if I delete <link> node (using debug tools) from inside (in second example it is not a direct child) of the node to cut then when I'm cutting it browser tab does not crash anymore.

Based on the w3c documentation it seems to me that we are using link tag incorrectly - value of attribute "rel" should be one of the values listed here http://www.w3schools.com/tags/tag_link.asp but in our case it is "mw:WikiLink/Category".

In case of templates in VE we are simply rendering HTMLDOM that we are getting from Parsoid, so fixing it in Parsoid (not using link tag incorrectly) should solve this problem. (I'm making some assumptions here - it should be verified first in some sort of isolation - jsfiddle.)

For now as a quick fix we can strip all link nodes when we are rendering template in the VE.
Comment 11 Tim Starling 2013-08-01 09:26:27 UTC
The node variable in frame 3 of my backtrace is indeed a <link> element.
Comment 12 Roan Kattouw 2013-08-01 16:07:16 UTC
I'll try to isolate this to produce a minimal test case, see how we can work around it in VE, and report it to the Chrome people. It's not acceptable for a browser to segfault even on invalid HTML.
Comment 13 Krinkle 2013-08-01 19:50:14 UTC
I can still reproduce this on https://en.wikipedia.org/wiki/Pancytopenia?veaction=edit#External_links with Chrome 28 (stable channel).

However when testing on Chrome 30 (dev channel), I can no longer reproduce this.

Confirmed that removing the [
<link rel=​"mw:​WikiLink/​Category" href=​"./​Category:​Commons_category_without_a_link_on_Wikidata" data-parsoid=​"{"stx":​"simple","a":​{"href":​"./​Category:​Commons_category_without_a_link_on_Wikidata"}​,"sa":​{"href":​"Category:​Commons category without a link on Wikidata"}​}​" about=​"#mwt7">​
] tag from the {{commonscat}} template before cutting, prevents the crash.


@Tim: Which chromium version is the stacktrace from?

Filed upstream: https://code.google.com/p/chromium/issues/detail?id=267059
Comment 14 Tim Starling 2013-08-01 22:11:38 UTC
(In reply to comment #13)
> @Tim: Which chromium version is the stacktrace from?

It's the Ubuntu package version 28.0.1500.71-0ubuntu1.12.04.1
Comment 15 Tim Starling 2013-08-02 04:28:03 UTC
I think this is the patch that fixed it in Chrome 30:

https://codereview.chromium.org/14995014
https://trac.webkit.org/changeset/150402

Which would mean that this is the upstream bug: 

http://code.google.com/p/chromium/issues/detail?id=177470
https://bugs.webkit.org/show_bug.cgi?id=116479
Comment 16 Krinkle 2013-08-02 05:07:23 UTC
Since <link> and <style> don't render in a useful way in the DOM (if they would ever be in wikitext, they'd be exported to VE as generated content or some other special thing that we can visualise and edit through an inspector or dialog)..

It is fixed in Chromium 30.

Updated summary to mention Chromium, not Chrome. This is likely affecting Opera 15 as well, for example.

Since we don't want to 2 weeks for this to land in stable, and we can safely strip these out before we render them in CE in the first place, let's do that.
Comment 17 Gerrit Notification Bot 2013-08-27 18:19:20 UTC
Change 81280 had a related patch set uploaded by Catrope:
Don't render <meta>/<link>/<style> tags in GeneratedContentNode

https://gerrit.wikimedia.org/r/81280
Comment 18 Gerrit Notification Bot 2013-08-27 18:28:36 UTC
Change 81280 merged by jenkins-bot:
Don't render <meta>/<link>/<style> tags in GeneratedContentNode

https://gerrit.wikimedia.org/r/81280
Comment 19 James Forrester 2013-08-27 19:48:28 UTC
Fixed in master; will be deployed on Thursday as part of the regular push.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links