Closed Bug 273741 Opened 20 years ago Closed 20 years ago

Copy from textarea truncated at first instance of <

Categories

(Core :: DOM: Serializers, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: ali, Assigned: David.R.Gardiner)

References

()

Details

(Keywords: dataloss, regression, testcase)

Attachments

(2 files, 1 obsolete file)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041207 Firefox/1.0+ Copying out of textareas is broken where you're copying a string that contains a '<' character. It is *sometimes* truncated starting with that character. Best illustrated by example: Example 1: Copying '2><foo bar baz' copies only '2>'. Example 2: Copying '<hello world>' copies '' (nothing). Example 3: Copying 'contains a '<' character' copies 'contains a '<' character'. (I don't know why it works here, but not for example 1 and 2)
I think this is bug 273657.
Not sure if its a dupe or not, will leave that call to someone who knows better. Also, when copying &lt;foo&gt; into a textarea, I get <foo>
Blocks: 273657
Note that this bug is in the right component, with the right ccs, so if someone feels the urge to dup, please dup bug 273657 here.
No longer blocks: 273657
*** Bug 273657 has been marked as a duplicate of this bug. ***
OK, so this was in fact caused by the checkin for bug 244685. The problem lies in the following lines in the patch for that bug: + // this string may still contain HTML formatting, so we need to remove that too. + nsCOMPtr<nsIFormatConverter> htmlConverter = do_CreateInstance(kHTMLConverterCID); + NS_ENSURE_TRUE(htmlConverter, NS_ERROR_FAILURE); ... etc For the case when bHTMLCopy is false, doing this is WRONG. It will parse plaintext (text in text/plain pages, text in form controls, etc) as HTML, which is totally the wrong thing to do.
Assignee: dom-to-text → david.gardiner
Blocks: 244685
OS: Windows XP → All
Hardware: PC → All
Flags: blocking1.8a6?
Status: NEW → ASSIGNED
Attached file test-case (deleted) —
textarea element with embedded < and >. -dave
Attached patch Fix plain text code path (obsolete) (deleted) — Splinter Review
This patch fixes the problem for me... thanks for spotting the bug and sorry about the inconvenience. -dave
Comment on attachment 168259 [details] [diff] [review] Fix plain text code path >+ nsCOMPtr<nsIFormatConverter> htmlConverter = nsnull; > > // sometimes we also need the HTML version > if (bIsHTMLCopy) { The |htmlConverter| declaration can be inside the |if|, can it not? r=me with that
Attachment #168259 - Flags: review+
No, as it is used later in the file (http://lxr.mozilla.org/seamonkey/source/content/base/src/nsCopySupport.cpp#141 ) It is only used within another if (bIsHTMLCopy) block though. -dave
Attachment #168259 - Flags: superreview?(neil.parkwaycc.co.uk)
Comment on attachment 168259 [details] [diff] [review] Fix plain text code path sr=me with these nits fixed: >+ nsCOMPtr<nsIFormatConverter> htmlConverter = nsnull; nsnull is already the default value, no need to explicitly specify it. >+ nsCOMPtr<nsISupportsString> plainHTML; >+ plainHTML = do_CreateInstance(NS_SUPPORTS_STRING_CONTRACTID); No point splitting this, just use nsCOMPtr<nsISupportsString> plainHTML(do_CreateInstance(NS_SUPPORTS_STRING_CONTRACTID)); >+ nsresult plainhtml_rv = plainHTML->SetData(textBuffer); You don't use this return value; no point creating a variable for it. >+ nsresult converted_rv = ConvertedData->GetData(plaintextBuffer); Or this one.
Attachment #168259 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Attached patch Fix plain text code path (deleted) — Splinter Review
Updated as per suggestions, I believe this patch is read to check in now. -dave
Attachment #168259 - Attachment is obsolete: true
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Flags: blocking1.8a6?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: