Closed
Bug 381578
Opened 18 years ago
Closed 10 years ago
rendering becomes corrupt after about half of the page + images are loaded
Categories
(Core Graveyard :: GFX, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: bugzilla.mozilla.org, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070521 Minefield/3.0a5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070521 Minefield/3.0a5pre
The provided URL is a long forum topic with a huge amount of images:
Documents (1 file) 118 KB
Images (205 files) 11000 KB
Scripts (3 files) 33 KB
Style Sheets (3 files) 17 KB
-----------------------------------
Total 11168 KB
it takes quite some time to load all the images. Minefield works fine until about half of all the images are loaded. I can scoll up and down, jump HOME and END etc. But then, once more images get loaded, Minefield stops updating the display/rendering. I see the "position marker" on the scroll bar moving up and down when I scroll but the display remains what was visible
Reproducible: Always
Steps to Reproduce:
1. load given URL
2. while page is loading images scroll up and down
3. do so until you see rendering becoming corrupt
The given URL loads and gets displayed fine in Firefox-2.0.0.3 and MSIE 6.
Interesting observation on memory usage after loading the huge page in minefield compared to others:
MSIE 6: 411MB virtual 319MB working set 310MB Private bytes
Firefox 2: 418MB 353MB 342MB
Minefield: 103MB 40MB 29MB
(Firefox 2 with a couple of extensions loaded)
Reporter | ||
Updated•18 years ago
|
Version: unspecified → Trunk
Reporter | ||
Comment 1•18 years ago
|
||
Slight correction: not only the display but the rendering of whole UI becomes corrupt
Comment 2•18 years ago
|
||
Maybe dupe of/related to bug 366548.
What's your GDI usage like at the page? (You can add it as a column to the Task Manager process list)
Reporter | ||
Comment 3•18 years ago
|
||
two further observations:
I started a 2nd independent instance of minefield to report this bug but this instance seemed also affected and showed corrupt rendering.
While writing the report and reading on some other bugreports in FF2, the Minefield browser window was still open and has kind of recovered a bit by now. the UI is partly working again and I can scroll the huge page again and see the content. But it seems that not all of the linked images are really loaded.
Weird: although the page looks ok now when scrolling with the cursor keys or mouse, I just used FAYT to search for "Antwort", then use "F3" key and when doing so the rendering acts strange, images overlaying text, only parts of the screen get updated. As soon as I scroll normally the rendering goes back to normal.
The second parallel instance also has mostly recovered but resizing any of the the two windows still leaves artifacts on screen.
GDI objects in Minefield showing the huge page at this point in time: 2,120
Comment 4•18 years ago
|
||
i cannot reproduce with current nightly, do you still see that?
Reporter | ||
Comment 5•18 years ago
|
||
unfortunately the testcase is gone. Most posts of the forum topic are gone, moved to a different web site and organized in a more browser-friendly way.
the size of the images is only 1/10 now
Documents (1 file) 79 KB
Images (62 files) 1059 KB
Scripts (3 files) 33 KB
Style Sheets (3 files) 11 KB
Total 1182 KB
I'll try to create a new testcase for this issue.
Reporter | ||
Comment 6•18 years ago
|
||
created a new test case
http://www.ja-web.de/Screenshots/X-Plane/huge-page-index.php?n=1
change the "1" at the end to a higher number to get more images on the page.
I tried 500 with FF-2.0.0.4 and MSIE6, booth showed the page without issues, both wehere using about 900MB Virtual memory. (The FF2 number below is with additional tabs open)
A current FF-3 Nightly will load the page too and it looks ok until you start to scroll down: then the content and even the UI become corrupt (put some other window in front of FF3 and take it away)
Process Explorer shows
<pre>
Process Virtual Size Working Set Private Bytes GDI Objects Command Line USER Objects
------------------------------------------------------------------------------------------------------------
firefox.exe 1.135.060 K 1.006.588 K 994.728 K 184 FIREFOX_2\FIREFOX.EXE 108
firefox.exe 130.152 K 51.556 K 41.220 K 1.856 firefox_3\firefox.exe 58
</pre>
So, FF3 memory consumption remains rather low but GDI object count goes way up compared to FF2
Reporter | ||
Updated•18 years ago
|
Reporter | ||
Comment 7•18 years ago
|
||
changed the test page slightly to see the impact of image sizes
http://www.ja-web.de/Screenshots/X-Plane/huge-page-index.php?t=1&n=1
will show number of n thumbnail images
http://www.ja-web.de/Screenshots/X-Plane/huge-page-index.php?n=1
as before, shows number of n large images
Comment 8•18 years ago
|
||
i get about your same results for memory consumption and gdi objects
but i don't get graphic artefacts on page or on gui
Component: General → GFX
Product: Firefox → Core
QA Contact: general → general
Comment 9•18 years ago
|
||
i can finnaly reproduce also artefacts problem, it hangs somehow and does not redraw moving a window in front of it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 10•17 years ago
|
||
bug 366548 is now fixed - can you check if tomorrow's build (20071004 or later) fixes it ?
Reporter | ||
Comment 11•17 years ago
|
||
yes, the rendering is fixed now
the example from comment #6 http://www.ja-web.de/Screenshots/X-Plane/huge-page-index.php?n=500 loads and renders fine now.
But the cost is an rather huge memory consumption, far more than FF2 uses in the same page (compare to comment #6)
firefox3.exe 1.317.620 K (Virtual) 1.232.248 K (Working set) 1.220.096 K (private) 1.228 (GDI)
Comment 12•17 years ago
|
||
So can we now mark this bug as a dupe of bug 366548 and note that you have filed bug 398983 wrt the increase in memory usage?
Assignee | ||
Updated•16 years ago
|
Product: Core → Core Graveyard
Comment 13•10 years ago
|
||
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.
[Mass-change filter: graveyard-wontfix-2014-09-24]
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•