hang in copy_string while forwarding epost (HTML format ) as Inline !!

RESOLVED FIXED in mozilla1.0.1

Status

()

Core
String
--
critical
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: Yeh You-Ying, Assigned: jag (Peter Annema))

Tracking

({dataloss})

Trunk
mozilla1.0.1
x86
Windows 98
dataloss
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2 rtm] custrtm-)

Attachments

(10 attachments)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 80511 [details]
The epost source I would like to forward as inline
(Reporter)

Comment 2

16 years ago
Created attachment 80513 [details]
The epost looks like
(Reporter)

Comment 3

16 years ago
Created attachment 80514 [details]
forward as inline

Comment 4

16 years ago
related: bug 126953
Summary: Can not Forward epost (HTML format ) as Inline !! → Can not Forward epost (HTML format ) as Inline !!

Updated

16 years ago
QA Contact: gayatri → olgam

Comment 5

16 years ago
wfm using mozilla trunk build 2002042303.  forwarding attachment as inline can
be sent and received successfully.  please reverify using latest trunk build.
(Reporter)

Comment 6

16 years ago
Dear Trix,

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

Comment 7

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

Comment 8

16 years ago
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.

Comment 9

16 years ago
Um, somehow I attached this to the wrong bug by mistake. So sorry...
(Reporter)

Comment 10

16 years ago
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...:(
Component: MIME → Composition
(Reporter)

Comment 11

16 years ago
I doubt if it is the size problem of HTML message I'd like to forward...????
Accepting
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Reporter)

Comment 13

16 years ago
Created attachment 81992 [details]
This simple HTML could not be forward as inline....
(Reporter)

Comment 14

16 years ago
Created attachment 81993 [details]
Simple HTML source which could not be forward as inline. Mozilla looks like  stalled.

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

Comment 15

16 years ago
Mozilla 0.9.9+ build 2002050108 still has this issue.

Comment 16

16 years ago
Created attachment 82430 [details]
HTML spam I received which hung MozRC1 when forwarding inline

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%.
(Reporter)

Comment 17

16 years ago
Created attachment 82464 [details]
Another message can not be forwarded as inline.
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
Keywords: dataloss, nsbeta1
Target Milestone: --- → mozilla1.0.1
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.
Assignee: ducarroz → jaggernaut
Status: ASSIGNED → NEW
Component: Composition → String
Keywords: mailtrack
Product: MailNews → Browser
QA Contact: olgam → scc
Summary: Can not Forward epost (HTML format ) as Inline !! → hang in copy_string while forwarding epost (HTML format ) as Inline !!
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 >

Comment 24

16 years ago
Nav triage team: nsbeta1+, adt2 rtm
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 rtm]
(Reporter)

Comment 25

16 years ago
Created attachment 82775 [details]
A message contains *no* HTML tag, still hang... 

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...
Created attachment 83052 [details] [diff] [review]
Proposed fix by Jag, v1

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
Attachment #83052 - Flags: review+
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.
Attachment #83052 - Flags: superreview+
Fix checked in the trunk. This is a simple fix that prevent an application
freeze, we should consider taking it for RTM
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Assignee)

Updated

16 years ago
Keywords: adt1.0.0

Comment 31

16 years ago
adding adt1.0.0+.  Please get drivers approval and then checkin to the 1.0 branch.
Keywords: adt1.0.0 → adt1.0.0+
(Reporter)

Comment 32

16 years ago
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.
(Reporter)

Comment 33

16 years ago
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.
(Reporter)

Comment 35

16 years ago
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
Attachment #83052 - Flags: approval+

Updated

16 years ago
Blocks: 143200
Fix checked in the branch
Keywords: fixed1.0.0
(Reporter)

Updated

16 years ago
Depends on: 144658
(Reporter)

Comment 39

16 years ago
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 ? 

Updated

16 years ago
No longer blocks: 143200

Updated

16 years ago
Whiteboard: [adt2 rtm] → [adt2 rtm] custrtm-
(Reporter)

Comment 40

16 years ago
Created attachment 86038 [details]
This pic shows the problem of fix.

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.
(Assignee)

Comment 41

16 years ago
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?

Comment 42

16 years ago
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.
(Assignee)

Comment 43

16 years ago
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.
You need to log in before you can comment on or make changes to this bug.