All users were logged out of Bugzilla on October 13th, 2018

Mozilla uses lots of CPU during "sending request to..."

RESOLVED WORKSFORME

Status

()

--
major
RESOLVED WORKSFORME
18 years ago
5 years ago

People

(Reporter: bischoff, Assigned: waterson)

Tracking

(Blocks: 1 bug, {hang, perf})

Trunk
Future
x86
Windows 2000
hang, perf
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001204
BuildID:    2000120420

While loading the page, the status bar displays "sending request to
dealnews.com" at several points. This is fine. However, during the "sending
request", the browser locks up -- scroll bars, menus and toolbars don't respond.
After the page is finished loading, things come back to normal.

Reproducible: Always
Steps to Reproduce:
1. Load the page
2. As the page is loading, try to scroll down the page (I think the page is
dynamically generated, so it could take a few seconds to load completely).
3. Notice that as soon as "sending request to dealnews.com" appears in the
status bar, the browser stops responding.

Actual Results:  The browser locks up until the page has finished loading.

Expected Results:  The browser should behave normally during "sending request
to" (menus and scrollbars should work, etc)

I checked the Bug-Query page to look for duplicates, and I didn't find any in my
brief search.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can confirm this bug with build 2000113020 / win2k SP1
Mozilla freeze while page loading.
This page is very big (>190k).

Comment 2

18 years ago
Not sure if this qualifies for the "freeze" keyword, but adding it together with
"perf" to indicate a "freeze" that goes away after some time.
Keywords: freeze, perf

Updated

18 years ago
Keywords: freeze → hang

Updated

18 years ago
Priority: P3 → --

Comment 3

18 years ago
I don't see any significant freeze here.  the page seems to load up in about 3
or 4 seconds during which time the CPU is used pretty heavily but not enough to
starve the UI.  tested 022209 mozilla win32 build on NT4
(Reporter)

Comment 4

18 years ago
Asa: 

Right -- it doesn't freeze anymore, but the Mozilla daily builds of three months
ago (when I first reported the bug) did freeze ;). I'm guessing that one of the
other bugs fixed between now and then resolved the freezing part.

So, perhaps the summary should be reworded to reflect that the current builds
use the CPU heavily on this page but the UI doesn't actually freeze?

Comment 5

18 years ago
updating summary. A testcase narrowing this down to whatever in the page is
causing the spike would be extremely helpful.
Summary: Mozilla locks up during "sending request to..." → Mozilla uses lots of CPU during "sending request to..."

Comment 6

18 years ago
Not sure if this is too helpful, but I see the CPU spike using Linux build
2001031208, and in Netscape 4.75, and also if I'm loading a local copy of the
page, and with image loading turned off.

Comment 7

18 years ago
I'll try to simplify this page over the weekend. A quick scan however shows that
it uses the width of td tags in a very inconsistent way. e.g.

- Make 3 cells in a row, giv one a fixed width of 9 (absolute) and the other
100%.and the last 9 (absolute again)
- Make 2 rows, each with one cell and set the width of the first at 96% and the
other at 98%
I remember an onld problem where mozilla had problems with a combination of
%,px,pt etc in one row....

Besides this, there are many nested tables (when wil the time come that HTML
designer do not use tables anymore for these kinds of layout issues? I HATE IT ;-) )

Comment 8

18 years ago
probably related to bug #43039 (and different other 'table' related bugs) So
this one should be probably assigned to karnaze@netscape.com as well.

Maybe I should triage these table-freeze bugs? And marking some as dups and
reassinging to one engineer...?

Comment 9

18 years ago
CC-ing myself, btw. it happens on Linux as well - OS -> ALL ? 

I'll look into the many <FONT> tags as well

Updated

18 years ago
Assignee: asa → karnaze
Component: Browser-General → Layout
QA Contact: doronr → petersen

Comment 10

18 years ago
updating component

Comment 11

18 years ago
Reassigning to waterson and moving to m1.0
Assignee: karnaze → waterson
Target Milestone: --- → mozilla1.0
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

17 years ago
Blocks: 103671

Comment 12

17 years ago
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1

Updated

17 years ago
Keywords: mozilla1.0+

Comment 13

17 years ago
loads fine for me on linux build 20020426 (800MHz, 256MB system) (even on my 266
MHz system it is ok....)
(Assignee)

Updated

17 years ago
Target Milestone: mozilla1.0.1 → Future

Comment 14

16 years ago
This bug is BACK AGAIN for:
Mozilla 1.1
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1) Gecko/20020826
(the standard download)

Platform is:
Linux 2.2.17 i586

(Bug was NOT in Mozilla 1.0)

Can someone go and fix this (again) now?
URL is dead, marking wfm because there is no testcase
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.