Bug #1570110 “evolution crashed with SIGSEGV, while pasting from...” : Bugs : webkitgtk package : Ubuntu

Revision history for this message

In bugs.webkit.org/ #155694, Michael Gratton (mjog) wrote on 2016-03-20:

#7

Download full text (3.9 KiB)

WebKitGTK+ 2.4.10 seems to have introduced a bug that is causing a crash when loading HTML images in Geary (See https://bugzilla.gnome.org/show_bug.cgi?id=763933). This didn't occur using earlier versions of WebKitGTK+.

Geary currently implements user-controlled image loading by what amounts to using a random scheme string for the IMG SRC attribute - when the user has assented to loading images for a specific message, it updates every IMG SRC attribute value to be prefixed with the random scheme. The crash occurs during this process, at random, when displaying a HTML message.

A workaround exists in removing the src element first using webkit_dom_element_remove_attribute(), causing the subsequent call to webkit_dom_element_set_attribute() not crash. Workarounds that do not work include cloning the IMG element and setting the SRC element on that instead, nor does casting the element and using webkit_dom_html_image_element_set_src(). I didn't try creating a new Attr instance, setting the value on that, then setting that on the IMG element.

I know you guys aren't interested in supporting 2.4.x, but I thought I'd log it since it's a regression with 2.4.10 (thanks for doing a new release, BTW!).

Thread 1 "geary" received signal SIGSEGV, Segmentation fault.
WebCore::AXObjectCache::handleAttributeChanged (this=0x7fff9191b500, attrName=..., element=0x5df8210)
    at ../Source/WebCore/accessibility/AXObjectCache.cpp:880
880 if (!attrName.localName().string().startsWith("aria-"))
(gdb) bt
#0 0x00007ffff4d8aae9 in WebCore::AXObjectCache::handleAttributeChanged(WebCore::QualifiedName const&, WebCore::Element*) (this=0x7fff9191b500, attrName=..., element=0x5df8210) at ../Source/WebCore/accessibility/AXObjectCache.cpp:880
#1 0x00007ffff4f8105a in WebCore::Element::attributeChanged(WebCore::QualifiedName const&, WTF::AtomicString const&, WTF::AtomicString const&, WebCore::Element::AttributeModificationReason) (this=0x5df8210, name=..., oldValue=..., newValue=...)
    at ../Source/WebCore/dom/Element.cpp:1137
#2 0x00007ffff4f80530 in WebCore::Element::didModifyAttribute(WebCore::QualifiedName const&, WTF::AtomicString const&, WTF::AtomicString const&) (this=this@entry=0x5df8210, name=..., oldValue=..., newValue=...) at ../Source/WebCore/dom/Element.cpp:2851
#3 0x00007ffff4f8777d in WebCore::Element::setAttributeInternal(unsigned int, WebCore::QualifiedName const&, WTF::AtomicString const&, WebCore::Element::SynchronizationOfLazyAttribute) (this=this@entry=0x5df8210, index=<optimised out>, name=..., newValue=..., inSynchronizationOfLazyAttribute=inSynchronizationOfLazyAttribute@entry=WebCore::Element::NotInSynchronizationOfLazyAttribute)
    at ../Source/WebCore/dom/Element.cpp:1075
#4 0x00007ffff4f8494f in WebCore::Element::setAttribute(WTF::AtomicString const&, WTF::AtomicString const&, int&) (this=this@entry=0x5df8210, localName=..., value=..., ec=@0x7fffffffddec: 0) at ../Source/WebCore/dom/Element.cpp:1027
#5 0x00007ffff5bd7a5c in webkit_dom_element_set_attribute(WebKitDOMElement*, gchar const*, gchar const*, GError**) (self=self@entry=0x5dcd0b0 [WebKitDOMHTMLImageElement], name=name@entry=0x6ac5bc "src", value=value@entry=0x5851a00 "glxaowi...

WebKitGTK+ 2.4.10 seems to have introduced a bug that is causing a crash when loading HTML images in Geary (See https://bugzilla.gnome.org/show_bug.cgi?id=763933). This didn't occur using earlier versions of WebKitGTK+.

Geary currently implements user-controlled image loading by what amounts to using a random scheme string for the IMG SRC attribute - when the user has assented to loading images for a specific message, it updates every IMG SRC attribute value to be prefixed with the random scheme. The crash occurs during this process, at random, when displaying a HTML message.

A workaround exists in removing the src element first using webkit_dom_element_remove_attribute(), causing the subsequent call to webkit_dom_element_set_attribute() not crash. Workarounds that do not work include cloning the IMG element and setting the SRC element on that instead, nor does casting the element and using webkit_dom_html_image_element_set_src(). I didn't try creating a new Attr instance, setting the value on that, then setting that on the IMG element.

I know you guys aren't interested in supporting 2.4.x, but I thought I'd log it since it's a regression with 2.4.10 (thanks for doing a new release, BTW!).

Thread 1 "geary" received signal SIGSEGV, Segmentation fault.
WebCore::AXObjectCache::handleAttributeChanged (this=0x7fff9191b500, attrName=..., element=0x5df8210)
    at ../Source/WebCore/accessibility/AXObjectCache.cpp:880
880	    if (!attrName.localName().string().startsWith("aria-"))
(gdb) bt
#0  0x00007ffff4d8aae9 in WebCore::AXObjectCache::handleAttributeChanged(WebCore::QualifiedName const&, WebCore::Element*) (this=0x7fff9191b500, attrName=..., element=0x5df8210) at ../Source/WebCore/accessibility/AXObjectCache.cpp:880
#1  0x00007ffff4f8105a in WebCore::Element::attributeChanged(WebCore::QualifiedName const&, WTF::AtomicString const&, WTF::AtomicString const&, WebCore::Element::AttributeModificationReason) (this=0x5df8210, name=..., oldValue=..., newValue=...)
    at ../Source/WebCore/dom/Element.cpp:1137
#2  0x00007ffff4f80530 in WebCore::Element::didModifyAttribute(WebCore::QualifiedName const&, WTF::AtomicString const&, WTF::AtomicString const&) (this=this@entry=0x5df8210, name=..., oldValue=..., newValue=...) at ../Source/WebCore/dom/Element.cpp:2851
#3  0x00007ffff4f8777d in WebCore::Element::setAttributeInternal(unsigned int, WebCore::QualifiedName const&, WTF::AtomicString const&, WebCore::Element::SynchronizationOfLazyAttribute) (this=this@entry=0x5df8210, index=<optimised out>, name=..., newValue=..., inSynchronizationOfLazyAttribute=inSynchronizationOfLazyAttribute@entry=WebCore::Element::NotInSynchronizationOfLazyAttribute)
    at ../Source/WebCore/dom/Element.cpp:1075
#4  0x00007ffff4f8494f in WebCore::Element::setAttribute(WTF::AtomicString const&, WTF::AtomicString const&, int&) (this=this@entry=0x5df8210, localName=..., value=..., ec=@0x7fffffffddec: 0) at ../Source/WebCore/dom/Element.cpp:1027
#5  0x00007ffff5bd7a5c in webkit_dom_element_set_attribute(WebKitDOMElement*, gchar const*, gchar const*, GError**) (self=self@entry=0x5dcd0b0 [WebKitDOMHTMLImageElement], name=name@entry=0x6ac5bc "src", value=value@entry=0x5851a00 "glxaowieyx:http://www.outsideonline.com/sites/default/files/styles/img_600x339/public/cogburn-cb4.jpg?itok=04MxjrHH", error=error@entry=0x7fffffffded0)
    at DerivedSources/webkitdom/WebKitDOMElement.cpp:533
#6  0x00000000004d7e86 in conversation_viewer_show_images_email (self=self@entry=0xd46230 [ConversationViewer], email_element=0x5b59440 [WebKitDOMHTMLDivElement], remember=remember@entry=0)
    at /home/mjg/local/src/geary/src/client/conversation-viewer/conversation-viewer.vala:1497
---Type <return> to continue, or q <return> to quit---
#7  0x00000000004dfbb0 in conversation_viewer_add_message (self=0xd46230 [ConversationViewer], email=0x7fff1400b770 [GearyEmail], is_in_folder=1) at /home/mjg/local/src/geary/src/client/conversation-viewer/conversation-viewer.vala:698

Revision history for this message

In bugs.webkit.org/ #155694, Michael Gratton (mjog) wrote on 2016-03-20:

#8

NB, while the crash occurs in WebCore::AXObjectCache::handleAttributeChanged, I don't think it's related to accessibility, by that stage attrName has gone bad: attrName.m_impl is pointing to an invalid memory location.

Revision history for this message

In bugs.webkit.org/ #155694, Michael Gratton (mjog) wrote on 2016-03-26:

#9

This seems to be not just limited to setting IMG SRC attributes. Geary is also occasionally crashing when pasting content into an editable web view, with a similar top of the stack, e.g.: https://bugzilla.gnome.org/show_bug.cgi?id=764168

They seem to be related in that in both cases, an attribute value is being set via the DOM API in a document that is already being displayed by a web view.

Revision history for this message

In bugs.webkit.org/ #155694, Mcatanzaro (mcatanzaro) wrote on 2016-04-02:

#10

We received 1333 reports of this crash from Evolution and Geary users in Fedora in the past two weeks. It is definitely a regression from the 2.4.10 update.

There are possibly more reports, but since it's a WebKit1 crash the crashes get assigned to individual applications rather than to WebKit, making it impossible to search for them. I only checked Evolution and Geary.

Revision history for this message

In bugs.webkit.org/ #155694, Mcatanzaro (mcatanzaro) wrote on 2016-04-02:

#11

Also, I will just add we have several slight variations on this crash:

https://retrace.fedoraproject.org/faf/problems/1886091/
https://retrace.fedoraproject.org/faf/problems/1875612/
https://retrace.fedoraproject.org/faf/problems/1888402/
https://retrace.fedoraproject.org/faf/problems/1864883/

Revision history for this message

In bugs.webkit.org/ #155694, Mcatanzaro (mcatanzaro) wrote on 2016-04-02:

#12

(In reply to comment #2)
> This seems to be not just limited to setting IMG SRC attributes. Geary is
> also occasionally crashing when pasting content into an editable web view,
> with a similar top of the stack, e.g.:
> https://bugzilla.gnome.org/show_bug.cgi?id=764168
>
> They seem to be related in that in both cases, an attribute value is being
> set via the DOM API in a document that is already being displayed by a web
> view.

This is how Evolution is crashing as well (at least, it's the report for which we received a description and full backtrace, see the See Also field).

Revision history for this message

In bugs.webkit.org/ #155694, Mcatanzaro (mcatanzaro) wrote on 2016-04-02:

#13

Download full text (18.1 KiB)

(In reply to comment #5)
> This is how Evolution is crashing as well (at least, it's the report for
> which we received a description and full backtrace, see the See Also field).

Sigh, I realize this is a private bug... I think thread 1 is probably the only important part; note the string "aria-" in the crash frame.

Core was generated by `/usr/bin/evolution'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 WTF::StringImpl::startsWith (this=0xbad801d800000002, matchString=matchString@entry=0x7f85ba36fea7 "aria-", matchLength=matchLength@entry=5, caseSensitive=caseSensitive@entry=true) at Source/WTF/wtf/text/StringImpl.cpp:1363
1363 if (matchLength > length())
[Current thread is 1 (Thread 0x7f85c0247ac0 (LWP 17496))]

Thread 1 (Thread 0x7f85c0247ac0 (LWP 17496)):
#0 WTF::StringImpl::startsWith (this=0xbad801d800000002, matchString=matchString@entry=0x7f85ba36fea7 "aria-", matchLength=matchLength@entry=5, caseSensitive=caseSensitive@entry=true) at Source/WTF/wtf/text/StringImpl.cpp:1363
No locals.
#1 0x00007f85b8f3e00f in WTF::StringImpl::startsWith<6u> (caseSensitive=true, prefix=..., this=<optimized out>) at Source/WTF/wtf/text/StringImpl.h:730
No locals.
#2 WTF::String::startsWith<6u> (caseSensitive=true, prefix=..., this=<optimized out>) at Source/WTF/wtf/text/WTFString.h:281
No locals.
#3 WebCore::AXObjectCache::handleAttributeChanged (this=0x7f851b997f00, attrName=..., element=0x558fcfb67cb0) at Source/WebCore/accessibility/AXObjectCache.cpp:880
No locals.
#4 0x00007f85b91641ea in WebCore::Element::attributeChanged (this=0x558fcfb67cb0, name=..., oldValue=..., newValue=...) at Source/WebCore/dom/Element.cpp:1137
        cache = <optimized out>
        styleResolver = <optimized out>
        testShouldInvalidateStyle = true
        shouldInvalidateStyle = <optimized out>
#5 0x00007f85b9163520 in WebCore::Element::didModifyAttribute (this=this@entry=0x558fcfb67cb0, name=..., oldValue=..., newValue=...) at Source/WebCore/dom/Element.cpp:2851
No locals.
#6 0x00007f85b916b449 in WebCore::Element::setAttributeInternal (this=0x558fcfb67cb0, index=<optimized out>, name=..., newValue=..., inSynchronizationOfLazyAttribute=WebCore::Element::NotInSynchronizationOfLazyAttribute) at Source/WebCore/dom/Element.cpp:1075
        oldValue = {m_string = {m_impl = {m_ptr = 0x7f858c676000}}}
        valueChanged = <optimized out>
        attributeName = <optimized out>
#7 0x00007f85b91de4b9 in WebCore::CompositeEditCommand::applyCommandToComposite (this=this@entry=0x7f853a37c900, prpCommand=...) at Source/WebCore/editing/CompositeEditCommand.cpp:278
        command = {m_ptr = 0x7f853a56ad20}
#8 0x00007f85b91e4f1a in WebCore::CompositeEditCommand::setNodeAttribute (this=this@entry=0x7f853a37c900, element=..., attribute=..., value=...) at Source/WebCore/editing/CompositeEditCommand.cpp:664
No locals.
#9 0x00007f85b926c8f9 in WebCore::ReplaceSelectionCommand::removeRedundantStylesAndKeepStyleSpanInline (this=this@entry=0x7f853a37c900, insertedNodes=...) at Source/WebCore/editing/ReplaceSelectionCommand.cpp:525
        element = 0x558fcfb67cb0
        inlineStyle = 0x7f853a3cb410
        newInlineStyle = {m_ptr = 0x7f851b975b70}
  ...

(In reply to comment #5) 
> This is how Evolution is crashing as well (at least, it's the report for
> which we received a description and full backtrace, see the See Also field).

Sigh, I realize this is a private bug... I think thread 1 is probably the only important part; note the string "aria-" in the crash frame.

Core was generated by `/usr/bin/evolution'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  WTF::StringImpl::startsWith (this=0xbad801d800000002, matchString=matchString@entry=0x7f85ba36fea7 "aria-", matchLength=matchLength@entry=5, caseSensitive=caseSensitive@entry=true) at Source/WTF/wtf/text/StringImpl.cpp:1363
1363	    if (matchLength > length())
[Current thread is 1 (Thread 0x7f85c0247ac0 (LWP 17496))]

Thread 1 (Thread 0x7f85c0247ac0 (LWP 17496)):
#0  WTF::StringImpl::startsWith (this=0xbad801d800000002, matchString=matchString@entry=0x7f85ba36fea7 "aria-", matchLength=matchLength@entry=5, caseSensitive=caseSensitive@entry=true) at Source/WTF/wtf/text/StringImpl.cpp:1363
No locals.
#1  0x00007f85b8f3e00f in WTF::StringImpl::startsWith<6u> (caseSensitive=true, prefix=..., this=<optimized out>) at Source/WTF/wtf/text/StringImpl.h:730
No locals.
#2  WTF::String::startsWith<6u> (caseSensitive=true, prefix=..., this=<optimized out>) at Source/WTF/wtf/text/WTFString.h:281
No locals.
#3  WebCore::AXObjectCache::handleAttributeChanged (this=0x7f851b997f00, attrName=..., element=0x558fcfb67cb0) at Source/WebCore/accessibility/AXObjectCache.cpp:880
No locals.
#4  0x00007f85b91641ea in WebCore::Element::attributeChanged (this=0x558fcfb67cb0, name=..., oldValue=..., newValue=...) at Source/WebCore/dom/Element.cpp:1137
        cache = <optimized out>
        styleResolver = <optimized out>
        testShouldInvalidateStyle = true
        shouldInvalidateStyle = <optimized out>
#5  0x00007f85b9163520 in WebCore::Element::didModifyAttribute (this=this@entry=0x558fcfb67cb0, name=..., oldValue=..., newValue=...) at Source/WebCore/dom/Element.cpp:2851
No locals.
#6  0x00007f85b916b449 in WebCore::Element::setAttributeInternal (this=0x558fcfb67cb0, index=<optimized out>, name=..., newValue=..., inSynchronizationOfLazyAttribute=WebCore::Element::NotInSynchronizationOfLazyAttribute) at Source/WebCore/dom/Element.cpp:1075
        oldValue = {m_string = {m_impl = {m_ptr = 0x7f858c676000}}}
        valueChanged = <optimized out>
        attributeName = <optimized out>
#7  0x00007f85b91de4b9 in WebCore::CompositeEditCommand::applyCommandToComposite (this=this@entry=0x7f853a37c900, prpCommand=...) at Source/WebCore/editing/CompositeEditCommand.cpp:278
        command = {m_ptr = 0x7f853a56ad20}
#8  0x00007f85b91e4f1a in WebCore::CompositeEditCommand::setNodeAttribute (this=this@entry=0x7f853a37c900, element=..., attribute=..., value=...) at Source/WebCore/editing/CompositeEditCommand.cpp:664
No locals.
#9  0x00007f85b926c8f9 in WebCore::ReplaceSelectionCommand::removeRedundantStylesAndKeepStyleSpanInline (this=this@entry=0x7f853a37c900, insertedNodes=...) at Source/WebCore/editing/ReplaceSelectionCommand.cpp:525
        element = 0x558fcfb67cb0
        inlineStyle = 0x7f853a3cb410
        newInlineStyle = {m_ptr = 0x7f851b975b70}
        node = {m_ptr = 0x558fcfb67cb0}
        next = {m_ptr = 0x558fd14d9630}
#10 0x00007f85b926f714 in WebCore::ReplaceSelectionCommand::doApply (this=0x7f853a37c900) at Source/WebCore/editing/ReplaceSelectionCommand.cpp:1151
        selection = {m_base = {m_anchorNode = {m_ptr = 0x558fd16cd1b0}, m_offset = 0, m_anchorType = 1, m_isLegacyEditingPosition = true}, m_extent = {m_anchorNode = {m_ptr = 0x558fd16cd1b0}, m_offset = 0, m_anchorType = 1, m_isLegacyEditingPosition = true}, m_start = {m_anchorNode = {m_ptr = 0x558fd16cd1b0}, m_offset = 0, m_anchorType = 1, m_isLegacyEditingPosition = true}, m_end = {m_anchorNode = {m_ptr = 0x558fd16cd1b0}, m_offset = 0, m_anchorType = 1, m_isLegacyEditingPosition = true}, m_affinity = WebCore::DOWNSTREAM, m_selectionType = WebCore::VisibleSelection::CaretSelection, m_baseIsFirst = true, m_isDirectional = true}
        fragment = {m_document = {m_ptr = 0x7f853a276d00}, m_fragment = {m_ptr = 0x558fd0f6ad00}, m_hasInterchangeNewlineAtStart = false, m_hasInterchangeNewlineAtEnd = false}
        visibleStart = {m_deepPosition = {m_anchorNode = {m_ptr = 0x558fd16cd1b0}, m_offset = 0, m_anchorType = 1, m_isLegacyEditingPosition = true}, m_affinity = WebCore::DOWNSTREAM}
        visibleEnd = {m_deepPosition = {m_anchorNode = {m_ptr = 0x558fd16cd1b0}, m_offset = 0, m_anchorType = 1, m_isLegacyEditingPosition = true}, m_affinity = WebCore::DOWNSTREAM}
        selectionEndWasEndOfParagraph = true
        selectionStartWasStartOfParagraph = true
        startBlock = <optimized out>
        insertionPos = {m_anchorNode = {m_ptr = 0x558fd16cd1b0}, m_offset = 0, m_anchorType = 1, m_isLegacyEditingPosition = true}
        startIsInsideMailBlockquote = false
        selectionIsPlainText = <optimized out>
        currentRoot = <optimized out>
        endBR = <optimized out>
        originalVisPosBeforeEndBR = {m_deepPosition = {m_anchorNode = {m_ptr = 0x558fd02d50a0}, m_offset = 0, m_anchorType = 1, m_isLegacyEditingPosition = true}, m_affinity = WebCore::DOWNSTREAM}
        insertionBlock = {m_ptr = 0x558fcff56940}
        insertedNodes = {m_firstNodeInserted = {m_ptr = 0x558fcfb67cb0}, m_lastNodeInserted = {m_ptr = 0x558fd1a7b1f0}}
        refNode = {m_ptr = 0x558fd1a7b1f0}
        node = <optimized out>
        blockStart = <optimized out>
        plainTextFragment = false
        startOfInsertedContent = {m_deepPosition = {m_anchorNode = {m_ptr = 0x558fd14d9630}, m_offset = 0, m_anchorType = 0, m_isLegacyEditingPosition = true}, m_affinity = WebCore::DOWNSTREAM}
        lastPositionToSelect = {m_anchorNode = {m_ptr = 0x558fd1a7b1f0}, m_offset = -1204594578, m_anchorType = 5, m_isLegacyEditingPosition = false}
#11 0x00007f85b91de107 in WebCore::CompositeEditCommand::apply (this=0x7f853a37c900) at Source/WebCore/editing/CompositeEditCommand.cpp:227
No locals.
#12 0x00007f85b91de21d in WebCore::applyCommand (command=...) at Source/WebCore/editing/CompositeEditCommand.cpp:182
No locals.
#13 0x00007f85b9207946 in WebCore::executeInsertFragment (frame=..., fragment=...) at Source/WebCore/editing/EditorCommand.cpp:195
No locals.
#14 0x00007f85b9207df1 in WebCore::executeInsertHTML (frame=..., value=...) at Source/WebCore/editing/EditorCommand.cpp:508
No locals.
#15 0x00007f85b913c9df in WebCore::Document::execCommand (this=this@entry=0x7f853a276d00, commandName=..., userInterface=<optimized out>, value=...) at Source/WebCore/dom/Document.cpp:4227
No locals.
#16 0x00007f85b9e5d5dd in webkit_dom_document_exec_command (self=<optimized out>, command=<optimized out>, userInterface=userInterface@entry=0, value=0x558fd1496580 "<meta http-equiv=\"content-type\" content=\"text/html; charset=utf-8\"><span style=\"color: rgb(0, 0, 0); font-family: myriadpro-regular, Arial, sans-serif; font-size: 15px; font-style: normal; font-varian"...) at DerivedSources/webkitdom/WebKitDOMDocument.cpp:1157
        state = {m_previousState = 0x0}
        __PRETTY_FUNCTION__ = "gboolean webkit_dom_document_exec_command(WebKitDOMDocument*, const gchar*, gboolean, const gchar*)"
        item = 0x7f853a276d00
        convertedCommand = {m_impl = {m_ptr = 0x7f853a45fa50}}
        convertedValue = {m_impl = {m_ptr = 0x7f853a278700}}
        result = <optimized out>
#17 0x00007f85bfb7471b in e_html_editor_view_exec_command (view=view@entry=0x558fd0302790, command=command@entry=E_HTML_EDITOR_VIEW_COMMAND_INSERT_HTML, value=value@entry=0x558fd1496580 "<meta http-equiv=\"content-type\" content=\"text/html; charset=utf-8\"><span style=\"color: rgb(0, 0, 0); font-family: myriadpro-regular, Arial, sans-serif; font-size: 15px; font-style: normal; font-varian"...) at e-html-editor-view.c:8915
        document = <optimized out>
        cmd_str = <optimized out>
        has_value = <optimized out>
        __func__ = "e_html_editor_view_exec_command"
#18 0x00007f85bfb638ab in e_html_editor_selection_insert_html (selection=0x558fd15c6c90, html_text=0x558fd1496580 "<meta http-equiv=\"content-type\" content=\"text/html; charset=utf-8\"><span style=\"color: rgb(0, 0, 0); font-family: myriadpro-regular, Arial, sans-serif; font-size: 15px; font-style: normal; font-varian"...) at e-html-editor-selection.c:5673
        view = 0x558fd0302790
        command = E_HTML_EDITOR_VIEW_COMMAND_INSERT_HTML
        ev = 0x558fd13c0e00
        html_mode = -1
        __func__ = "e_html_editor_selection_insert_html"
#19 0x00007f859c2caca4 in e_composer_paste_html (r=<optimized out>, clipboard=<optimized out>) at e-composer-private.c:533
        editor = <optimized out>
        view = 0x558fd0302790
        editor_selection = 0x558fd15c6c90
        html = 0x558fd1496580 "<meta http-equiv=\"content-type\" content=\"text/html; charset=utf-8\"><span style=\"color: rgb(0, 0, 0); font-family: myriadpro-regular, Arial, sans-serif; font-size: 15px; font-style: normal; font-varian"...
        __func__ = "e_composer_paste_html"
#20 0x00007f85b7548d61 in request_targets_received_func (clipboard=0x558fcf7f5ee0, selection_data=selection_data@entry=0x7ffeb58e68a0, data=data@entry=0x558fd14b6fc0) at gtkclipboard.c:1325
        info = 0x558fd14b6fc0
        targets = 0x558fd0856fd0
        n_targets = 8
#21 0x00007f85b7548ff9 in selection_received (widget=0x558fcf5d1220, selection_data=0x7ffeb58e68a0, time=<optimized out>) at gtkclipboard.c:960
        request_info = 0x558fd1024e20
#22 0x00007f85b5b6c7a5 in g_closure_invoke (closure=0x558fcf1e9be0, return_value=return_value@entry=0x0, n_param_values=3, param_values=param_values@entry=0x7ffeb58e6530, invocation_hint=invocation_hint@entry=0x7ffeb58e64b0) at gclosure.c:801
        marshal = <optimized out>
        marshal_data = <optimized out>
        in_marshal = 0
        real_closure = 0x558fcf1e9bc0
        __func__ = "g_closure_invoke"
#23 0x00007f85b5b7e851 in signal_emit_unlocked_R (node=node@entry=0x558fccc28bc0, detail=detail@entry=0, instance=instance@entry=0x558fcf5d1220, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffeb58e6530) at gsignal.c:3627
        tmp = <optimized out>
        handler = 0x558fcf1e8f00
        accumulator = 0x0
        emission = {next = 0x7ffeb58e6ad0, instance = 0x558fcf5d1220, ihint = {signal_id = 70, detail = 0, run_type = G_SIGNAL_RUN_FIRST}, state = EMISSION_RUN, chain_type = 4}
        class_closure = 0x558fccc28b30
        handler_list = 0x558fcf1e8f00
        return_accu = 0x0
        accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
        signal_id = 70
        max_sequential_handler_number = 110677
        return_value_altered = 0
#24 0x00007f85b5b87530 in g_signal_emit_valist (instance=instance@entry=0x558fcf5d1220, signal_id=signal_id@entry=70, detail=detail@entry=0, var_args=var_args@entry=0x7ffeb58e6768) at gsignal.c:3383
        instance_and_params = 0x7ffeb58e6530
        signal_return_type = <optimized out>
        param_values = 0x7ffeb58e6548
        node = <optimized out>
        i = <optimized out>
        n_params = <optimized out>
        __func__ = "g_signal_emit_valist"
#25 0x00007f85b5b87dc5 in g_signal_emit_by_name (instance=0x558fcf5d1220, detailed_signal=detailed_signal@entry=0x7f85b75c3e83 "selection-received") at gsignal.c:3479
        var_args = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 0x7ffeb58e68a0, reg_save_area = 0x7ffeb58e67b0}}
        detail = 0
        signal_id = 70
        itype = 94076144637376
        __func__ = "g_signal_emit_by_name"
#26 0x00007f85b746dd13 in gtk_selection_retrieval_report (info=info@entry=0x558fd1a7aef0, type=<optimized out>, format=<optimized out>, buffer=<optimized out>, length=length@entry=64, time=30218102) at gtkselection.c:3033
        data = {selection = 0x45, target = 0x95, type = 0x4, format = 32, data = 0x558fd14d96b0 "\225", length = 64, display = 0x558fccbf6020}
#27 0x00007f85b7471cbd in _gtk_selection_notify (widget=<optimized out>, event=0x558fd12b72f0) at gtkselection.c:2837
        tmp_list = 0x7f8534ecbd20
        info = 0x558fd1a7aef0
        window = <optimized out>
        buffer = 0x558fd14d96b0 "\225"
        length = 64
        type = 0x4
        format = 32
#28 0x00007f85b73e5fda in _gtk_marshal_BOOLEAN__BOXEDv (closure=0x558fccc28790, return_value=0x7ffeb58e6b00, instance=<optimized out>, args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x558fccc287c0) at gtkmarshalers.c:131
        cc = <optimized out>
        data1 = <optimized out>
        data2 = <optimized out>
        callback = <optimized out>
        arg0 = 0x558fd12b72f0
        args_copy = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 0x7ffeb58e6cb0, reg_save_area = 0x7ffeb58e6bf0}}
        v_return = <optimized out>
        __func__ = "_gtk_marshal_BOOLEAN__BOXEDv"
#29 0x00007f85b5b6c9d4 in _g_closure_invoke_va (closure=closure@entry=0x558fccc28790, return_value=return_value@entry=0x7ffeb58e6b00, instance=instance@entry=0x558fcf5d1220, args=args@entry=0x7ffeb58e6bd0, n_params=<optimized out>, param_types=0x558fccc287c0) at gclosure.c:864
        marshal = <optimized out>
        marshal_data = <optimized out>
        in_marshal = 0
        real_closure = 0x558fccc28770
        __func__ = "_g_closure_invoke_va"
#30 0x00007f85b5b86dd3 in g_signal_emit_valist (instance=0x558fcf5d1220, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffeb58e6bd0) at gsignal.c:3292
        return_accu = 0x7ffeb58e6b00
        accu = {g_type = 20, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
        accumulator = 0x558fccc287e0
        emission = {next = 0x0, instance = 0x558fcf5d1220, ihint = {signal_id = 69, detail = 0, run_type = G_SIGNAL_RUN_LAST}, state = EMISSION_RUN, chain_type = 94076144637376}
        signal_id = 69
        instance_type = 94076144637376
        emission_return = {g_type = 20, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
        rtype = 20
        static_scope = 0
        fastpath_handler = <optimized out>
        closure = <optimized out>
        run_type = <optimized out>
        l = <optimized out>
        fastpath = <optimized out>
        instance_and_params = <optimized out>
        signal_return_type = <optimized out>
        param_values = <optimized out>
        node = <optimized out>
        i = <optimized out>
        n_params = <optimized out>
        __func__ = "g_signal_emit_valist"
#31 0x00007f85b5b878ff in g_signal_emit (instance=instance@entry=0x558fcf5d1220, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3439
        var_args = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7ffeb58e6cb0, reg_save_area = 0x7ffeb58e6bf0}}
#32 0x00007f85b75234bc in gtk_widget_event_internal (widget=0x558fcf5d1220, event=0x558fd12b72f0) at gtkwidget.c:7692
        signal_num = <optimized out>
        return_val = 0
        handled = 0
        event = 0x558fd12b72f0
        widget = 0x558fcf5d1220
#33 0x00007f85b73e50b6 in gtk_main_do_event (event=0x558fd12b72f0) at gtkmain.c:1795
        event_widget = 0x558fcf5d1220
        grab_widget = 0x558fcf5d1220
        topmost_widget = <optimized out>
        window_group = 0x558fd0131840
        rewritten_event = <optimized out>
        device = 0x0
        tmp_list = <optimized out>
        __func__ = "gtk_main_do_event"
#34 0x00007f85b6f5de92 in gdk_event_source_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at gdkeventsource.c:369
        display = <optimized out>
        event = <optimized out>
#35 0x00007f85b586de3a in g_main_dispatch (context=0x558fccbe7840) at gmain.c:3154
        dispatch = 0x7f85b6f5de70 <gdk_event_source_dispatch>
        prev_source = 0x0
        was_in_call = 0
        user_data = 0x0
        callback = 0x0
        cb_funcs = 0x0
        cb_data = 0x0
        need_destroy = <optimized out>
        source = 0x558fccbe7750
        current = 0x558fccc54d40
        i = 0
#36 g_main_context_dispatch (context=context@entry=0x558fccbe7840) at gmain.c:3769
No locals.
#37 0x00007f85b586e1d0 in g_main_context_iterate (context=0x558fccbe7840, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
        max_priority = 0
        timeout = 0
        some_ready = 1
        nfds = <optimized out>
        allocated_nfds = 4
        fds = 0x558fcf754da0
#38 0x00007f85b586e4f2 in g_main_loop_run (loop=0x558fcf32d5d0) at gmain.c:4034
        __func__ = "g_main_loop_run"
#39 0x00007f85b73e4325 in gtk_main () at gtkmain.c:1241
        loop = 0x558fcf32d5d0
#40 0x0000558fcc45d089 in main (argc=1, argv=0x7ffeb58e7008) at main.c:660
        shell = 0x558fcccc11e0
        settings = <optimized out>
        error = 0x0

We also have a valgrind log (available on request); I think the main interesting part is:

==21341== Conditional jump or move depends on uninitialised value(s)
==21341==    at 0xCEBA8FF: WTF::fastFree(void*) (in /usr/lib64/libjavascriptcoregtk-3.0.so.0.16.18)
==21341==    by 0xB15E1A4: ??? (in /usr/lib64/libwebkitgtk-3.0.so.0.22.16)
==21341==    by 0xB15DA6B: ??? (in /usr/lib64/libwebkitgtk-3.0.so.0.22.16)
==21341==    by 0xB15F451: ??? (in /usr/lib64/libwebkitgtk-3.0.so.0.22.16)
==21341==    by 0xA9F7B32: ??? (in /usr/lib64/libwebkitgtk-3.0.so.0.22.16)
==21341==    by 0xA9F8173: ??? (in /usr/lib64/libwebkitgtk-3.0.so.0.22.16)
==21341==    by 0xA9FA28D: ??? (in /usr/lib64/libwebkitgtk-3.0.so.0.22.16)
==21341==    by 0xA9FA9D1: ??? (in /usr/lib64/libwebkitgtk-3.0.so.0.22.16)
==21341==    by 0xB71B5DC: webkit_dom_document_exec_command (in /usr/lib64/libwebkitgtk-3.0.so.0.22.16)
==21341==    by 0x5173D20: ??? (in /usr/lib64/evolution/libevolution-util.so)
==21341==    by 0xF1D4BEA: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.4600.2)
==21341==    by 0xF1B6B7A: ??? (in /usr/lib64/libgobject-2.0.so.0.4600.2)

