519286 - Copy to Clipboard feature does not lay out properly - about:support page

Status: VERIFIED FIXED

(Firefox :: General, defect, P2)

Comment 1

[Marcia Knous [:marcia]]

Seen while running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b1pre) Gecko/20090926 Namoroka/3.6b1pre

STR:
1. Go to about:support
2. Select the "Copy to Clipboard" button
3. Paste the text into a document using TextEdit

Using 10.5 this works fine, using 10.6 it does not.

Comment 2

[Marcia Knous [:marcia]]

Attachment: Screenshot of copy to clipboard using 10.6

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Josh, Simon: any idea what might have changed between 10.5 and 10.6 here?

Comment 4

[Curtis Bartley [:cbartley]]

(In reply to comment #2)
> Created an attachment (id=403349) [details]
> Screenshot of copy to clipboard using 10.6

Marcia:  Have you tried pasting the text into another WYSIWYG application?  If you've got Microsoft Word installed you might try that.  Actually, even pasting into Gmail might be a good test.

This might be a long winded way of saying that I think the problem might be with TextEdit rather than with us.

From the look of the screenshot, it looks like it's an HTML paste rather than a plain-text paste.  The HTML is really just the innerHTML from a DIV element.  There's really no reason that it should be different from 10.5 to 10.6.  From the screenshot, it looks like bad table layout on TextEdit's part, although that's just guesswork since I don't have a 10.6 machine to test it on myself.

Comment 5

[Simon Montagu :smontagu]

FWIW I see this on 10.5 too. Anyway, I think Curtis is right and the problem is that TextEdit's table layout algorithm has problems with the long strings with no wordbreaks that occur in prefs. In OpenOffice it works fine.

Comment 6

[Curtis Bartley [:cbartley]]

(In reply to comment #5)
> FWIW I see this on 10.5 too. Anyway, I think Curtis is right and the problem is
> that TextEdit's table layout algorithm has problems with the long strings with
> no wordbreaks that occur in prefs. In OpenOffice it works fine.

I'm seeing it in TextEdit on 10.5 as well.  At the very least I think it's not 10.5 vs 10.6 thing.  We should probably try to test pasting into a number of different wysyiwyg apps to see if it's a common problem.  If other apps demonstrate similar problems, there may be things we can do on our end to compensate, such as truncating really long values.

Comment 8

[Tony Chung [:tchung]]

I tried this against a few other editors.
- Confirm what you guys see with TextEdit on mac 10.5
- on XP, notepad.exe puts all the data on one line.   If you word wrapping it doesnt help much
- on XP , Wordpad.exe displays the info in outline format.

Comment 9

[Curtis Bartley [:cbartley]]

Attachment: better formatting when using the "Copy all to clipboard" button

Pref values are truncated to 120 characters.  This greatly improves table layout when pasting into TextEdit.  This should apply whether the contents were copied using the "Copy all to clipboard" button or with a direct select text and copy.

The "Copy all to clipboard" button now uses CR/LF pairs for its plain text clipboard format.  This shouldn't matter on Mac or Linux but can be important when pasting into some Windows text editors (notably Notepad).  Text that is selected directly and copied never had this problem, although it suffers from some other less serious (and hard to correct) formatting issues.

Comment 10

[Curtis Bartley [:cbartley]]

(In reply to comment #8)

> - on XP , Wordpad.exe displays the info in outline format.

It looks like Wordpad doesn't accept HTML as a clipboard format.  Instead it uses the plain text format.

Comment 11

[Johnathan Nightingale [:johnath]]

Comment on attachment 405294 [details] [diff] [review]
better formatting when using the "Copy all to clipboard" button

>diff -r 18b3562dd2b7 browser/base/content/aboutSupport.xhtml

>@@ -271,16 +283,19 @@ function createTextForElement(elem) {
>   let textFragmentAccumulator = [];
>   generateTextForElement(elem, "", textFragmentAccumulator);
>   let text = textFragmentAccumulator.join("");
> 
>   // Trim extraneous whitespace before newlines, then squash extraneous
>   // blank lines.
>   text = text.replace(/[ \t]+\n/g, "\n");
>   text = text.replace(/\n\n\n*/g, "\n\n");

The patch looks fine, but can you (or your checkin-helper) fix this regex as well on your way past? /\n\n\n*/g will match "\n\n" and uselessly replace it with "\n\n". I think this should be /\n\n\n+/g

>+  
>+  // Actual CR/LF pairs are needed for some Windows text editors.
>+  text = text.replace(/\n/g, "\r\n");
> 
>   return text;
> }

Comment 12

[Curtis Bartley [:cbartley]]

Attachment: better formatting when using the "Copy all to clipboard" button, v2

Same as the v1 patch, but with the minor regex change johnath requested in comment #11.

Comment 13

[Marco Bonardo [:mak]]

http://hg.mozilla.org/mozilla-central/rev/ba3c88503495

Comment 14

[Dão Gottwald [:dao]]

Comment on attachment 406112 [details] [diff] [review]
 better formatting when using the "Copy all to clipboard" button, v2

>+  if (text.length > maxPrefValueLen)
>+    text = text.substring(0, maxPrefValueLen) + "…";

You want intl.ellipsis here.

Comment 15

[Curtis Bartley [:cbartley]]

(In reply to comment #14)
> (From update of attachment 406112 [details] [diff] [review])
> >+  if (text.length > maxPrefValueLen)
> >+    text = text.substring(0, maxPrefValueLen) + "…";
> 
> You want intl.ellipsis here.

I'll pick this up in bug 523337.

Comment 16

[Curtis Bartley [:cbartley]]

The v2 patch applies cleanly to branch as of a few minutes ago.

Comment 17

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5766f493fb05

Comment 18

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b3pre) Gecko/20091112 Namoroka/3.6b3pre 
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091111 Minefield/3.7a1pre
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091111 Minefield/3.7a1pre

Comment 19

[Robert H. Bernard]

The following relates to copy-paste FF versions on MacOS 10.4.11:
I am a newcomer to Mozilla/Firefox bugs, but I have discovered a possibly related copy-paste bug on that crept in between FF 2.0.0.1 and FF 3.5, and is still present in FF 3.6B4.  When copying a table from the BillPay section of BankofAmerica.com online banking.  In the process of copy of that table, and pasting into MS Excel X for Mac, the tabs previously present between fields on the clipboard are missing in FF 3.5 and FF 3.6B4.  Using FF 2.0.1, the tabs are present. With 3.5 and 3.6B4 Excel refuses to even paste.
I am able with any of the versions to paste the clipboard into Textedit and the tab characters are present in paste from FF 2.0.0.1 but not from FF 3.5 or FF 3.6B4.
I can supply details if requested. Bob