211377 - Browser response (everything) becomes VERY slow on pages with large numbers of images.

Status: RESOLVED DUPLICATE of bug 213391

(SeaMonkey :: General, defect)

Description

[J Vender]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624

When visiting the page at http://www.kucinich.com , the browser response becomes
extremely slow. Scrolling becomes sluggish, toolbar buttonovers become slow and
delayed to respond... everything about the browser becomes intollerably slow to
respond. Bringing up the Preferences panel is also very slow to repond. This
page (http://www.kucinich.com) demonstrates the bug. If the radio button "do not
load any images" is selected in Preferences/Privacy&Security/Images, the browser
response returns to normal.

Reproducible: Always

Steps to Reproduce:
1.Visit the page and allow the browser to load it all, including all the images
(at least images on the same server)
2.Wait for the page to finish loading
3.Try to scroll, bring up preferences panel, move mouse over the toolbar buttons
and watch how the response is sluggish, slow and delayed.
4.Now, turn off loading of all images and reload the page. Now try scrolling,
accessing browser settings, etc... RETURNS TO NORMAL RESPONSE!
Actual Results:  
Self-explanatory

Expected Results:  
Loaded the images and then responded with the normal speed to scrolling and
mouseovers, dropdowns etc...

I've tested the same page using Internet Explorer 6SP1 and it doesn't suffer the
same problem on this site. (Don't worry, I'm a mozilla user).

It almost seems like it's in a loop or something, but it isn't crashing or
locking up, just getting VERY VERY slow to respond to any browser events.

This doesn't really fit the "major feature is broken" model because it's not
technically broken, but it's more critical that just "normal, needs fixed"
because there are a lot of websites with lots of images. It will be encountered
daily. Anyway, I chose "broken" to emphasize that it's a serious problem that
needs fixed immediately.

Comment 1

[J Vender]

CORRECTION TO ORIGINAL REPORT:
The URL for the page to test this bug was not entered correctly (wrong website).
The URL should be http://www.kucinich.net

Comment 2

[Jason Barnabe (np)]

WorksForMe on WinXP Moz 2003070107.

Comment 3

[Javier Martinez]

The problem also exists in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.5) Gecko/20031007

I've seen the problem happening in several sites with large ammount of images.
What I observe is the browser failing to process the paint message. It happens
in the client as well as the nonclient area.

The client area can be forced to redraw by scrolling the page. Some parts of the
nonclient area can be forced to redraw by moving the cursor on top of the items
(i.e. close tab icon and the browsing animated icon). Switching between tabs
doesn't refresh the client are and one has to scroll to get the content to show.

Closing the tab that has the large number of images solves the sluggishness. I
haven't seen mozzi crash due to this problem but it's really annoying.

The link given by J Vender works for me too. It must have changed since it
currently doesn't have a significant amount of images. I've "found" some others
that cause the problem but they include nudity. If it's ok I'll post the link.

Thank you,
Javier

Comment 4

[Pete Lin]

Hi

I was viewing this page when it happened.

http://www.jasonpan.com/china/

The guy has a large number of hi-res images on the page, and Firebird actually
crashed W2K.

Comment 5

[Bogdan Stroe]

Something similar is reported in bug 225977.

Comment 6

[Daniel de Wildt]

Sounds more like a dup of bug 213391.
What shows the memory cache if you enter about:cache after you loaded the images?
Is 'Storage in use:' greater then 'Maximum storage size:'? If yes, then it's a
dup of bug 213391. 
Marking this bug as a duplicate because that bug contains more information.
Please reopen this bug if you think this is no dup ('Storage in use:' is less
then 'Maximum storage size:')

*** This bug has been marked as a duplicate of 213391 ***