From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020422 BuildID: 2002042209 Recent nightlies, even RC1, can not forward(inline) epost (HTML format) as before. The Mozilla ate lots resource. I should kill the process of Mozilla. Reproducible: Always Steps to Reproduce: 1. Forward epost(epaper I subscribe) as Inline 2. The epost message source is attached to Bugzilla Actual Results: Forward successfully and system not hang. build 2002-04-15 build 2002-04-17 build 2002-04-19 build 2002-04-22 RC1 all have the same problem.

related: bug 126953

wfm using mozilla trunk build 2002042303. forwarding attachment as inline can be sent and received successfully. please reverify using latest trunk build.

Dear Trix, I can not verify what you said, because nightly 2002042303 (win) can not be downloaded completely. The file seems to be broken.

Still not fixed in 2002042510. (0.9.9+) This bug needs more attention. :-( The function was OK in 0.9.9 milestone.

Well, at least in Classic (I don't use Modern), I see the green arrow on the mail icon to show that you have new mail. If that's a problem with modern you should file a themes bug. Also, I filed the bug asking for the mail icon to go to read your new mail some time ago but it as been ignored.

Um, somehow I attached this to the wrong bug by mistake. So sorry...

I have to correct what I said. The milestone 0.9.9 also failed in this. I have checked it again. This should be a big problem of Mozilla Mail, but it seems no one care...:(

I doubt if it is the size problem of HTML message I'd like to forward...????

Accepting

This bug needs some one's attention....:-(

Mozilla 0.9.9+ build 2002050108 still has this issue.

Another test case for the bug. This is some spam I received. When I forward as attachment all is well. When I forward as inline Mozilla RC1 hangs, under both Linux and Win2000, and CPU usage goes to 100%.

Using the first test case, I am able to reproduce the hang with a recent debug build. The hang append at: nsButtonBoxFrame::MouseClicked(nsIPresContext * 0x054144e0, nsGUIEvent * 0x0012f400) line 192 nsButtonBoxFrame::HandleEvent(nsButtonBoxFrame * const 0x055a0308, nsIPresContext * 0x054144e0, nsGUIEvent * 0x0012f400, nsEventStatus * 0x0012f6e0) line 142 PresShell::HandleEventInternal(nsEvent * 0x0012f400, nsIView * 0x00000000, unsigned int 0x00000001, nsEventStatus * 0x0012f6e0) line 6001 + 38 bytes PresShell::HandleEventWithTarget(PresShell * const 0x053bd730, nsEvent * 0x0012f400, nsIFrame * 0x055a0308, nsIContent * 0x05357348, unsigned int 0x00000001, nsEventStatus * 0x0012f6e0) line 5955 + 22 bytes nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 0x052c8670, nsIPresContext * 0x054144e0, nsMouseEvent * 0x0012f8d4, nsEventStatus * 0x0012f6e0) line 2623 + 63 bytes nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x052c8678, nsIPresContext * 0x054144e0, nsEvent * 0x0012f8d4, nsIFrame * 0x055a0308, nsEventStatus * 0x0012f6e0, nsIView * 0x053f5c90) line 1703 + 28 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f8d4, nsIView * 0x053f5c90, unsigned int 0x00000001, nsEventStatus * 0x0012f6e0) line 6006 + 43 bytes PresShell::HandleEvent(PresShell * const 0x053bd734, nsIView * 0x053f5c90, nsGUIEvent * 0x0012f8d4, nsEventStatus * 0x0012f6e0, int 0x00000001, int & 0x00000001) line 5909 + 25 bytes nsViewManager::HandleEvent(nsView * 0x053f5c90, nsGUIEvent * 0x0012f8d4, int 0x00000001) line 2076 nsView::HandleEvent(nsViewManager * 0x05242bb0, nsGUIEvent * 0x0012f8d4, int 0x00000001) line 306 nsViewManager::DispatchEvent(nsViewManager * const 0x05242bb0, nsGUIEvent * 0x0012f8d4, nsEventStatus * 0x0012f7d0) line 1881 + 23 bytes HandleEvent(nsGUIEvent * 0x0012f8d4) line 83 nsWindow::DispatchEvent(nsWindow * const 0x053f5d3c, nsGUIEvent * 0x0012f8d4, nsEventStatus & nsEventStatus_eIgnore) line 865 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f8d4) line 886 nsWindow::DispatchMouseEvent(unsigned int 0x0000012d, unsigned int 0x00000000, nsPoint * 0x00000000 {x=??? y=???}) line 4720 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 0x0000012d, unsigned int 0x00000000, nsPoint * 0x00000000 {x=??? y=???}) line 4977 nsWindow::ProcessMessage(unsigned int 0x00000202, unsigned int 0x00000000, long 0x0025006d, long * 0x0012fcec) line 3596 + 28 bytes nsWindow::WindowProc(HWND__ * 0x000f0870, unsigned int 0x00000202, unsigned int 0x00000000, long 0x0025006d) line 1130 + 27 bytes USER32! 77e11b60() USER32! 77e11cca() USER32! 77e183f1() nsAppShellService::Run(nsAppShellService * const 0x01148ad8) line 451 main1(int 0x00000001, char * * 0x00304fc0, nsISupports * 0x00000000) line 1456 + 32 bytes main(int 0x00000001, char * * 0x00304fc0) line 1805 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e8d326() the assertion is: ###!!! ASSERTION: You can't |write| into an |nsWritingIterator| with no space!: 'size_forward() > 0', file ..\..\dist\include\string \nsStringIterator.h, line 356 ###!!! ASSERTION: |copy_string| will never terminate: 'count_copied > 0', file ..\..\dist\include\string\

