Closed Bug 24905 Opened 25 years ago Closed 24 years ago

Mac - Line breaks not correctly copied to clipboard

Categories

(Core :: DOM: Serializers, defect, P3)

Product:
Core
Component:
DOM: Serializers
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 56561
Milestone:
Future

People

(Reporter: elig, Assigned: akkzilla)

References

(
URL
)

Details

(Keywords: helpwanted, platform-parity) 

Akkana indicated this is a regression of a known bug, but I'm not sure of the 
number, so writing this up quickly. Using the 2000012108 build.

* If you copy the entire page on Mac OS, you'll see the box-characters where 
linebreaks should be.

* If you copy down to the "}", you won't see boxes --- there just won't be 
linebreaks.

* Works fine on Win32.

* Can't copy on Linux.
Copy works fine from the editor window; it's just in the browser window that it
doesn't work on linux.  The line breaks are coming through fine on linux when I
copy from an editor window.
QA Contact: paulmac → elig
Correction: I had tried this on a release build, but see different things on a

debug build; and not quite everything is fine on linux.



First, on a build (either from today or Friday), the lines outside the massive

nesting appear in the editor window as though they're separated by two newlines

instead of one.  This doesn't happen in the release build, only the debug build.

 Oddly, the extra newlines show up in OutputText from the editor, but not in

select all/copy/paste.

Second, select-all, copy, and paste as plaintext gets the text out of order and

shows an assert; filed bug 24912 on that.



(Neither of these issues directly relate to the issue in this bug, which is the

newline handling on mac.)
QA Contact: elig → paulmac
per our discussion, reassigning to akkana as the text doesn't seem to get 
converted to platform linebreaks in this instance (as it should) before it gets 
to the clipboard code.
Assignee: pinkerton → akkana
changing component.
Component: XP Toolkit/Widgets → Editor
Hope to look at this for M14.
Status: NEW → ASSIGNED
Target Milestone: M14
Adding "pp" keyword.
Keywords: pp
QA Assigning to self.
QA Contact: paulmac → elig
On Linux, NS_LINEBREAK is definitely being called for every linebreak; there is
no linebreak coming from the output code that is not going through NS_LINEBREAK.

I'll try to debug this on the Mac, but I'm skeptical that this is really a
problem in the output sink code.
How do I reproduce this on a mac?  If I copy out of the mozilla editor and paste
into bbedit, the line breaks all look fine.  Also, if I do Edit->Show Clipboard
from the Finder, the line breaks still look fine.
As requested...
	* Tested within Browser, rather than Editor

To reproduce:
	* Drag-select contents of page
	* Select "Copy" from the Edit menu
	* Go to the Finder, and select "Show Clipboard" from the Edit menu.

Reproduced box-characters using 2000012808 Mac OS build.

Not marked as beta1, bumping off to M15 so I can help with PDT+ bugs.
Target Milestone: M14 → M15
Summary: [PP] Mac - Line breaks not correctly copied to clipboard → Mac - Line breaks not correctly copied to clipboard
[Purely as a courtesy notice, saw this issue using the 2.14.00 Mac OS build in 
verifying 24912.]

Okay, I finally see this, but I don't know what it means.  I only see the boxes
on clipboard viewer; when I paste (e.g. into bbedit) everything is fine, when I
print (on stdout, which comes out on the console window) with Debug->Test
Selection, everything looks fine.  Clipboard viewer apparently wants something
different from what all the other apps can deal with.  This obviously can only
be debugged on a mac.  I need some help from a Mac expert.  Simon?  Pinkerton? 
What's different about the clipboard viewer's linebreak handling, and how do we
deal with it?
This probably doesn't need to be M16 since the only way of reproducing it is to
use the Mac clipboard viewer, and it seems to work okay with "real" apps.

Pinkerton, could you take a look at this and figure out what's different about
the clipboard viewer, and whether this should be considered a problem?
Assignee: akkana → pinkerton
Status: ASSIGNED → NEW
Target Milestone: M15 → M16
pushing off
Status: NEW → ASSIGNED
Target Milestone: M16 → M17
the reason this works fine in BBEdit is that BBEdit is smart enough to handle the 
non-mac line endings. Paste into SimpleText and you see the boxes. Moving back up 
to M16.
Target Milestone: M17 → M16
akk, i looked into the clipboard code and I am getting text that has 0x0A, which 
is not the mac linebreak character. Somewhere the conversion is not being 
correctly done _before_ it gets into the clipboard.

Pushing back to you. Hit me over the head with a bat if this is wrong.
Assignee: pinkerton → akkana
Status: ASSIGNED → NEW
Sigh.  Back to M17 -- not a feature item, only happens with a few apps, will
require Mac-specific debugging since it can't be reproduced anywhere else.
Status: NEW → ASSIGNED
Target Milestone: M16 → M17
no, it happens with _all_ apps that aren't development tools.

I'm willing to consider moving it up in priority if someone is seeing a case
where this actually causes problems with a real app.  I haven't seen any reports
of that so far.  I'm also willing to work on it any time if a Mac debugging
expert wants to give me a little handholding (I do want to learn how to debug
better on the Mac, but I get a bit confused by having to use the old debugger
with the new CW and how to get that all working right), or just tells me where
in nsHTMLToTXTSinkStream the 0x0A is getting past all the code that's supposed
to replace them with NS_LINE_BREAK.
simpletext and microsoft word are two "real" apps that this doesn't work in. if 
you want i can sit down with you and we can go through it.
Component: Editor → DOM to Text Conversion
Keywords: correctness
Target Milestone: M17 → M18
moving this to m19 for now -- not critical
Target Milestone: M18 → M19
moving out to future, this will just have to wait till the next release
Target Milestone: M19 → Future
forgot to add helpwanted
Keywords: helpwanted
Simon just found a great testcase for this, and we were able to pin down exactly
when it happened, at least in the case he reported in bug 56561.  There's a
patch attached to that bug which fixes the View Source case.  I would be very
interested to know if it fixes this case too.  I think it will, but if there are
still cases where you see incorrect linebreaks, please give me a testcase (I
think I know how to test these now).

Sorry it didn't make it in for rtm (though if someone wants to argue for it, the
fix is simple and should be safe).
Duping to the bug that has the patch attached.

*** This bug has been marked as a duplicate of 56561 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verified in 10/31 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.