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

RESOLVED INVALID

Status

()

RESOLVED INVALID
14 years ago
7 years ago

People

(Reporter: ghost16825, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [good first bug])

Attachments

(1 attachment, 4 obsolete attachments)

(Reporter)

Description

14 years ago
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

14 years ago
confirming, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050401 Firefox/1.0+
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Page info: Links: Select all copy then paste in Notepad pastes in UNIX format → Links->Select all, Copy then paste in Notepad pastes in UNIX format
Version: unspecified → Trunk

Updated

13 years ago
Whiteboard: [goodfirstbug]

Comment 2

13 years ago
This seems to be fixed, not sure if the latest stable, but deer park fixes this
(Reporter)

Comment 3

13 years ago
(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

13 years ago
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.
Status: NEW → ASSIGNED

Updated

13 years ago
Assignee: bugs → gijskruitbosch+bugs
Status: ASSIGNED → NEW

Comment 5

13 years ago
Created attachment 201020 [details] [diff] [review]
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).
Attachment #201020 - Flags: review?(db48x)

Comment 6

13 years ago
Created attachment 201026 [details] [diff] [review]
New patch, less parens

New patch, including comments over IRC.
Attachment #201020 - Attachment is obsolete: true
Attachment #201026 - Flags: review?(db48x)
Attachment #201020 - Flags: review?(db48x)

Comment 7

13 years ago
Created attachment 201027 [details] [diff] [review]
New patch, window. removed
Attachment #201026 - Attachment is obsolete: true
Attachment #201027 - Flags: review?(db48x)
Attachment #201026 - Flags: review?(db48x)

Comment 8

13 years ago
Created attachment 201028 [details] [diff] [review]
Mirrored patch for seamonkey.
Attachment #201028 - Flags: review?(db48x)

Updated

13 years ago
Attachment #201027 - Flags: review?(db48x) → review+

Updated

13 years ago
Attachment #201028 - Flags: review?(db48x) → review+

Updated

13 years ago
Attachment #201027 - Flags: superreview?(bugs.mano)
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.
I'm anti-ifdef
Status: NEW → ASSIGNED
Comment on attachment 201027 [details] [diff] [review]
New patch, window. removed

No need for runtime checks - the Firefox version of this file is preprocessed.
Attachment #201027 - Flags: superreview?(bugs.mano) → superreview-

Comment 12

13 years ago
Created attachment 201345 [details] [diff] [review]
Patch with #ifdefs

Right. Now we use about twice as many lines, but at least there's no more runtime checks.
Attachment #201345 - Flags: superreview?(bugs.mano)
Attachment #201345 - Flags: review?(db48x)

Comment 13

13 years ago
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

13 years ago
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 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.
Attachment #201345 - Flags: superreview?(bugs.mano)
Attachment #201345 - Flags: review?(db48x)
Attachment #201345 - Flags: review-
Comment on attachment 201345 [details] [diff] [review]
Patch with #ifdefs

Hrm, comment 15 is wrong for BeOS (dunno about QNX).
Attachment #201345 - Flags: review-
Mac OS X should use traditional unix line-endings.

Comment 18

13 years ago
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.
Assignee: gijskruitbosch+bugs → nobody
Status: ASSIGNED → NEW

Updated

13 years ago
Attachment #201027 - Attachment is obsolete: true

Updated

13 years ago
Attachment #201345 - Attachment is obsolete: true

Comment 19

13 years ago
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

12 years ago
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.
Whiteboard: [goodfirstbug] → [good first bug]

Comment 21

8 years ago
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
We don't have a "Links"-tab in "Page Info" anymore.

This bug should be closed.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.