[PP] {perf} Layout of large HTML files goes wrong

VERIFIED FIXED in M11

Status

()

P3
normal
VERIFIED FIXED
20 years ago
15 years ago

People

(Reporter: erik, Assigned: buster)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Perf], URL)

Attachments

(4 attachments)

(Reporter)

Description

20 years ago
To test the layout engine, I selected a link (7.5 or something) from the above
URL which is a table of contents of a *large* html file. What I am shown is some
blue text on a black background (the previous page was blue visited links on a
black background...). I've tried it for four times or something alike, and every
time the page got messed up.

Updated

20 years ago
Assignee: rickg → chrisd

Comment 1

20 years ago
Chris -- can you please test this on NT ad 9x, and let me know how prolific the
problem is?

Updated

20 years ago
Assignee: chrisd → rickg
QA Contact: 4144 → 4110
Summary: Layout of large HTML files goes wrong → [PP]Layout of large HTML files goes wrong

Comment 2

20 years ago
Tested this page using 5/7 Apprunner on Win NT, Win 95, Win 98, Mac8.5 and
Linux. Clicked on the '7.5' link which began to load:

http://www.tcx.se/Manual/manual.html#DROP_DATABASE

Results as follows:

Win NT: Page loaded although it took about 5 min. Able to scroll to bottom
(slowly) with no problems.

Win 95, Win 98 and Linux: Page is corrupted while loading (text over text, etc).
After 20 minutes, status indicates still loading (except for Win 95 which says
'Done'). At this point I am able to scroll to the top where the display is now
clear. However, scrolling from the top, I am only able to scroll down to about
the '3.5' indicator and then the page is once again corrupted.

Mac8.5: Page is corrupted from the beginning. After 20 minutes, status indicates
that data is still being transferred. If I go to the top of the page, it is
still corrupted. This had the most buggy behavior of all platforms.

Changing 'Assigned to' to rickg and will put myself on as QA contact. Also,
changing to PP bug as this only works on Win NT.

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

20 years ago
Assignee: rickg → kipp
Status: ASSIGNED → NEW

Comment 3

20 years ago
Kipp -- this is a pathologically huge document, and it exacerbates our content
append performance issue. The other issues referred to here are likely the
result of the CPU being sucked up by layout/content append. Let's start there.

Updated

20 years ago
Status: NEW → ASSIGNED
Summary: [PP]Layout of large HTML files goes wrong → {perf} [PP]Layout of large HTML files goes wrong
Target Milestone: M15

Updated

20 years ago
Summary: {perf} [PP]Layout of large HTML files goes wrong → [PP]Layout of large HTML files goes wrong
Whiteboard: [Perf]

Comment 4

20 years ago
putting on [Perf] radar

Comment 5

20 years ago
*** Bug 8471 has been marked as a duplicate of this bug. ***

Updated

20 years ago
Blocks: 8691

Comment 7

20 years ago
*** Bug 10004 has been marked as a duplicate of this bug. ***

Comment 8

20 years ago
There are also memory issues associated with large files.  For example, on one
large 760K page (bug 10004), memory usage jumped from 12Mb to 72Mb while loading
and displaying the page.  This put document memory use at around eighty times
larger than file size.  (Linux, Necko apprunner from 3PM 7/27)

Comment 9

20 years ago
I think I was hit by the same problem --with a home-compiled 1999-09-02-08-M9.
Here are some screenshots. Is it what you see too ?

I noticed that this problem often arises when lots of :
 Block(body)(1)@0x831a468: WARNING: desired:8655,5898823
 nsBlockReflowContext: Block(body)(1)@0x831a468 metrics=8655,5898823!
 Area(html)(-1)@0x88a84e0: WARNING: desired:8885,5899418
appear on the console...

(heavily compressed jpeg's to save bandwidth)

Comment 10

20 years ago
Created attachment 1567 [details]
loading of http://www.fr.debian.org/Bugs/db/ix/full.html is long (3168 K)but OK

Comment 11

20 years ago
Created attachment 1568 [details]
it's OK too when you begin to scroll, but it goes wrong rapidly (see the position of the slider)

Comment 12

20 years ago
Created attachment 1569 [details]
it becomes worse when you keep on scrolling down. resizing the window does not refresh or anything.

Comment 13

20 years ago
Created attachment 1570 [details]
but when you arrive to the bottom of the document, it's clean again !
The screenshots given look a lot like the bug 1077 problems.  Perhaps that needs
to be re-investigated.  I believe the previous solution only increased the
available space by a factor of 15 (well, actually t2p, which varies).

I'll try and look into it if I have time, which is unlikely.
Many of the comments on this bug are really duplicates of bug 1177 / bug 2564.
However, there seem to be some performance issues here too as noted by rickg and
pollman.

There is no need to reopen bug 1177 (and certainly not 1077!!) because bug 2564
currently covers the Linux problems.

Updated

20 years ago
Summary: [PP]Layout of large HTML files goes wrong → [PP] {perf} Layout of large HTML files goes wrong
Target Milestone: M17 → M12

Comment 16

20 years ago
The page now renders OK (however the background doesn't paint very nicely
because of the large size of the content area; the rest does paint fine however;
bug 2564 remains the correct bug for handling the painting issue.

However, the loading time for this page is hideous. Moving up to M12 so that at
least some analysis will be done before beta.

Comment 17

20 years ago
*** Bug 4957 has been marked as a duplicate of this bug. ***

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED

Comment 18

20 years ago
The issue here was directly related to 7455 which has been fixed. The painting
bug already has a seperate bug # so I'm closing this bug.

Updated

20 years ago
Target Milestone: M12 → M11

Comment 19

20 years ago
chrisd, can you verify?

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 20

20 years ago
Using build 1999110309 on Linux. Page loads and scrolls with no corruption.
Verifying bug fixed.

Comment 21

19 years ago
*** Bug 18495 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.