51744 - Copying text tagged as PRE in a TD in a TABLE should retain line breaks

Status: VERIFIED FIXED

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

Description

[Eric Hopper]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3lvm i586; en-US; m17) Gecko/20000807
BuildID:    2000080712

Attempting to cut & paste the public key off of this web page fails because the
line breaks are turned into spaces.  The entire key is wrapped in a PRE tag.
IMHO, PRE tags should preserve line breaks when you're cutting and pasting from
them.  Often they contain source code, or other things (like public keys) that
are line break sensitive.


Reproducible: Always
Steps to Reproduce:
1.Select entire public key from listed URL
2.Move to emacs window, or just a shell window where you've typed GPG import
3.paste


Actual Results:  All the text is smooshed together on one line with spaces in
place of the line breaks.


Expected Results:  Left the line breaks in so the text looked exactly like what
I had selected.

Comment 1

[Matthew T (active 1999-2002)]

This ain't user interface ... --> DOM to Text Conversion?

Comment 2

[Akkana Peck]

I see it, too, on slasdot.  But it's not just pre -- I made a simple test page
with pre, and newlines worked fine.
Turns out this only happens on <pre> tags within tables.  I'm not sure why yet
-- investigating.  This would be bad.

Comment 3

[Akkana Peck]

Attachment: Simple test case

Comment 4

[rubydoo123]

can wait, since it seems like it only happens when pre is within tables

Comment 5

[Matthew T (active 1999-2002)]

Is this relnoteable?

Comment 6

[timeless]

Clarifying summary. Adding keywords.
Hixie: is this important for w3 compliance?

Comment 7

[Hixie (not reading bugmail)]

timeless: I am not aware of any specification relating to the clipboard.

Comment 8

[Ben Bucksch (:BenB)]

I think, this should be fixed. Pretty much every webpage uses tables for layout,
so the <pre> is very likely to be in a table. nsbeta3.

Comment 9

[Ben Bucksch (:BenB)]

Hixie: you can are that the HTML->TXT converter is an HTML "renderer", and thus
all of the specs apply to it. (But I assume, Netscape meant only display when it
promised full HTML4 compliance :) .)

Comment 10

[rubydoo123]

sorry, this is pushed out till the next release

Comment 11

[rubydoo123]

talked with akkana, she explained this is dataloss and the user is unable to use 
the app with the public key -- the newline is required

Comment 12

[Akkana Peck]

Turns out this isn't a problem with output after all: the pre isn't getting
passed to the output system because it isn't in the selection. 
nsHTMLDocument.cpp includes code to treat pre the same way as H1, etc., e.g.
include it in the selection if its children are, but this doesn't seem to be
working, for some reason.

Ideally, this would be fixed on the noxif branch, but it doesn't currently work
there either.

Comment 13

[Phil Peterson]

PDT agrees P2 on data loss argument. Otherwise, probably a P3

Comment 14

[Akkana Peck]

I checked a fix in to the noxif branch; when that branch lands, this will be
fixed, otherwise, we'll need to figure out why it's not working in the old
code.  Marking dependency.

Comment 15

[rubydoo123]

moving this from nsbeta3+ to rtm, because the noxif is not getting in till then

Comment 16

[rubydoo123]

Akkana, please include the required information per the rtm checkin rules

Comment 17

[Akkana Peck]

It's somewhat academic: it's already part of the noxif branch.  In any case,
it's a major correctness problem: copy/paste should give you the correct
information.

Comment 18

[rubydoo123]

Akkana, please follow the checkin rules -- get a patch to fix the problems, get 
it super-reviewed, get module owner approval. The reviewer and module owner must 
make an entry in the bug, once all of that is done, remove the NEED INFO in the 
rtm+ block. I will then pop it to pdt for approval.

Comment 19

[rubydoo123]

removed the +, to fit with pdt rules

Comment 20

[Joe Francis]

well, kin already super reviewed as part of bug 50472.  And akkana is a module 
owner.  If you want a different module owner then I approve.  Kin, how bout you?

Comment 21

[Akkana Peck]

I guess since it's already sr'ed as part of noxif, and is already on the branch,
it's time to remove the NEED INFO.

Comment 22

[rubydoo123]

adding the + so pdt will see this one

Comment 23

[Michael La Guardia]

If this is already part of the noxif patch, then you don't need anything outside
of that bug.  Marking need info so that this can be verified after the noxif
landing.

Comment 24

[Akkana Peck]

Verified that it is indeed working on the trunk, will be fixed by the noxif
landing; adding an appropriate note in status whiteboard.

Comment 25

[Ben Bucksch (:BenB)]

I'm confused. If "it is indeed working on the trunk", why does it need fixing
("will be fixed by the noxif landing")? You always (until yesterday) spoke about
a "NOXIF branch". Did this branch land on the trunk and you're now speaking
about landing it on the N6.0 branch?

Comment 26

[Akkana Peck]

The noxif branch landed on the trunk over the weekend.  It's scheduled to land
on the NS branch soon (like probably tonight or tomorrow), at which point I will
pull, check to make sure this bug is still fixed, and mark it so.

Comment 27

[Kathleen :Brade]

I tried the original scenario reported and was able to paste successfully (with
line breaks).  This was on a Mac debug N6 branch build.  I'll hold off on
resolving this since Akkana may have a few other things to verify.

Comment 28

[Akkana Peck]

NoXIF landed -- this is fixed now, both branch and trunk.

Comment 29

[sujay]

verified in 10/17 build.

Comment 30

[Akkana Peck]

Sorry for the spam!  But apparently all these closed bugs need to have their
target milestones changed since M19 and M20 are going away.  Since they're
allready closed, I'm choosing M18.