285400 - Links->Select all, Copy then paste in Notepad pastes in UNIX format

Status: RESOLVED INVALID

(Firefox :: Page Info Window, defect)

Description

[ghost16825]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050308 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050308 Firefox/1.0+

Tools -> Page Info -> Links -> Select all -> Copy
Paste in Notepad

Paste seems to work fine in other applications, only Notepad pastes in UNIX
format. (Boxes at the end of each link)


Reproducible: Always

Steps to Reproduce:
1. See details

Actual Results:  
eg.
https://bugzilla.mozilla.org/*Box*
https://bugzilla.mozilla.org/2/1.htm*Box*

Expected Results:  
https://bugzilla.mozilla.org/
https://bugzilla.mozilla.org/2/1.htm

Build configuration (was a Firefox nightly, but guarantee latest stable will do
the same thing):
Build platform
target
i586-pc-msvc

Build tools
Compiler 	Version 	Compiler flags
$(CYGWIN_WRAPPER) cl 	12.00.8804 	-TC -nologo -W3 -Gy -Fd$(PDBFILE)
$(CYGWIN_WRAPPER) cl 	12.00.8804 	-TP -nologo -W3 -Gy -Fd$(PDBFILE)

Configure arguments
--enable-application=browser --enable-optimize --disable-debug --disable-tests
--enable-static --disable-shared --enable-official-branding

Comment 1

[Nickolay_Ponomarev]

confirming, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050401 Firefox/1.0+

Comment 2

[Andrew Murphy]

This seems to be fixed, not sure if the latest stable, but deer park fixes this

Comment 3

[ghost16825]

(In reply to comment #2)
> This seems to be fixed, not sure if the latest stable, but deer park fixes this

Please re-confirm, as Deer Park Alpha 2( Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.8b4) Gecko/20050724 Firefox/1.0+ ) still exhibits this behaviour.

Comment 4

[:Gijs (he/him)]

I'm going to look into doing a patch this in the afternoon / evening. The change we need should happen here:

http://lxr.mozilla.org/seamonkey/source/browser/base/content/pageInfo.js#1087

That should figure out if we're on windows or os/2, and if we are, use \r\n as a line separator instead.

Comment 5

[:Gijs (he/him)]

Attachment: Patch to fix the issue depending on window.navigator.platform

Check the platform string for anything with either 'win' or 'os/2', and use a different line end for them.

Tested on windows xp pro, seems to work fine here, and I have no reason to assume it doesn't on other platforms (plus, I can't test it as the only OS I can work on atm is Windows).

Comment 6

[:Gijs (he/him)]

Attachment: New patch, less parens

New patch, including comments over IRC.

Comment 7

[:Gijs (he/him)]

Attachment: New patch, window. removed

Comment 8

[:Gijs (he/him)]

Attachment: Mirrored patch for seamonkey.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Standard practice in browser code is to use the preprocessor and ifdefs for platform specific code, instead of relying on run-time checks against navigator.platform.

Comment 10

[Daniel Brooks [:db48x]]

I'm anti-ifdef

Comment 11

[Asaf Romano (gone)]

Comment on attachment 201027 [details] [diff] [review]
New patch, window. removed

No need for runtime checks - the Firefox version of this file is preprocessed.

Comment 12

[:Gijs (he/him)]

Attachment: Patch with #ifdefs

Right. Now we use about twice as many lines, but at least there's no more runtime checks.

Comment 13

[:Gijs (he/him)]

Mike Pinkerton: It has been brought to my attention that (sometimes?) Mac OS expects \r line ends. Could you advise what line ends mac should get in this bug? I don't consider myself familiar with Mac enough to judge that myself.

Comment 14

[[e-mail]]

Rather than replicate these tests/ifdefs in every file using nsIClipboardHelper to copy a string, shouldn't we either a) fix the line endings in the clipboard helper (after all, it's not being much help right now) b) have a central CopyStringArrayToClipboard method which we only have to #ifdef once.

Comment 15

[Asaf Romano (gone)]

Comment on attachment 201345 [details] [diff] [review]
Patch with #ifdefs

OS X (read: not os 9) uses \n alone, so #ifdef XP_UNIX...#else..#endif should do.

Comment 16

[Asaf Romano (gone)]

Comment on attachment 201345 [details] [diff] [review]
Patch with #ifdefs

Hrm, comment 15 is wrong for BeOS (dunno about QNX).

Comment 17

[Mike Pinkerton (not reading bugmail)]

Mac OS X should use traditional unix line-endings.

Comment 18

[:Gijs (he/him)]

Reassigning to default per comment #14, with which I agree. However, I'm not capable of correctly making the changes Neil describes. Hence, I'll let someone else take this bug and fix it properly. Sorry for bugspam.

Comment 19

[:Gijs (he/him)]

I'm assuming the seamonkey people want to fix things as suggested in comment #14 as well, but in case they don't, leaving the patch un-obsoleted.

Comment 20

[Tae Kim]

Isn't there a global constant defined anywhere for endlines or a global constant file where we can add such a constant? I would imagine that endlines are used in a lot of other places. It would clean up the code if a constant was defined for endlines in one place with ifdef and that constant used instead of reevaluating every time you need to print out a line break.

Comment 21

[Phong]

This is in C++, so if there's some way to call it from JS, things can be solved systematically. The endline character is stored in eLinebreakPlatform.
http://mxr.mozilla.org/mozilla1.9.2/source/xpcom/io/nsLinebreakConverter.h

Comment 22

[Thomas Prip Vestergaard [:prip]]

We don't have a "Links"-tab in "Page Info" anymore.

This bug should be closed.