234624 - crashes converting \r\r\n input from Iframe into a hidden form field [@ ConvertBreaks]

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Joachim Glauche]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Please view the demo on
http://www.linuxhardware.de/testing/mozillacrash.html

If you copy a long text into this iframe (f.e. a Slashdot article), Mozilla will
crash. If you use a textarea instead, mozilla will not crash.

This is tested with Mozilla 1.5 and Mozilla FireFox 0.8 with win2k.

Reproducible: Always
Steps to Reproduce:
1. copy a long text into the iframe
2. enjoy the crash

Actual Results:  
Mozilla crashes

Comment 1

[Boris Zbarsky [:bzbarsky]]

> 1. copy a long text into the iframe

How long is long?  Please either point to a text that should be pasted in or
attach it to this bug using
http://bugzilla.mozilla.org/attachment.cgi?bugid=234624&action=enter

Comment 2

[Joachim Glauche]

Hi, after some more testing I recognized that I can simply insert over 2000
"a"s, but 
Mozilla crashes if I insert 9 line breaks (note: the script adds one additional
<br>). 

And now something strange: 
Sometimes it crashes when I add only one line break. I don't know why...

I hope this helps a bit.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Could you please just attach whatever it is that you insert to cause the crash
to this bug like I asked?  That would help the most, since it would make it
simple to reproduce the crash... ;)

Comment 4

[Joachim Glauche]

Attachment: copy & paste this text in a text file first, then copy the text with notepad (or other) into the iframe-window.

Ok, if you aren't able to press the "enter"-key 9 times ;)) (or is it just my
english?)
The attached text will also definitely crash my Mozilla.

Comment 5

[Joachim Glauche]

Wait a second...
If I click on the text file and copy the text with Mozilla into the Iframe, it
will not crash. I copied the text in a text file and then I copied the text out
of the editor window (f.e. notepad) - and Mozilla crashes.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Ok, if you aren't able to press the "enter"-key 9 times ;))

I am, of course.  It doesn't crash.

The idea is that we need to be doing _exactly_ the same things, since I am
having trouble reproducing the bug.  That said, and in light of comment 5, what
are the exact steps to reproduce the crash?  Step by step, please?  Pretend you
are giving directions to a 5-year-old who knows nothing about computers.

Comment 7

[Joachim Glauche]

Ok...
1. click on the attachment, select the text by pressing strg+a and strg+c
2. create a new textfile and open it with notepad
3. paste the text with strg+v
4. press strg+a and strg+c again
5. start Mozilla
6. go to http://www.linuxhardware.de/testing/mozillacrash.html
7. click on the inline-frame, press strg+v. After doing that, your cursor will
be at the last row 
   of the frame. 
8. Press on the Button "click" and wait for the crash.

Please note that this is only tested (with 3 different machines) under win2k.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yeah, I can't get that to crash, but I'm testing on Linux (and I used emacs
instead of notepad).  Biesi, do you have a windows build to test on?

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

well, I do crash... winxp home, 2004021709

I don'T currently have a debug build here though...

Comment 10

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040216
confirm crash with Mozilla 1.4.1, 1.5, and current nightly, 
used each with own profile, but same text, didn´t test others.

TalkbackID TB30440772Z using Mozilla 1.5

Would be fine if 1.7a could come with Talkback included.

tested 1.7a five times, restarted Mozilla, and pasted same text again, without
copying. First three times instant crash, 4th time no crash, but text vanished
from iframe, pasted again, clicked, no crash, but crashed, when I closed mozilla
to check another one.
tested 1.4.1, three times, always crashing.
When I clicked, the default alert for submit came up, I acknowledged, and boom!

tested 1.5, crashing, and sent talkback.
Didn´t look where the talkback was sent to, if needed, I can do some more ;-)

Comment 11

[Boris Zbarsky [:bzbarsky]]

> TalkbackID TB30440772Z using Mozilla 1.5

Can we even get to those anymore?  Asa?

Anyway, confirming a bug in browser-general without moving it somewhere is a
good way to make sure that it never gets looked at by anyone.

This seems to only be crashing Windows builds, so I'm not going to be useful here...

Neil has this in gdb, but all it's really showing is that the stack is totally
trashed...  Realistically, running this under purify is what would probably do
the most good.

Comment 12

[Hermann Schwab]

I´ll never ever will confirm a bug from general, if I don´t know something
better. Would Editor:Core be the correct component, as I suppose it is a Midas bug?