The hang append during the send. Therefore this is a dataloss

we choke on the HTML tag <img src="clear.gif" height=1 width=150> when processing the image url. This is similar to bug 129358 I fixed a while ago

this is a string iterator problem! the function OutputIterator& copy_string( InputIterator& first, const InputIterator& last, OutputIterator& result ) will failed to detect the end of the copy. This because when we copied the first chunk of data, we move forward the "first" iterator using the function source_traits::advance(first, count_copied). The returned iterator will be set pass the end operator by the call to normalize_forward(). Therefore we never get a first iterator equals to the "last" iterator and we loop for ever!!! reassign to string guru.

the easy way to reproduce this problem is: 1) Open a Plain Text compose window 2) address the message to yourself and type the following text: <img src="bogus.gif" 3) send the message 4) get the message, do forward inline, address the message to yourself 5) send it ==> Application hang PS: The fact we interprete HTML tag from a plain text message when forwarding is covered by another bug report

in step 2, you should read: 2) address the message to yourself and type the following text: <img src="bogus.gif"> the HTML tag must be closed with a >

Nav triage team: nsbeta1+, adt2 rtm

This attachment message is *not* HTML like message (no HTML tag), also can not be forwarded inline.

This hang is caused by the way fragment are currently managed in strings. This problem should go away once the fix for bug 70083 has been checked in. Until then, jag gave me a work around that I will post...

The workaround is to copy the string we need to parse into an new string, that will result in an unfragmented string.

Comment on attachment 83052 [details] [diff] [review] Proposed fix by Jag, v1 R=ducarroz

Comment on attachment 83052 [details] [diff] [review] Proposed fix by Jag, v1 sr=sspitzer if you check this into the trunk, don't forget to add a comment to #70083 to remember to remove the hack once that bug is fixed.

Fix checked in the trunk. This is a simple fix that prevent an application freeze, we should consider taking it for RTM

adding adt1.0.0+. Please get drivers approval and then checkin to the 1.0 branch.

Hello, In nighty, 2002051408 on Win98SE, the fix works. But while sending message...it looks quite slow...:-( It's better to avoid this in a mature S/W application.

Although the fix can forward HTML style email, it seems to need lots of resource...i.e., the whole system becomes slow while sending. And there is still a problem. While entering email address, the smart searching in address book no more works ! It looks not a perfect fix. Thanks for your effort.

That should be a totally different problem and not a regression caused by this fix. Please file a new bug.

I filed an another bug about this fix issue. Please refer to bug#144658 Thanks a lot.

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

Comment on attachment 83052 [details] [diff] [review] Proposed fix by Jag, v1 a=brendan@mozilla.org for 1.0 -- please get this in ASAP. /be

Fix checked in the branch

In nightly 2002051708 (1.0.0+), forwarding HTML style message as inline (also attachment) comsuned lots resource, and entering email address with smart searching failed (except forward as attachment). I'm not sure this is closed or not. I filed bug#144658 for this, if this is considered to solve in RC3 (or 1.0 final), please notice the related problem. Personal thinking, this isn't a perfect fix and it should not appear in a final release...because it's an obvious issue. Thanks for your all effort. ps. This may be an impolite question, but is this fix really verified ?

After using this fix (I believe that's in RC3), you will see the terrible result as the pic. This pic was got from RC3.

This bug is about a hang in string code. The work-around for this was to construct the resulting string slightly differently, the resulting string contains the same characters either way. This bug has been fixed; as far as I know, we don't hang anymore. This fix can't possibly affect (either positively or negatively) the issues you describe. Could you please keep comments about them in the bug you filed instead of putting them in this bug?

Hello Peter Annema, First I have say sorry for my poor English. I might not describe well. What I want to point out is, this fix (or said work-around) does not *perfectly* solve this issue. I knew that MozillaMail will not hang with this work-around. But a viewpoint from an *end* *user* about this work-around, it's hard to say it was solved completely. (Please refer to the attachment, 86038) I can imagine that Mozilla team will say "This is another problem, please file another bug". Yes! I did that, it's bug#144658. Any one in Mozilla team care ? I'm not sure and I don't know... I'm an end user in this domain, I filed this bug just to help Mozilla.org to qualify. Please don't say Bugzilla is not for end user. Sorry to say that, I feel tired and frustration to file bugs about MozillaMail/News recently. I filed bugs, and lots of them still have no progress... Becasue they are minor ??? Sorry to complian this, you may not be interested in this complaint or heard lots already. >> Could you please keep comments about them in the bug you filed instead >>of putting them in this bug? Sorry...I have poor English, I don't know what you mean above.

I understand that end users may think this bug is not fixed, which is why I've tried to explain why we developers think this particular bug is fixed. Mail doesn't hang anymore when it forwards a message inline (even though it's still slow and uses a lot of resources). If you look at your first comment, your expected results (under the actual results line) even state "Forward successfully and system not hang." I have fixed the hang part of this problem, it is up to the mail/news team to fix the rest of the problems. The easiest way to get that fixed is to file a new bug (which you have done, bug 144658) and discuss the problems there. They may not fix it immediately, they have a long list of bugs to fix and they probably have bugs with a higher priority than the ones you've pointed out. Please keep filing bugs you find, it is appreciated, even though we may not have the resources to fix them immediately, some bugs are more important to fix than other bugs, and will get fixed first.