cut & paste from <pre> always adds <newline> at the end of pasted text

VERIFIED DUPLICATE of bug 98572

Status

()

Core
Selection
P3
normal
VERIFIED DUPLICATE of bug 98572
18 years ago
17 years ago

People

(Reporter: bjoern, Assigned: Joe Francis)

Tracking

Trunk
mozilla0.9.7
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [plntxt][QAHP])

(Reporter)

Description

18 years ago
when cutting & pasting text from a text (not html!) file to another application,
a <newline> is also created.

Comment 1

18 years ago
what buildid does your build have?

Comment 2

18 years ago
so you're copying text from a browser window which has a foo.txt loaded into the
content window? Or, your're copying text from a Composer window with a text file
loaded? Or, you're copying text from a Composer window which has some plain text
typed into the content area? Or, you're copying text from a plaintext email
you're recieved? Or, you're copying text from a message compose window you've
just typed palin text into?

Reporter, please provide clear and  specific steps to reproduce.  Please also
include the buildID you tested.  Thank you for testing mozilla and reporting bugs.
(Reporter)

Comment 3

18 years ago
my build has been 2000100409 ...

I copy text from the browser to a different application. HTML is fine
but plain text files ftp://ftp.dante.de/pub/tex/support/rmligs/README
don't work. To reproduce it just load the file into your mozilla, mark
some text with you left mouse button, paste it to a vi running in an
xterm with your middle mouse button. Sorry I didn't add a full
decription in the report but I thought this would be trivial to
reproduce.

Comment 4

18 years ago
*** Bug 56631 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
Confirming on linux cvs build 2000101321, this bug has been driving me crazy for
a while now.

Comment 6

18 years ago
Forgot to click Confirm bug. :)
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

18 years ago
Steps to reproduce:
Select text in urlbar.
Paste it into an xterm, for example, and notice that there is a newline.

I'm not sure which component this should go into.

Comment 8

18 years ago
*** Bug 56583 has been marked as a duplicate of this bug. ***

Comment 9

18 years ago
*** Bug 56695 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
I think this one is jfrancis (see #54851), duping my bug filed against him and
another one. If not, pass it on...
Assignee: asa → jfrancis

Updated

18 years ago
Component: Browser-General → Selection

Comment 11

18 years ago
The reporter said copy from a html file worked fine, but I see it
doesn't work on Win98.
qa for selection is my friend blake
QA Contact: doronr → blakeross

Comment 13

18 years ago
Akk: is this up you alley?

Comment 14

18 years ago
Suggest: OS=all since in bug 56631 is was also seen with Windows2000.

Updated

18 years ago
OS: Linux → All

Comment 15

18 years ago
Joe, is the follwoing covered by this bug?:

copying from urlbar or any textfield (like in bugzilla) into the composer gives
newline, text *in monospace*, newline. The formatting worries me most. It is
plaintext what I am pasting, and I want no formatting, not <pre>. Pasting into
another app, copying ther and pasting into Mozilla Composer works as expected.
All on Linux.

Comment 16

18 years ago
moving to future, until we get the fix dates down
Target Milestone: --- → Future

Comment 17

18 years ago
Filed bug 57041 about the problem mentioned.
(Assignee)

Comment 18

18 years ago
moz 0.9
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9

Comment 19

18 years ago
*** Bug 57031 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
*** Bug 57791 has been marked as a duplicate of this bug. ***

Comment 21

18 years ago
*** Bug 57915 has been marked as a duplicate of this bug. ***

Comment 22

18 years ago
 This also happens for text in <pre> blocks (in a browser window), such as in
these bug reports.
(Current Linux CVS trunk pull/build.)

 This also appears to happen for selections in non-<pre> text under some
situations: if the selection starts at the start of a new paragraph or a
new container, it appears to generate the newline on pasting. (Merely a
new line, from a <br>, doesn't seem to do it.) Eg: on this web page, selecting
'Bugzilla Bug' and pasting will generate a newline, but selecting 'Bug List:'
will not. Selecting 'Bug 55661 depends on' will, and so on.
*** Bug 64059 has been marked as a duplicate of this bug. ***
Added self to cc.

Comment 25

18 years ago
*** Bug 64159 has been marked as a duplicate of this bug. ***

Comment 26

18 years ago
I nominated 56135 for nsbeta1, and this is the same bug (not sure which Joe
wants to be the real bug and which one the dup), so I'll nominate this one as well.
Keywords: nsbeta1
*** Bug 64392 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 28

18 years ago
dup


*** This bug has been marked as a duplicate of 56135 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 29

18 years ago
Is this really a dup? Bug 56135 is about MailNews, this is about the Browser.
And bug 56135 is about copying from the Subject field, this bug is about
copying from/to anywhere in the browser.
(Assignee)

Comment 30

18 years ago
it's the same bug, really.

Comment 31

18 years ago
vrfy dup
Status: RESOLVED → VERIFIED
(Assignee)

Comment 32

18 years ago
reopening.  related issues in bug 56135 are fixed, but copying from pre's still 
exhibits this behavior, and will require a separate fix.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Summary: cut & paste from text files always adds <newline> at the end of pasted text → cut & paste from <pre> always adds <newline> at the end of pasted text

Comment 33

18 years ago
It's a bit complicated, because if I select across lines, I want to get the line
breaks (e.g. if I select one stanza of a poem), but if I select just a word or
two, I don't want line breaks.

In other words, I do want line breaks that are inside the block I've selected; I
just don't want an extra newline at the end of what I've selected (unless I've
selected the entire contents of the pre block).  Maybe that's not really that
complicated after all.
(Assignee)

Comment 34

18 years ago
What Akkana is asking for would just work if copies from inside pre's always 
copied as plaintext.  If you pasted that into html, it would be a text insertion, 
and returns would automatically be converted into breaks.  Getting a plaintext 
paste to exhibit the desired behavior is free.  Making the determination that we 
want a plaintext copy is the hard part.  All the other code that examines the 
selection during copy happens _after_ we have decided whether to do a text or 
html copy.  I'll have to bend things around a bit to get this to work.  

Comment 35

18 years ago
jfrancis, I can see your coding problems, but logically, it's easy: If the
selection is only inside a <pre> (or exactly all of the <pre>), use plaintext
flavor. If the user selects something outside the <pre>, use HTML flavor.

Comment 36

18 years ago
shouldn't soft returns be pasted as soft return (thus adjusting the linewraps to
the new window width) and hard returns be pasted as hard returns? This would be
the desired solution.

I've also noticed that when pasting into a message, the text is pasted as
"preformatted" text and not as "body" text, as one would expect. 

Paste should simply paste as plain text (body) unless the message one is pasting
into AND the copied text are BOTH formatted.

Comment 37

18 years ago
> shouldn't soft returns be pasted as soft return (thus adjusting the
> linewraps to the new window width) and hard returns be pasted as hard
> returns? This would be the desired solution.

