Closed
Bug 67334
Opened 24 years ago
Closed 23 years ago
Text copied from a pre doesn't preserve newlines
Categories
(Core :: DOM: Serializers, defect, P2)
Tracking
()
VERIFIED
DUPLICATE
of bug 125732
mozilla1.0.1
People
(Reporter: akkzilla, Assigned: t_mutreja)
References
(Depends on 1 open bug, )
Details
(Keywords: helpwanted, Whiteboard: [behavior][html][serializer])
Attachments
(2 files)
|
(deleted),
text/html
|
Details | |
|
(deleted),
patch
|
Details | Diff | Splinter Review |
The opposite of the problem we usually see: The lyrics in the url listed are in
a <pre> although they don't look like it, since there's a font tag that
specifies variable width. Copy multiple lines, and paste into a plaintext app
somewhere. No newlines are preserved -- it's all one long line.
Giving to Joe since I know he's working on issues related to plaintext copy.
Joe, if you think this is some other problem not directly related to what you're
working on, give it back to me or Anthony.
|
||
Comment 1•24 years ago
|
||
akkana, i have to hand this back as a worksforme. i tried on mac and on windows,
copying lyrics and pasting into separate plaintext apps (bbedit and wordpad).
giving back to you instead of worksforme in case you can get this to happen.
Assignee: jfrancis → akkana
|
Reporter | |
Comment 2•24 years ago
|
||
Joe and I looked at this on my machine. The page has <i> and <b> tags inside
the <pre>, and it seems that those are confusing things. If I select the entire
contents of the <pre>, I either get nothing at all pasted, or the entire
contents pasted with no newlines. If I select just a few lines outside the <i>
blocks, I get correct formatting with newlines. If I select lines spanning from
outside the <i> to inside or across that block, then the lines outside the <i>
are formatted correctly but the lines inside it are not. Tres weird.
Bouncing back to Joe on his suggestion; he's going to look at the code in the
doc encoder to see if it's doing anything wrong, and I'll poke around in the
plaintext serializer to see if the problem is there.
Assignee: akkana → jfrancis
|
|
||
Updated•24 years ago
|
Status: NEW → ASSIGNED
|
|
||
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
|
||
Comment 5•23 years ago
|
||
I think this is the correct bug for the issue blocking bug #77062.
I will attach a sample testcase that is causing the problem (there is a <br>
inside the <pre> instead of a newline).
Blocks: 77062
|
|
||
Comment 6•23 years ago
|
||
|
|
||
Comment 7•23 years ago
|
||
i need help with serializer issues. i don't have time to own these :-(
Keywords: helpwanted
|
||
Updated•23 years ago
|
Whiteboard: [behavior][html] → [behavior][html][ws]
|
|
||
Comment 8•23 years ago
|
||
removing [ws], marking [serializer]
Whiteboard: [behavior][html][ws] → [behavior][html][serializer]
|
|
||
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
adding mailtrack keyword. This non appending of newlines seems to create havoc
when sending mail thru imap and results in the mail not being sent. It would be
extremely helpful if this could be elevated to a .9.2 if not a .9.1 :-) and
fixed for this release.
Keywords: mailtrack
|
|
||
Comment 10•23 years ago
|
||
assigning to mjudge
Assignee: jfrancis → mjudge
Status: ASSIGNED → NEW
Priority: P1 → P2
Target Milestone: mozilla0.9.3 → mozilla0.9.2
|
||
Comment 11•23 years ago
|
||
blocks 0.9.1 bug #83381
mjudge / jfrancis, is this something I can help with?
Blocks: 83381
|
|
||
Comment 12•23 years ago
|
||
sniffing around, trying to help.
in nsWSRunObject::InsertBreak()
// MOOSE: for now, we always assume non-PRE formatting. Fix this later.
// meanwhile, the pre case is handled in WillInsertText in nsHTMLEditRules.cpp
nsHTMLEditRules::WillInsertText() just returns NS_OK.
Is this the place to start?
|
|
||
Comment 13•23 years ago
|
||
more sniffing, I see we get here:
nsTextEditRules::ReplaceNewlines(nsIDOMRange * 0x083c7bf0) line 1083
nsHTMLEditRules::AfterEditInner(int 3009, short 1) line 389 + 23 bytes
nsHTMLEditRules::AfterEdit(nsHTMLEditRules * const 0x083a7bf4, int 3009, short
1) line 311 + 20 bytes
nsHTMLEditor::EndOperation(nsHTMLEditor * const 0x083f07c0) line 3538 + 62 bytes
nsAutoRules::~nsAutoRules() line 109
nsHTMLEditor::InsertAsCitedQuotation(nsHTMLEditor * const 0x083f0858, const
nsAString & {...}, const nsAString & {...}, int 1, const nsAString & {...},
nsIDOMNode * * 0x0012f388) line 1472 + 16 bytes
nsHTMLEditorLog::InsertAsCitedQuotation(nsHTMLEditorLog * const 0x083f0858,
const nsAString & {...}, const nsAString & {...}, int 1, const nsAString &
{...}, nsIDOMNode * * 0x0012f388) line 428 + 29 bytes
nsEditorShell::InsertAsCitedQuotation(nsEditorShell * const 0x082003a0, const
unsigned short * 0x074bb0e0, const unsigned short * 0x083f59e0, int 1, const
unsigned short * 0x024bcd34, nsIDOMNode * * 0x0012f388) line 2615 + 64 bytes
nsMsgCompose::ConvertAndLoadComposeWindow(nsMsgCompose * const 0x082fcb00,
nsIEditorShell * 0x082003a0, nsString & {"On 6/1/01 12:37 PM, Varada
Parthasarathi wrote:<br><html>"}, nsString & {"<html>
<head>
</head>
<body>
<br>
what is your mtbf?<br>
<br>
<br>
chris h.<br>
<br>
-------- Original Message --------
<t"}, nsString & {""}, int 1, int 1) line 328 + 98 bytes
QuotingOutputStreamListener::OnStopRequest(QuotingOutputStreamListener * const
0x08416860, nsIRequest * 0x08414dc4, nsISupports * 0x08416750, unsigned int 0)
line 1537
nsStreamConverter::OnStopRequest(nsStreamConverter * const 0x084144b0,
nsIRequest * 0x08414dc4, nsISupports * 0x08416750, unsigned int 0) line 1022
nsMsgProtocol::OnStopRequest(nsMsgProtocol * const 0x08414dc0, nsIRequest *
0x08414714, nsISupports * 0x08416750, unsigned int 0) line 275 + 88 bytes
nsMailboxProtocol::OnStopRequest(nsMailboxProtocol * const 0x08414dc0,
nsIRequest * 0x08414714, nsISupports * 0x08416750, unsigned int 0) line 344
nsOnStopRequestEvent::HandleEvent() line 159
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x083c7e14) line 64
PL_HandleEvent(PLEvent * 0x083c7e14) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x009ced80) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x001601d4, unsigned int 49489, unsigned int 0,
long 10284416) line 1071 + 9 bytes
USER32! 77e71820()
009ced80()
perhaps that is what is converting our newlines in the <pre> text to <br>,
instead of <br>CRLF
investigating if I can tweak nsTextEditRules::ReplaceNewlines(nsIDOMRange
*aRange) to insert <br>CRLF when quoting.
|
|
||
Comment 14•23 years ago
|
||
trying to fix it so instead of replacing "\n" with "<br>", we just insert the
<br> (And leave the "\n")
forgive the spam, I'm thinking out loud here in case some editor guru can jump
in and correct any mistakes.
|
|
||
Comment 15•23 years ago
|
||
ok, I've got the start of a hack. I'm not sure about the correctness, or if it
will break something else.
basically, I've changed it so we don't delete the newline when we insert the
<br>.
with it, I can save as draft (and send) the evil message in bug #83381.
I'll attach a patch.
|
|
||
Comment 16•23 years ago
|
||
|
|
||
Comment 17•23 years ago
|
||
I don't see any obvious bugs with seth's patch but I defer to the all-knowing
rules guru: joe
|
||
Comment 18•23 years ago
|
||
I applied this patch and it takes care of both 77062 as well as 83381.
|
|
||
Comment 19•23 years ago
|
||
after reading jfrancis' emails about reply perf, I see one place this will cause
a regression.
leaving the newlines in there makes it so there isn't "dead lines" that the user
can't click on.
if you compare the two versions of the reply in #83381, the one made with this
patch has extra space in between the lines that the user can't click on.
the version without the newlines, you can click on every line.
so that explains why the original code removed the "\n". not sure what to do
about that.
|
|
||
Comment 20•23 years ago
|
||
see my comments in bug 83381
|
|
||
Comment 21•23 years ago
|
||
I don't think the linebreak -> <br> substitution code can be removed until
http://bugzilla.mozilla.org/show_bug.cgi?id=85505 is fixed.
Depends on: 85505
|
|
||
Comment 22•23 years ago
|
||
well, if this depends on 85505, then moving over to 9.3, 85505 does not a
milestone set yet.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
|
||
Comment 23•23 years ago
|
||
I've run into "dead lines which I click in" when I do a forward inline of a
message and I have a sig file. The dead lines show up right before the sig
file. When I try to delete the text in the compose window (part of the forwarded
content), I have an area which I can't click in.
|
|
||
Comment 24•23 years ago
|
||
i hate to do this, but moving to 1.0, bug 85505 won't get any traction for the
next few weeks
Target Milestone: mozilla0.9.3 → mozilla1.0
|
||
Comment 25•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
|
Assignee | |
Updated•23 years ago
|
Status: NEW → ASSIGNED
|
|
Assignee | |
Comment 27•23 years ago
|
||
Can be fixed by the patch attached for bug#125732.
*** This bug has been marked as a duplicate of 125732 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•