1.6 is also crashing, and simply submitting a local copy of the file is sufficient.


0. save http://www.linuxhardware.de/testing/mozillacrash.html

steps to repeat:
1. load mozillacrash.html
2. click on 'click', until it crashes.

more complicated, involves entering data:
1. load mozillacrash.html
2. Press Enterkey seven times or more
3. click on 'click'

or:
1. load mozillacrash.html
2. Press Enterkey seven times or more
3. click on 'click'

or:
1. load mozillacrash.html
2. type A, press Enter
3. type B, press Enter
.. repeat till

7. type F, press Enter
8. click on 'click'

if it doesn´t crash, repeat.

Comment 13

[Hermann Schwab]

Talkbacks with Mozilla 1.5 on Win98SE, sent to
talkback.mozilla.org/sprial-bin/Collector.dll

TB30472929W, TB30472846H entered more than 6 ENTER into Iframe on website, crash
on submit (after Acknowledge)

TB30472794M used local copy of page, entered 5 ENTER, then cursor vanished, I
submitted, crash.

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

loading this testcase in a win debug build gives me assertion failures from
inside NTDLL... this really does need running under purify, which I
unfortunately can not do.

Comment 15

[Hermann Schwab]

TB305888305W, TB30588982W from Mozilla 1.7a sent to 213.157.0.193:DNS
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040219

wanted to test Talkback on coming 1.7a

Comment 16

[Kevin Berkheiser]

When I try this the mozilla windows hangs with an hourglass. 

I then click the X to close the app and it crashes. 

TB9600Y


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316

Comment 17

[timeless]

Attachment: purify output (cvs build from this week)

Comment 18

[timeless]

Attachment: purify output - win line numbers (cvs build from unknown)

Comment 19

[timeless]

discussed on irc, bz's use of emacs was a poor choice, it almost certainly 
decided to be 'helpful' and 'clean up' the input. this means emacs would not be 
certified as a timeless editor for the purpose of crashing mozilla.

notepad of course was up to the task.

Here's a sample of the input:
0x02568998  45 00 66 00 72 00 65 00 6e 00 20 00 52 00 65 00  E.f.r.e.n. .R.e.
0x025689A8  79 00 65 00 73 00 26 00 6c 00 74 00 3b 00 62 00  y.e.s.&.l.t.;.b.
0x025689B8  72 00 26 00 67 00 74 00 3b 00 0d 00 0d 00 0a 00  r.&.g.t.;.......
0x025689C8  26 00 6c 00 74 00 3b 00 62 00 72 00 26 00 67 00  &.l.t.;.b.r.&.g.

The fun stuff is at inSrc+21:
0x025689C2  0d 00 0d 00 0a 00

\r\r\n  or something like that. life is cruel to the poor beancounters of the 
world. Today's beancounter is CountLinebreaks.

Basically \r\r\n becomes 2 points for the minus side and that causes big 
problems for the plus side.

here's where the sides play:
180                   PRInt32 newBufLen = ioLen - (numLinebreaks * srcBreakLen) 
+ (numLinebreaks * destBreakLen);

CountLinebreaks => 28
ioLen = 759
srcBreakLen = 2
destBreakLen = 1

this of course leads to overflow

Comment 20

[timeless]

Attachment: buffer instead of aggressively sizing

Comment 21

[timeless]

Comment on attachment 145264 [details] [diff] [review]
buffer instead of aggressively sizing

/someone/ needs to check my math on the second half of this change

Comment 22

[chris hofmann]

	 ntdll.dll + 0x33aed (0x77f83aed) 16917670
Email Address	[e-mail]
Product ID	Mozilla1.7
Build ID	2004031615
Trigger Time	2004-03-31 22:12:48.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	ntdll.dll + (00033aed)
URL visited	http://www.linuxhardware.de/testing/mozillacrash.html
User Comments	http://bugzilla.mozilla.org/show_bug.cgi?id=234624
Since Last Crash	null sec
Total Uptime	null sec
Trigger Reason	Access violation
Source File Name	
Trigger Line No.	
Stack Trace 	
ntdll.dll + 0x33aed (0x77f83aed)
ntdll.dll + 0x8cca (0x77f58cca)
msvcrt.dll + 0x1ab2e (0x77c2ab2e)
nsMemoryImpl::Free
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/xpcom/base/nsMemoryImpl.cpp,
line 348]
nsMemory::Free
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/xpcom/glue/nsMemory.cpp,
line 106]
ReleaseData
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/xpcom/string/src/nsSubstring.cpp,
line 214]
nsSubstring::Finalize
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/xpcom/string/src/nsTSubstring.cpp,
line 164]
nsHTMLInputElement::SaveState
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 2355]
nsGenericHTMLFormElement::SetDocument
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 3274]
nsHTMLInputElement::SetDocument
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1640]
nsGenericElement::SetDocumentInChildrenOf
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 1706]
nsGenericElement::SetDocument
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 1758]
nsGenericHTMLElement::SetDocument
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1279]
nsCOMPtr_base::assign_from_qi
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/xpcom/glue/nsCOMPtr.cpp,
line 94]
nsGenericElement::SetDocumentInChildrenOf
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 1706]
nsGenericElement::SetDocument
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 1758]
nsGenericElement::SetDocumentInChildrenOf
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 1706]
nsGenericElement::SetDocument
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 1758]
nsGenericHTMLElement::SetDocument
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1279]
nsHTMLBodyElement::SetDocument
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsHTMLBodyElement.cpp,
line 501]
nsGenericElement::SetDocumentInChildrenOf
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 1706]
nsGenericElement::SetDocument
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 1758]
nsGenericHTMLElement::SetDocument
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1279]
nsDocument::SetScriptGlobalObject
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocument.cpp,
line 1645]
DocumentViewerImpl::Close
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocumentViewer.cpp,
line 1143]
nsDocShell::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp,
line 3060]
nsWebShell::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/docshell/base/nsWebShell.cpp,
line 1230]
nsFrameLoader::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsFrameLoader.cpp,
line 374]
nsSubDocumentFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/document/src/nsFrameFrame.cpp,
line 564]
nsFrameList::DestroyFrames
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 130]
nsContainerFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 137]
nsBoxFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1066]
nsFrameList::DestroyFrames
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 130]
nsContainerFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 137]
nsBoxFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1066]
nsFrameList::DestroyFrames
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 130]
nsContainerFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 137]
nsBoxFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1066]
nsFrameList::DestroyFrames
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 130]
nsContainerFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 137]
nsBoxFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1066]
nsFrameList::DestroyFrames
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 130]
nsContainerFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 137]
nsBoxFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1066]
nsFrameList::DestroyFrames
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 130]
nsContainerFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 137]
nsBoxFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1066]
nsFrameList::DestroyFrames
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 130]
nsContainerFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 137]
nsBoxFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1066]
nsFrameList::DestroyFrames
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 130]
nsContainerFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 137]
nsBoxFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1066]
nsFrameList::DestroyFrames
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 130]
nsContainerFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 137]
ViewportFrame::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsViewportFrame.cpp,
line 68]
nsFrameManager::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsFrameManager.cpp,
line 331]
PresShell::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 1878]
DocumentViewerImpl::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocumentViewer.cpp,
line 1227]
nsDocShell::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp,
line 3061]
nsWebShell::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/docshell/base/nsWebShell.cpp,
line 1230]
nsXULWindow::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsXULWindow.cpp,
line 491]
nsWebShellWindow::Destroy
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp,
line 1666]
nsWebShellWindow::Close
[c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp,
line 373]

Comment 23

[[e-mail]]

Ah, I see now, CountLineBreaks counts a CR as a CRLF, it will skip over the LF
although that wouldn't have affected the count anyway.

Now suppose you have a string containing (say) 32768 CRs, then CountLineBreaks
will say that there are 32768 line breaks, so ConvertBreaks thinks that it will
strip 32768 CR characters and allocates zero memory for the 32768 LFs...

Whatever the correct result of converting lone CR or LF characters should be,
ConvertBreaks should not try to shorten its buffer. In fact, the conversion
functions could be rewritten to always convert to a lone CR or LF in situ.

Comment 24

[[e-mail]]

Whoops, I blame Bugzilla's access keys ;-)

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 145264 [details] [diff] [review]
buffer instead of aggressively sizing

+    ioLen = dst - resultString;

you need to add 1 to include the terminating zero, which is included per the
comment above this function

+    if (newBufLen <= 0) return nsnull;

this seems somewhat unnecessary; you are defending against possible overflow?
that'd require a 4 GB string...

r=me otherwise

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #25)
> (From update of attachment 145264 [details] [diff] [review])
> +    ioLen = dst - resultString;
> 
> you need to add 1 to include the terminating zero, which is included per the
> comment above this function

nevermind me. your calculation is correct... dst points *after* the zero at the
end. or so it looks like to me.

add an NS_ASSERTION(resultString[ioLen - 1] == 0); ?

Comment 27

[tor]

Attachment: fix CountLinebreaks instead

Shouldn't we fix the function CountLinebreaks instead of doing a
conservative memory allocation?

Comment 28

[Joachim Glauche]

This bug seems to be fixed in Firefox 1.5 beta1 (Using the Windows build) 

Can anyone double-check this?

Comment 29

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050910 SeaMonkey/1.1a

wfm means: doesn't crash, but I see other issues:

When I submit using 'click', the text pasted is formatted and appended to the
URL in the Location Bar. 
When I go back, URL is restored, but the text now is shown as <pre>formatted
HTML, including tags. I didn't find a way to delete this text.

Comment 30

[Joachim Glauche]

(In reply to comment #29)
> wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
> wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050910 SeaMonkey/1.1a
> 
> wfm means: doesn't crash, but I see other issues:
> 
> When I submit using 'click', the text pasted is formatted and appended to the
> URL in the Location Bar. 
> When I go back, URL is restored, but the text now is shown as <pre>formatted
> HTML, including tags. I didn't find a way to delete this text.

I don't think it's a bug. The edit mode is activated by this:
<body onload="start()">
When you click the back-button, you will see the page like it was before the
submit (see code) and the onload - tag is not activated. Since "designmode" is
not activated on page load, you won't be able to edit this iframe. 

Comment 31

[timeless]

*** Bug 307189 has been marked as a duplicate of this bug. ***

Comment 32

[Brendan Eich [:brendan]]

timeless, don't dup without propagating crucial cc list members and blocking
flags, at the least.  Also, if tor patched, but you own the bug, are you going
to make sure that patch gets review, and do all the checkins?

/be

Comment 33

[timeless]

no. this bug is lost in the ether. it's dougt's fault. you're welcome to 
review. you've repeatedly indicated that you'd get dougt to fulfill my review 
requests. i'd say this is a reflection of something. if this gets reviews, i'd 
see it and get it resolved. if this doesn't get reviews, i'll continue to dupe 
any obvious dupes of it until someone addresses the patch.

Comment 34

[Doug Turner (:dougt)]

Comment on attachment 145708 [details] [diff] [review]
fix CountLinebreaks instead

a) the function is terribly named as it only check at most two chars of the
breakStr.

b) the else should be on its own line (when in rome)

c) please move the inc operator next to the variable name to make this function
consistent with the rest of the file.

other then that, it looks like it will work fine.  I tried the test case and it
doesn't appear to still crash.

Comment 35

[Daniel Veditz [:dveditz]]

Comment on attachment 145708 [details] [diff] [review]
fix CountLinebreaks instead

sr=dveditz

Comment 36

[timeless]

Comment on attachment 145708 [details] [diff] [review]
fix CountLinebreaks instead

mozilla/xpcom/io/nsLinebreakConverter.cpp  1.15

Comment 37

[timeless]

Comment on attachment 145708 [details] [diff] [review]
fix CountLinebreaks instead

asa: why did you minus this bug when it's clear that brendan wanted it?

Comment 38

[Asa Dotzler [:asa]]

we minused this bug because it's not going to block the release of Firefox 1.5.

Comment 39

[Brendan Eich [:brendan]]

The concern is that this is an exploitable bug.  See comment 23.  If not
exploitable, then still a crash we should fix in 1.8.

/be

Comment 40

[Asa Dotzler [:asa]]

Comment on attachment 145708 [details] [diff] [review]
fix CountLinebreaks instead

OK. please add the fixed1.8 keyword when this lands.

Comment 41

[Asa Dotzler [:asa]]

timeless, time is running out on 1.8b5 and I suspect we're soon going to start
withdrawing the approvals for non-blocking bugs to minimize risk. If this still
needs to land on the branch, please do so ASAP and add the "fixed1.8" keyword.
Thanks.

Comment 42

[Martijn Wargers (dead)]

This is also fixed on branch, right?
http://lxr.mozilla.org/mozilla1.8/source/xpcom/io/nsLinebreakConverter.cpp#106
So it should have the fixed1.8 keyword, not?

Comment 43

[Bob Clary [:bc] (inactive)]

no crash in firefox 1.5 rc2 winxp/linux