Revision history for this message

In bugs.webkit.org/ #155694, Mcatanzaro (mcatanzaro) wrote on 2016-04-02:

#14

Comment from the downstream bug:

"""Ok, I've done a bit more experimentation and I think I can give you some additional info, hopefully even useful!

If I have my email format set to Plain Text, I cannot get the crash that I reported regardless of how or what I copy/paste.

If I have the email format set to HTML, I cannot get the crash if I copy plain text into the email. However, If I copy HTML text into the email I can reproduce the crash every time.

The specific steps to reproduce are as follows:

- Click New > Compose Email Message
- Enter any email address in 'To:'
- Enter anything into 'Subject"
- Go to any webpage, and highlight a few lines
- Click 'ctrl c'
- Place cursor into the body of the open Compose Message window
- Click 'ctrl v'
- Crash will occur 100% of time for me.

The trick seems to be to have the email formatting to be HTML and then copy-paste HTML content.

Hopefully this is helpful."""

Seems it's 100% reproducible for some users, but not for others.

Revision history for this message

In bugs.webkit.org/ #155694, Tpopela (tpopela) wrote on 2016-04-04:

#15

(In reply to comment #7)
> Seems it's 100% reproducible for some users, but not for others.

It would be easy to bisect to the bad commit, but when we can't reproduce this on our machines:/.

Revision history for this message

In bugs.webkit.org/ #155694, Tpopela (tpopela) wrote on 2016-04-04:

#16

With Milan we figured out that this backported change http://trac.webkit.org/changeset/197274 had a follow-up (security bug) http://trac.webkit.org/changeset/165044 that was not backported and is causing the crash.

Revision history for this message

In bugs.webkit.org/ #155694, Mcatanzaro (mcatanzaro) wrote on 2016-04-04:

#17

Just an FYI, we're up to 1,871 reports of this crash, i.e. we got over 500 new reports over this past weekend.

Revision history for this message

In bugs.webkit.org/ #155694, Cgarcia-f (cgarcia-f) wrote on 2016-04-04:

#18

(In reply to comment #10)
> Just an FYI, we're up to 1,871 reports of this crash, i.e. we got over 500
> new reports over this past weekend.

I'll fix t and make a new release as soon as I find the time

Revision history for this message

In bugs.webkit.org/ #155694, Cgarcia-f (cgarcia-f) wrote on 2016-04-10:

#19

Patch backported to 2.4 branch in r199282. Thanks!

Revision history for this message

Thiago Martins (martinx) wrote on 2016-04-13:

#1

Dependencies.txt Edit (11.8 KiB, text/plain; charset="utf-8")
Disassembly.txt Edit (659 bytes, text/plain; charset="utf-8")
JournalErrors.txt Edit (163.8 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (305 bytes, text/plain; charset="utf-8")
ProcMaps.txt Edit (167.2 KiB, text/plain; charset="utf-8")
ProcStatus.txt Edit (970 bytes, text/plain; charset="utf-8")
Registers.txt Edit (874 bytes, text/plain; charset="utf-8")
Stacktrace.txt Edit (5.2 KiB, text/plain; charset="utf-8")
ThreadStacktrace.txt Edit (25.8 KiB, text/plain; charset="utf-8")

Revision history for this message

Apport retracing service (apport) wrote on 2016-04-13:

#2

StacktraceTop:
WebCore::HTMLElement::parseAttribute (this=0x557263c7e070, name=..., value=...) at ../Source/WebCore/html/HTMLElement.cpp:349
WebCore::Element::attributeChanged (this=0x557263c7e070, name=..., oldValue=..., newValue=...) at ../Source/WebCore/dom/Element.cpp:1097
WebCore::Element::didModifyAttribute (this=this@entry=0x557263c7e070, name=..., oldValue=..., newValue=...) at ../Source/WebCore/dom/Element.cpp:2851
WebCore::Element::setAttributeInternal (this=0x557263c7e070, index=<optimized out>, name=..., newValue=..., inSynchronizationOfLazyAttribute=<optimized out>) at ../Source/WebCore/dom/Element.cpp:1075
WebCore::CompositeEditCommand::applyCommandToComposite (this=this@entry=0x7f9b5b7c27e0, prpCommand=...) at ../Source/WebCore/editing/CompositeEditCommand.cpp:278

Revision history for this message

Apport retracing service (apport) wrote on 2016-04-13: Stacktrace.txt

#3

Stacktrace.txt Edit (12.1 KiB, text/plain)

Revision history for this message

Apport retracing service (apport) wrote on 2016-04-13: StacktraceSource.txt

#4

StacktraceSource.txt Edit (5.1 KiB, text/plain)

Revision history for this message

Apport retracing service (apport) wrote on 2016-04-13: ThreadStacktrace.txt

#5

ThreadStacktrace.txt Edit (34.9 KiB, text/plain)

Changed in evolution (Ubuntu):
importance:	Undecided → Medium
tags:	removed: need-amd64-retrace

Revision history for this message

Sebastien Bacher (seb128) wrote on 2016-04-22:

#6

that bug is fixed in 2.4.11 upstream, that should probably be SRUed

information type:	Private → Public
affects:	evolution (Ubuntu) → webkitgtk (Ubuntu)
Changed in webkitgtk (Ubuntu):
importance:	Medium → High
status:	New → Fix Committed

Bug Watch Updater (bug-watch-updater) on 2016-04-22

Changed in webkit-open-source:
importance:	Unknown → Medium
status:	Unknown → Fix Released

Revision history for this message

Amr Ibrahim (amribrahim1987) wrote on 2016-04-25:

#20

Exactly, Trusty also needs 2.4.11.

Amr Ibrahim (amribrahim1987) on 2016-04-27

Changed in webkitgtk (Ubuntu):
status:	Fix Committed → Confirmed

Revision history for this message

Van Stokes, Jr. (vstokes) wrote on 2016-05-10:

#21

This problem still persists in Gnome Ubuntu 16.04 X64:

$ uname -a
Linux eerlon 4.4.0-22-generic #39-Ubuntu SMP Thu May 5 16:53:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04 LTS
Release: 16.04
Codename: xenial

$ evolution --version
evolution 3.18.5.2

Revision history for this message

Amr Ibrahim (amribrahim1987) wrote on 2016-05-11:

#22

Please merge webkitgtk 2.4.11-1 from Debian Bug #1571071

Sebastien Bacher (seb128) on 2016-05-13

tags:

added: desktop-trello-import

Revision history for this message

Will Cooke (willcooke) wrote on 2016-05-13: Automatically added comment

#23

Added to Trello: https://trello.com/c/97rmunED/13-bug-1570110-evolution-crashed-with-sigsegv-while-pasting-from-clipboard

tags:

removed: desktop-trello-import

Sebastien Bacher (seb128) on 2016-05-13

Changed in webkitgtk (Ubuntu):
status:	Confirmed → In Progress

Sebastien Bacher (seb128) on 2016-05-13

description:

updated

Revision history for this message

Sebastien Bacher (seb128) wrote on 2016-05-13:

#24

I uploaded 2.4.11 to yakkety and as a SRU to 16.04

Revision history for this message

Amr Ibrahim (amribrahim1987) wrote on 2016-05-13:

#25

Thanks Sebastien. I guess 14.04 is also affected.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2016-05-13:

#26

This bug was fixed in the package webkitgtk - 2.4.11-0ubuntu1

---------------
webkitgtk (2.4.11-0ubuntu1) yakkety; urgency=medium

  * New upstream version:
    - "Fix a crash when changing elment attributes with DOM bindings"
      which impacts the evolution composer for example (lp: #1570110)
  * debian/patches/fix-arm64-build.patch:
    - dropped, the issue is resolved in the new version

-- Sebastien Bacher <email address hidden> Fri, 13 May 2016 10:52:06 +0200

Changed in webkitgtk (Ubuntu):
status:	In Progress → Fix Released

Revision history for this message

Martin Pitt (pitti) wrote on 2016-05-18: Please test proposed package

#27

Hello Thiago, or anyone else affected,

Accepted webkitgtk into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/webkitgtk/2.4.11-0ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags:	added: verification-needed
Changed in webkitgtk (Ubuntu Xenial):
status:	New → Fix Committed

Mathew Hodson (mhodson) on 2016-05-19

Changed in webkitgtk (Ubuntu Xenial):
importance:	Undecided → High
tags:	added: regression-update

Mathew Hodson (mhodson) on 2016-05-19

tags:

added: trusty

Revision history for this message

Sebastien Bacher (seb128) wrote on 2016-05-27:

#28

the steps to trigger the segfault doesn't hit the bug here neither with the old version nor the new one but I've been using evolution on different html files with the old and new version and have no issue and no visible regression. Empathy works fine as well

tags:

added: verification-done
removed: verification-needed

Revision history for this message

Launchpad Janitor (janitor) wrote on 2016-05-30:

#29

This bug was fixed in the package webkitgtk - 2.4.11-0ubuntu0.1

---------------
webkitgtk (2.4.11-0ubuntu0.1) xenial; urgency=medium

  * New upstream version:
    - "Fix a crash when changing elment attributes with DOM bindings"
      which impacts the evolution composer for example (lp: #1570110)
  * debian/patches/fix-arm64-build.patch:
    - remove, this has been fixed upstream.

-- Sebastien Bacher <email address hidden> Fri, 13 May 2016 10:52:06 +0200

Changed in webkitgtk (Ubuntu Xenial):
status:	Fix Committed → Fix Released

Revision history for this message

Martin Pitt (pitti) wrote on 2016-05-30: Update Released

#30

The verification of the Stable Release Update for webkitgtk has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message

Adrian Bunk (bunk) wrote on 2016-07-14:

#31

I have re-added the Ubuntu Stable Release Updates Team:

As was already mentioned here, this regression was also introduced in trusty.

The same fix is therefore required in trusty, and in other supported releases that got the 2.4.10 security update.

Brian Murray (brian-murray) on 2016-07-14

Changed in webkitgtk (Ubuntu Trusty):
assignee:	nobody → Sebastien Bacher (seb128)

Revision history for this message

Launchpad Janitor (janitor) wrote on 2016-07-16:

#32

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in webkitgtk (Ubuntu Trusty):
status:	New → Confirmed

Revision history for this message

jamina1 (jamina1) wrote on 2016-08-03:

#33

I can't get it to add Wily, but I'm on Xubuntu Wily and I have the same problem. Great that it's been fixed in Xenial, but I need it backported :(

no longer affects:	wily (Ubuntu)
no longer affects:	wily (Ubuntu Trusty)
no longer affects:	wily (Ubuntu Xenial)

Revision history for this message

Brian Murray (brian-murray) wrote on 2016-08-03:

#34

Wily recently reached End of Life and is no longer supported so this will not be fixed in that release.

Sebastien Bacher (seb128) on 2019-09-20

Changed in webkitgtk (Ubuntu Trusty):
status:	Confirmed → Won't Fix
assignee:	Sebastien Bacher (seb128) → nobody

Ubuntu
webkitgtk package

evolution crashed with SIGSEGV, while pasting from clipboard

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

	Status	Importance	Assigned to
WebKit	Fix Released	Medium	auto-bugs.webkit.org #155694
webkitgtk (Ubuntu)	Fix Released	High	Unassigned
Trusty	Won't Fix	Undecided	Unassigned
Xenial	Fix Released	High	Unassigned

Ubuntuwebkitgtk package

evolution crashed with SIGSEGV, while pasting from clipboard

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
webkitgtk package