Closed Bug 98626 Opened 23 years ago Closed 22 years ago

100% CPU viewing e-mail w/ a background image

Categories

(Core :: Graphics: ImageLib, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: smoehle, Assigned: Bienvenu)

References

Details

(4 keywords, Whiteboard: MS Outlook [adt needinfo])

Attachments

(6 files, 1 obsolete file)

When I view the multipart-mime news article (spam) in the Big5 character set from "t22116@ms53.url.com.tw" in "netscape.public.mozilla.general" and other groups, Mozilla takes 100% of the CPU and Mail/News becomes completely unresponsive until I switch to a Navigator window at which point the CPU usage drops to 0. If I switch back to Mail/News, the CPU usage goes up to 100% again. Mozilla trunk build 2001090603 on Win2000.
Attached file The news article causing the problem (deleted) —
This is not a Mail/News problem. I get it in the browser as well if I extract the MIME encoding to an html file and load it. I'll attach the file.
Attached file html extracted from news article (deleted) —
I spoke too soon... All of the sudden I can't reproduce this in the browser. But it still happens in the 3-pane view as well as the window that comes up when I double-click the mail message. The 100% CPU usage continues as long as the message is visible. Minimize it, or at least cover the content area up with another window, and the CPU usage drops back down to 0%. There is another problem I'm having which is triggered by a drop-down box (for example <select><option>Slow!!!</option></select>, actually bugzilla's own drop-down boxes will do it) being visible which behaves exactly like this. It causes 100% CPU usage, UI unresponsiveness, and just like this problem, it goes away when covered up by another window. In fact, simply cover up the down arrow of the combo box with a tiny window, and the CPU usage goes back down to zero. Bizarre. I'm guessing these two problems are somehow related, and probably have a common solution.
On a hunch, I removed the GIF image from the mutlipart message and viewed it: no problem. I then went to Prefs -> Appearance -> Colors, and set it to "Use my colors", turning off that background image: no problem. I then set this pref back to normal, and sent myself a message containing a GIF image as a background: 100% CPU usage! Tried again with a JPEG background: 100% CPU usage! Tried image alone, not as a background: no problem. Then I sent myself a table with an image sent as a background: 100% CPU usage! Covering up just the table put the CPU usage back down to zero, just like with the down arrow on a drop-down box. My theory is that Mozilla has a problem loading a background image from an unusual protocol handler. This comes into play when a mail message has a background image, as well as on the drop-down boxes which must internally use a background to display the arrow image. Note: If you want to try mailing yourself like I did above, you have to use Netscape 4 as Mozilla seems to not support multipart messages. It just leaves the links as file:// URL's rather than including them in the message, which doesn't produce this problem.
*** Bug 99078 has been marked as a duplicate of this bug. ***
Changed summary from "Viewing a certain news article causes 100% CPU usage" to "100% CPU viewing e-mail w/ a background image". I see this too on trunk build 2001091003, w2k SP2; have e-mailed myself a simple message w/ a background image, Mozilla uses 100% CPU when viewing the message.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Viewing a certain news article causes 100% CPU usage → 100% CPU viewing e-mail w/ a background image
Problem still here, build 2001092803, Win2K
Using Build 2001100803 on W2K, the problem has changed a little and got a bit less severe: Now, going to a message with a background window still causes the cpu to go to 100% and stay there, but I can switch to another message in the same folder and the cpu goes down to normal again. Can anybody on the cc-list confirm that?
Yep, I see that too. The UI remains responsive, and changing to another message works just as fast as it does from a normal message. It still stops the content of the message and folder pane from refreshing while the CPU is at 100%, though.
Status: NEW → ASSIGNED
*** Bug 132065 has been marked as a duplicate of this bug. ***
ducarroz seems to think this is an imagelib problem.
Assignee: sspitzer → pavlov
Status: ASSIGNED → NEW
Component: Mail Window Front End → ImageLib
Keywords: mailtrack
Product: MailNews → Browser
QA Contact: esther → tpreston
This bug REALLY needs to get bumped up to higher priority or resolved, as it makes interoperating with people who use MS Outlook a pain in the butt. There are several people I deal with who use Outlook, and have it set by default to send a background image. Whenever I get one of these emails and open it, the mouse goes absolutely nuts due to the 100% usage - there is a couple second lag between moving the mouse and getting any kind of response, which makes it hard to even close the window without using keyboard shortcuts. If a new user were to switch from Outlook to Mozilla for the first time and experience this, I guarantee they would immediately switch right back. (Bug is still present in 2002040203)
nominating nsbeta1
Severity: normal → major
Keywords: nsbeta1
Whiteboard: MS Outlook
*** Bug 133696 has been marked as a duplicate of this bug. ***
pav can you investigate what's going on here and let us know how big an effort/fix/risk this is?
Whiteboard: MS Outlook → MS Outlook [adt needinfo]
a mail to reproduce problem can be found at: http://bugzilla.mozilla.org/attachment.cgi?id=76392&action=view
*** Bug 106731 has been marked as a duplicate of this bug. ***
*** Bug 126599 has been marked as a duplicate of this bug. ***
*** Bug 132745 has been marked as a duplicate of this bug. ***
*** Bug 101819 has been marked as a duplicate of this bug. ***
related: bug 96633
Target Milestone: --- → mozilla1.0.1
This bug is still causing problem on Mozilla 1.0 Release Candidate 1 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417
"100% CPU viewing e-mail w/ a background image" seems to be fixed in mozilla 1.0 RC2, tested on german version :-)
It is not fully fixed in rc2 or rc3 us version on w2k, as my run bar still goes to 100% when viewing an email with background image, running down my batteries... It looks like responsiveness has been addressed, however; maybe the thread was given lower priority.
*** Bug 147607 has been marked as a duplicate of this bug. ***
This is not limited to Outlook messages - tested with a message created in RC3/Win98 and viewed in RC3/Win98. CPU goes to 100% and system lags for 20-30 seconds before responding to any input. The same message viewed in Linux displays correctly with no extra CPU usage. Please maintain high priority, this bug looks like a hang to users.
Sorry for the spam, but this bug is in the 1.0 Win release, and there's been no apparent activity in over a month. Is work being done on this? It's probably the most irritating bug that I regularly encounter.
*** Bug 154523 has been marked as a duplicate of this bug. ***
"workaround": enable 'do not load remote images in Mail & Newsgroup messages'
It's only mail-embedded wallpaper that has a problem and not all remote images...
*** Bug 157075 has been marked as a duplicate of this bug. ***
Same problem occurs if you add a background image than do file, save as, a template.
*** Bug 163369 has been marked as a duplicate of this bug. ***
Attached file testcase (deleted) —
Will not work when opened in Navigator. Must be opened in Mail to reproduce.
Severity: major → critical
Keywords: hang, testcase
the problem occurs only when the background image URL is a mailbox url. I can reproduce this problem in message display, message compose or composer (editor). Looks like we are repaint infinitively the image! Pavlov, mscott, any idea what could append here! We really need to fix this problem for buffy.
I'm not sure how to add an email to bugzilla but I will gladly send an email to anyone interested in this bug. Just send me an email tpreston@netscape.com and I will send to you. It involves a person using MS Outlook and having Stationary as the mail format. You are forced to close the mail window everytime.
*** Bug 167031 has been marked as a duplicate of this bug. ***
With Win98 Mozilla 1.1 CPU usage is regular
With Win98 Mozilla 1.1 CPU usage is regular
Attachment #98102 - Attachment is obsolete: true
Still 100% CPU usage with Windows 2000 Professional and Mozilla 1.1
Keywords: mozilla1.2, perf
*** Bug 168088 has been marked as a duplicate of this bug. ***
(from duplicate bug) Still happens with 2002090908 1.2a build on W2K.
*** Bug 142700 has been marked as a duplicate of this bug. ***
*** Bug 145046 has been marked as a duplicate of this bug. ***
Where would I start to try and help track this down? This is one of my biggest pet-peeves with MailNews -- my boss unfortunately uses Outlook w/ stationary, and every time I read an email from him I get the said symptoms occuring. The actual patch could be a bit beyond me (I've followed the codebase for some years and made a few minor patches, but I don't know it in-depth!), but I'd like to help at least try and identify where in the code this is occuring if I can...
Keywords: embed
*** Bug 99930 has been marked as a duplicate of this bug. ***
QA Contact: tpreston → gayatri
OK, the problem seems to be that imglib thinks the jpeg is animated. imgRequest::NotifyProxyListener seems to think that if there are any observers, it must be an animated image. My guess is that this is not true in this case. But I'm completely ignorant about imglib... if (mImage && (mObservers.Count() == 1)) { LOG_MSG(gImgLog, "imgRequest::AddProxy", "starting animation"); mImage->StartAnimation(); }
just stepping through the code, it seems like for other images, there are two observers, so we don't get into this animation code, but for background images in mail, there's only one and we get into this code. I'm a bit stuck about how to proceed - I don't have enough information to figure out how to stop this...
another interesting tidbit - after clicking on a message like this, and closing the window, I crashed in the nsTimerImpl destructor, so that popular crash might be related.
QA Contact: gayatri → yulian
taking, I have a fix.
Assignee: pavlov → bienvenu
Attached patch proposed fix (deleted) — Splinter Review
fix is to our mailnews base url ::Equals method - we need to compare the two base uris to each other, not our base uri with the other uri's real uri. I've tried displaying mail messages with relative uri's, and haven't had a problem.
Comment on attachment 100480 [details] [diff] [review] proposed fix sr=sspitzer
Attachment #100480 - Flags: superreview+
Comment on attachment 100480 [details] [diff] [review] proposed fix r=mscott
Attachment #100480 - Flags: review+
this fix works for imap and local, but not news - news seems to be munging its uri's by chopping off the ?part=1.2 kind of thing so the comparison still fails, leaving us in the situation we're currently in. The patch is still valid, but we need to fix the news code in order to fix this bug for news.
Can we (please) have the Mail-related fix now if it's ready?
When I'm done testing it, I'll check it in. I hope that will be today.
fix checked in. I'll spin up a new bug for news messages.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Keywords: adt1.0.2
good job David!
The bienvenu stands up and bows. --more-- The crowd cheers wildly.
Verified with 20020926 trunk build. Viewing e-mail w/background image doesn't cause 100% CPU usage problem any more. Great fix!
Status: RESOLVED → VERIFIED
Attached patch 1.0 branch patch (deleted) — Splinter Review
identical patch for 1.0 branch
Comment on attachment 100808 [details] [diff] [review] 1.0 branch patch sr=mscott for the 1.0 branch patch.
Attachment #100808 - Flags: superreview+
Comment on attachment 100808 [details] [diff] [review] 1.0 branch patch Carrying forward r= a=rjesup@wgate.com for 1.0 branch. Change mozilla1.0.2+ to fixed1.0.2 when checked in.
Attachment #100808 - Flags: review+
adt+, please check in to the 1.0 branch and add the fixed1.0.2 keyword
Keywords: adt1.0.2adt1.0.2+
fix checked into branch.
Verified with 20020930 branch build on Win2K.
*** Bug 171251 has been marked as a duplicate of this bug. ***
*** Bug 47846 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: