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
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
This seems to be fixed, not sure if the latest stable, but deer park fixes this
(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.
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
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).
Created attachment 201026 [details] [diff] [review] New patch, less parens New patch, including comments over IRC.
Created attachment 201027 [details] [diff] [review] New patch, window. removed
Created attachment 201028 [details] [diff] [review] Mirrored patch for seamonkey.
Attachment #201028 - Flags: review?(db48x)
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.
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-
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.
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.
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.
Comment on attachment 201345 [details] [diff] [review] Patch with #ifdefs Hrm, comment 15 is wrong for BeOS (dunno about QNX).
Mac OS X should use traditional unix line-endings.
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
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.
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.
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.