Last Comment Bug 677105 - <noscript> content cannot be copied to clipboard
: <noscript> content cannot be copied to clipboard
Product: Core
Classification: Components
Component: Widget (show other bugs)
: Trunk
: All All
-- normal (vote)
: mozilla8
Assigned To: Mats Palmgren (:mats)
Depends on:
  Show dependency treegraph
Reported: 2011-08-07 12:58 PDT by Stanimir Stamenkov
Modified: 2011-08-10 08:25 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

NOSCRIPT sample (641 bytes, text/html)
2011-08-07 12:58 PDT, Stanimir Stamenkov
no flags Details
fix (2.63 KB, patch)
2011-08-08 09:25 PDT, Mats Palmgren (:mats)
bzbarsky: review+
Details | Diff | Splinter Review

Description User image Stanimir Stamenkov 2011-08-07 12:58:40 PDT
Created attachment 551334 [details]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110731 SeaMonkey/2.3
Build ID: 20110731194239

Steps to reproduce:

While JavaScript is disabled, open the attached sample, select and copy *the complete content* (including the final dot) of the first <noscript> element to the clipboard, that is both of the following paragraphs:

    Select completely and copy both paragraphs to the clipboard.

    Then try to paste into a text editor.

As the sample suggest, then try to paste into a text editor.

Happens with current release as with latest nightly as well:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110807 Firefox/8.0a1

Actual results:

No content appeared with the paste operation.

Expected results:

The content of the <noscript> element just copied should have appeared in the text editor with the paste operation.
Comment 1 User image Stanimir Stamenkov 2011-08-07 13:05:17 PDT
This appears to happen with <noscript> elements containing two or more paragraphs (<p> elements) after selecting them completely.  Omitting one paragraph or just the last character in the last paragraph from selection, copies (and then pastes) the selected content fine.

Selecting completely, copying and pasting single paragraph, being the only content of a <noscript> element, also works fine.
Comment 2 User image Stanimir Stamenkov 2011-08-07 13:13:19 PDT
Don't know how this might be related but, selecting all of the content in the attached sample, copying it, then pastes just the heading "Copy noscript content test".
Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2011-08-08 09:01:53 PDT
This isn't actually a serializer bug.

nsHTMLFormatConverter::ConvertFromHTMLToUnicode (which is called via nsCopySupport::HTMLCopy calling SelectionCopyHelper calling nsHTMLFormatConverter::Convert) initializes a plaintext serializer like so:

294       textSink->Initialize(&aToStr, nsIDocumentEncoder::OutputSelectionOnly
295                            | nsIDocumentEncoder::OutputAbsoluteLinks, 0);

note conspicuous lack of OutputNoScriptContent.   Compare the document encoder or web browser persist, which set that flag if script is disabled on the document or if told to do so explicitly respectively.

After that the serializer does exactly what it's been told to do.

This code looks like it hasn't changed from jst's initial checkin of nsHTMLFormatConverter back in Oct 2000...

The problem, of course, is that it's converting an HTML string to a plaintext string.  By this point it has no idea what document the HTML came from originally, as far as I can tell.
Comment 4 User image Mats Palmgren (:mats) 2011-08-08 09:25:24 PDT
Created attachment 551480 [details] [diff] [review]

I think can we can make nsHTMLFormatConverter::ConvertFromHTMLToUnicode
assume that the input HTML string is already filtered visavi noscript
and noframes - that is, if they occur in the input string they should be
included in the result.

Writing a test for that seems hard with script disabled.
I've added a test for the opposite...
Comment 5 User image Boris Zbarsky [:bz] (still a bit busy) 2011-08-08 10:18:30 PDT
Comment on attachment 551480 [details] [diff] [review]

Ah, excellent.  r=me

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