Bug 92310 – Href attribute with javascript protocol is stripped when content is pasted into a XML document

• Component: DOM
• Status: RESOLVED FIXED

[Ryosuke Niwa]

When we paste a HTML content into a XML document, we end up stripping href content attribute altogether instead of emptying it out like we do on HTML documents.

[Ryosuke Niwa]

editing/pasteboard/paste-noscript-xhtml.xhtml already tests behavior but the output is hard to read, so I'm going to fix that first in the bug 92307.

[Ryosuke Niwa]

*** Bug 92329 has been marked as a duplicate of this bug. ***

[Ryosuke Niwa]

Created attachment 154530 [details]
Fixes the bug

[Early Warning System Bot]

Comment on attachment 154530 [details]
Fixes the bug

Attachment 154530 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/13361285

[WebKit Review Bot]

Comment on attachment 154530 [details]
Fixes the bug

Attachment 154530 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13342544

New failing tests:
svg/custom/missing-xlink.svg

[WebKit Review Bot]

Created attachment 154539 [details]
Archive of layout-test-results from gce-cr-linux-08

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-08  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid

[WebKit Review Bot]

Comment on attachment 154530 [details]
Fixes the bug

Attachment 154530 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13349554

New failing tests:
svg/custom/missing-xlink.svg

[WebKit Review Bot]

Created attachment 154552 [details]
Archive of layout-test-results from gce-cr-linux-05

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-05  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid

[Adam Barth]

Comment on attachment 154530 [details]
Fixes the bug

Makes sense.

[Ryosuke Niwa]

Created attachment 154719 [details]
Patch

[Adam Barth]

Comment on attachment 154719 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=154719&action=review

> Source/WebCore/dom/Element.cpp:787
> -                attribute.setValue(nullAtom);
> +                attribute.setValue(emptyAtom);

This change looks odd.  I guess we're using empty string rather than null when removing attributes?

> Source/WebCore/dom/Element.cpp:1465
> +bool Element::parseAttributeName(QualifiedName& out, const AtomicString& namespaceURI, const AtomicString& qualifiedName, ExceptionCode& ec)

We usually put out parameters at the end.  (I know the editing code is weird in this regard.)

[Adam Barth]

Comment on attachment 154719 [details]
Patch

rniwa convinced me that using "" won't go infinite for <iframe src>, so this is probably ok.  A natural followup would be to share code with XSS auditor since XSS auditor is a bit smarter about blocking attributes.

[Early Warning System Bot]

Comment on attachment 154719 [details]
Patch

Attachment 154719 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/13351890

[Ryosuke Niwa]

Committed r123788: <http://trac.webkit.org/changeset/123788>

[Radar WebKit Bug Importer]

<rdar://problem/13027931>