Closed
Bug 52184
Opened 24 years ago
Closed 24 years ago
unable to paste correctly paragraph tags
Categories
(Core :: DOM: Editor, defect, P3)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
People
(Reporter: christophe.barbe.ml, Assigned: mozeditor)
Details
I use Mozilla M17 build 2000080923 under RedHat 6.1 (with HelixCode).
The RPM packages comes from the redhat ftp pointed by galeon.
When I copy a text from Mozilla to another app (balsa, gedit, ...) the <P> tags
are not well translated. They are ignored instead to be convert in a carriage
return code. The <BR> tags are well translated.
You can look at the following page which contains a lot of <P> tags which are
well translated (in a copy/paste operation) with Netscape 4.75.
http://www.linuxgazette.com/issue57/correa.html
Friendly,
Christophe
Christophe-
Forgive me for being ignorant here-but are you copying the content of the web
page or the page source? Thanks.
akkana owns copy/paste
Assignee: clayton → akkana
Component: HTML Element → Editor
Comment 3•24 years ago
|
||
I don't understand the bug -- aren't <p> tags supposed to be converted to two
carriage returns on pasting into plaintext? Exactly what are you seeing, vs.
what do you expect to see?
Joe's rewriting paste anyway, so I'll pass this to him, but will stay on the cc
list.
Assignee: akkana → jfrancis
Assignee | ||
Comment 4•24 years ago
|
||
well, i'm only rewriting html paste. I know pretty much nothing about html->
plaintext conversion. I agree that we should be putting in returns for
boundaries between block elements.
Updated•24 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•24 years ago
|
||
Fixed by NOXIF.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Well, being that I don't really know what the problem is (and I'm not the only
one-see akkana's comments) I can't say for sure...
What I see (regressing to PR2 on Mac) is that the <p> was not being copied at all
(i.e. no carrriage returns). On 10-09-10 Mac build, it copied with the
appropriate 2 carriage returns. Marking VERIFIED since it seems to have fixed
that problem.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Comment 9•24 years ago
|
||
Reopening to Resolve as Fixed. Bugs stay resolved until verified on both the
branch and the trunk.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 10•24 years ago
|
||
Resolving as Fixed. vtrunk keyword is in place requesting trunk verification
before this bug changes state to Verified. When this is verified on the trunk
vtrunk keyword should be removed and the bug Status should be set to Verified.
Sorry for the spam, just trying to make sure we cover all of our bases here.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 11•24 years ago
|
||
I'm verifying this bug on trunk build and I have a question.
This is a Linux problem but it was verified on Macintosh?..
Or this is an all platform bug?
Comment 12•24 years ago
|
||
Per my comments above, yes, its an ALL bug. Sorry bout that-updating
accordingly.
OS: Linux → All
Hardware: PC → All
Comment 13•24 years ago
|
||
Verified on all platforms on the trunk builds 0ct 24
Marking as VERIFIED
Removing vtrunk keyword
Status: RESOLVED → VERIFIED
Keywords: vtrunk
You need to log in
before you can comment on or make changes to this bug.
Description
•