There's nothing like soft returns in normal plaintext.

> I've also noticed that when pasting into a message, the text is pasted as
> "preformatted" text and not as "body" text, as one would expect.

Yeah, that's what this bug is about. That "preformatted" (i.e. <pre>) is what
causes the newline at the end.

Comment 38

18 years ago
would it be possible to put soft returns into plain text?

Is mozilla or netscape capable of suggesting / implementing such a standard? (if
not, who?)

If either answer is yes, it should definetely be pursued as top priority and i
will post a bug for it. This is still the *major* drawback of all e-mail
formatting issues.

Comment 39

18 years ago
Please let's keep the focus on the bug. Such a discussion would be more
appropriate in one of the newsgroups.

Comment 40

17 years ago
*** Bug 70603 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Whiteboard: [QAHP]
FYI, I'm still seeing this bug on 2001032614.

Comment 42

17 years ago
I'd like to add that this not only the case with <PRE>.
Cut & paste from <H1>, <H2>, <H3>... also adds newline.
Seen on Netscape 6.01A on Solaris 8/SPARC. Looks like
this is the same bug?

(Assignee)

Comment 43

17 years ago
sigh.  this is not happening anytime soon.
Target Milestone: mozilla0.9 → mozilla1.0

Comment 44

17 years ago
need to investigate further before we work on the resolution

Updated

17 years ago
Whiteboard: [QAHP] → [plntxt][QAHP]

Comment 45

17 years ago
10 dups. Making mostfreq.
Keywords: mostfreq
(Assignee)

Comment 46

17 years ago
One alternative that would solve this and a host of other problems would be to 
*not* copy <pre> unless all of it is selected.  Ie, make <pre> copy rules 
identical to the rules for other block elements.  This would have the bad effect 
that you would lose the pre-formatting when copying parts of pres.

Comment 47

17 years ago
Again note that this is not only a <pre> issue. The same happens with <h1>,
<h2>, <h3>, ...

(Assignee)

Comment 48

17 years ago
Dimitir is correct.  The H1, ..., H6 elements are the other blocks that behave 
like pre when we copy.  Ie, we force them to be emitted even if you are only 
copying something inside them.  Other blocks we don't copy unless you either: 

are copying everything inside them, or
copy across at least on of the boundaries (start or end) of the block

In contrast, there are lots of non-block elements that we will copy even if you 
only have some interior content selected.  Basically all the tags that are used 
for stylistic purposes (b, i, u, tt, s, strike, em, strong, ....).

Comment 49

17 years ago
Joe, I don't think, it is a good idea to ignore <pre> (and thus plaintext
formatting) when only parts are copied.
(Assignee)

Comment 50

17 years ago
*** Bug 86172 has been marked as a duplicate of this bug. ***

Comment 51

17 years ago
*** Bug 85077 has been marked as a duplicate of this bug. ***
*** Bug 89036 has been marked as a duplicate of this bug. ***

Comment 53

17 years ago
*** Bug 90340 has been marked as a duplicate of this bug. ***

Comment 54

17 years ago
Dup bug 90340 is about View Source. Is the actual syntax of view source (we do
not see it - bug 74862) a big <pre> block? 

If not, bug 90340 is not a dup of this one :-(
View-source uses a big <pre> block, yes.

Comment 56

17 years ago
*** Bug 94342 has been marked as a duplicate of this bug. ***

Comment 57

17 years ago
Syd gave me permission to add nsbeta1 keyword to all bugs marked "[QAHP]"
in the status whiteboard. These are Editor usability bugs and are important
to fix for MachV.

We will have another triage meeting at some later date and re-evaluate
whether this bug is a MUSTFIX for MachV.
(Assignee)

Comment 58

17 years ago
097
Target Milestone: mozilla1.0 → mozilla0.9.7

Updated

17 years ago
Group: netscapeconfidential?

Comment 59

17 years ago

*** This bug has been marked as a duplicate of 98572 ***
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 60

17 years ago
verified.
Status: RESOLVED → VERIFIED
CC list accessible: false
Not accessible to reporter

Updated

17 years ago
Group: netscapeconfidential?
You need to log in before you can comment on or make changes to this bug.