The content makes its way into the clipboard, but yes, I can reproduce.

bi.llybob wrote:

(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.

bi.llybob wrote:

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

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.

It seems when I put a breakpoint in onCut and onCopy and step through slowly, it doesn't crash.

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

ajc11123 wrote:

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.

I experienced this on [[Narayana_Gosain_Temple]] which cutting '==References==\n{{reflist}}\n", which may have also cut "{{coord missing|Odisha}}" which follows it.

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}

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.

The node variable in frame 3 of my backtrace is indeed a <link> element.

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.

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

(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

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

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.

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

Change 81280 merged by jenkins-bot:
Don't render <meta>/<link>/<style> tags in GeneratedContentNode

https://gerrit.wikimedia.org/r/81280

Fixed in master; will be deployed on Thursday as part of the regular push.