Closed Bug 726605 Opened 12 years ago Closed 11 years ago

Troubleshooting Information: Copy and Paste Should Work As If Copying from a Web Page

Categories

(Toolkit :: General, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla24
Tracking Status
firefox23 --- affected

People

(Reporter: david, Unassigned)

References

Details

Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20120208 SeaMonkey/2.7.1

On the browser menu bar, select [Help > Troubleshooting Information].  On the Troubleshooting Information page, mark all or a portion of either the Extensions or the Modified Preferences table, manually copy, and then paste into an ASCII editor.  The result is one long line of text without any separators between fields and without any explicit line-breaks.  

On the Troubleshooting Information page, select the "Copy all to clipboard" button.  Paste the result into an ASCII editor.  The table rows appear as columns.  

Go to my <http://www.rossde.com/internet/ASCIIvsHTML.html>.  Mark the entire table at the end, copy it, and paste it into an ASCII editor.  The fields separated by tab characters, causing the columns to appear in vertical lines; and each row ends with an explicit line-break.  The same result for the table occurs if the entire page is selected (right-click and select "Select All" from the pull-down context menu), copied, and pasted.  

Copying the Troubleshooting Information page should behave as the table in my Web page.
Bug #727521 for Thunderbird addresses this same problem in the code forked from the Toolkit component addressed here.
When copied, the display is apparently formatted for pasting into a spread-sheet.  The user should be given the option between comma-separated formatting (for spread-sheets) and plain ASCII.
This is due to a difference in how Firefox serializes HTML and XHTML.  Apparently (via gdb) HTML uses nsPlainTextSerializer, which adds line breaks after TR and tabs between TDs, e.g.,

http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsPlainTextSerializer.cpp?rev=c4f83d9d8243#539

I don't know what serializer is used for XHTML, but it's not that one (again via gdb).

about:support is XHTML, and the link in comment 0 is HTML, hence the difference.  You can compare these two identical pages, one having an xhtml extension and the other an html extension:

http://people.mozilla.com/~adw/table.html
http://people.mozilla.com/~adw/table.xhtml

We can't use HTML for about:support, and I'm not sure it's a good idea to special-case XHTML in the XML serializer, but maybe we could just add tab and newline text nodes between TDs and TRs when the about:support tables are generated.
Well, that's not quite right.  They both use nsPlainTextSerializer.  HTML gets text/unicode and text/plain clipboard flavors, but XHTML gets only text/unicode [1].  (In the XHTML case, bIsHTMLCopy in [1] is false.)  Unlike text/plain, text/unicode is serialized with the nsIDocumentEncoder::OutputRaw flag, which skips the pretty printing stuff -- no line breaks or tabs [2].

[1] http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsCopySupport.cpp#70
[2] http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsPlainTextSerializer.cpp#406
See also bug 723163?
Fixed by bug 723163.

(In reply to David E. Ross from comment #3)
> The user should be given the option between comma-separated
> formatting (for spread-sheets) and plain ASCII.

I don't think we're going to do this.
Status: NEW → RESOLVED
Closed: 11 years ago
Depends on: 723163
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → FIXED
The similar problem for about:crashes was fixed per bug #723163.  Furthermore, a fix for bug #857915 would facilitate fixing this one.  

This bug describes a problem in communicating a configuration when reporting a problem.  Such communication should be encouraged, but this problem discourages it.  

Resolved/Fixed is supposed to cite a specific code modification, but no such citation was given.  If Resolved/WontFix is intended, please state why.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The problem described in comment 0 has been fixed by the patch to bug 723163.  You are welcome to view the patch there to see the code modifications.

Bug 857915 is about pasting into a text/html-aware editor, not an "ASCII editor."  If you would now like to extend the scope of this bug to cover text/html as well as text/plain, then please instead file a new bug that depends on bug 857915.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
In which release will the fix appear?
Gecko 23.  I think.
Target Milestone: --- → mozilla23
Target Milestone: mozilla23 → mozilla24
You need to log in before you can comment on or make changes to this bug.