Closed Bug 193209 Opened 22 years ago Closed 20 years ago

{inc} Windows redraw problem

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 215055

People

(Reporter: baffoni, Unassigned)

References

(
URL
)

Details

Attachments

(4 files, 1 obsolete file)

scrolling down screenshot v1
26.52 KB, image/gif
Details
picture of problem described in comment 7
45.85 KB, image/png
Details
another picture of probem described in comment 7
185.45 KB, image/png
Details
revised testcase
21.91 KB, text/html
Details 
When I go to this website and scroll the list on the left, at a particular
point, the page stops scrolling new data properly.  I can scroll back up and it
works fine, but if I scroll down it redraws wierdly....
Not sure of the bug number, but this might be the problem with handling a page
with too many links in it.
The page has a really long list in the left frame. It does not draw properly, it
keeps flashing an extra full length scroll bar inside the first normal scroll
bar. It also hogs most of the machines resources, as I type this with the page
loading and loading and loading the letters appear about 1 per second, and I am
typing faster then that!

Moz 1.5rc1
w2k
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208

I see the same thing. I also tried scrolling down, during loading the page, and
it resulted in the screenshot "scrolling down screenshot v1."

I guess the "double" scrollbar is *also* there because Mozilla can't decide
whether to put a horizontal scrollbar there or something?
I'm working on making a test case.
I had a breakthrough.  I took the source code for the left frame and stripped
out everything piece by piece until I found the problem.  You'll notice that
when you load the testcase, that second right scroll bar keeps flashing in and
out, and eventually the whole screen gets blurred up.  (Actually, when I reload
the page, sometimes the screen blurs up right away and sometimes it takes a
while).  The page also renders very slow, and CPU usage (on my 366 MHz
processor) is at 90% (but then drops down after the page gets blurred).

The blurring and the second scroll bar go away when you remove the
style="overflow:auto;" attribute of the <body> tag.  So this must be the root
of the problem.  (Even with this line removed, Mozilla still renders this page
far slower than IE and has 90% CPU ussage, but I think that is an issue related
to Bug 54542 - Large tables are slow.)
Another note: the problem also occurs when you use "overflow:scroll", but 
"overflow:hidden" and "overflow:visible" work fine.  Also, moving this style
attribute to inside table tag from the body tag makes the problem go away.

There are lots of bugs relating to the overflow CSS property.  While I didn't
find one related to the redraw/blurring problem in this bug, I found two that
mentioned the second, useless scrollbar:
Bug 107493  "scrollbars #3 overflow:scroll causes duplicate scrollbars"
Bug 199706  "Useless vertical scrollbar created in span with fixed position and
overflow: auto set"

Can someone verify if this bug applies to Linux and MacOS in addition to Win? 
We should also change component to Layout.
Some more insight.  I tried varying the number of rows in the table (by
commenting out rows).  If we limit the table to 744 rows (from start to
'fr.xbox'), there is no redraw problem (just an extra vertical and a horizontal
scroll bar).  If you add a few more rows, then the bottom of the screen becomes
some sort of separate text area - it tries to restart displaying from the top of
the table!  Watch what happens when you try to highlight this area with your
mouse, when you scroll up and then back down, or when other applications cover
Mozilla's portion of the screen and then are minimized.

What makes things even weirder is when you increase the size of the table by a
hundred or so more rows.  Now things get random.  Sometimes when you display the
page, you can use the second, inner, vertical scroll bar, which scrolls the
table on the top portion of the screen.  And by adding a few hundred more rows
on, the page will blur up again.  However, each time you hit 'refresh' the same
behavior might not occur!  They do some to happen more and more frequently as
the table gets bigger.
bz> doron: we reflow a partial page, that gives us a body height, then we reflow
the rest later and don't change the body height?
bz> doron: probably not fixable without dbaron's proposed changes to
shrink-wrapping in layout

We are assuming its inc. layout since a reload of the page fixes the isssue.
Assignee: asa → nobody
Component: Browser-General → Layout: Block and Inline
QA Contact: asa → core.layout.block-and-inline
Summary: Windows redraw problem → {inc} Windows redraw problem
Just to clarify in case there was a misunderstanding: a reload does not fix
the problem; for a large enough table, as in the testcase, the problem occurs
every time.

  Also, in comment 7, I wrote "If you add a few more rows, then the bottom of
the screen becomes some sort of separate text area - it tries to restart
displaying from the top of the table!"	I did not mean that the browser starts
redrawing from the top of the page.  What happens is that inside this "separate
text area", the browser can display rows from just about anywhere in the table.
 This attachment shows that.
This shows what happens when you minimize Mozilla and then maximize it again. 
My desktop is showing where that "separate text area" was.  Somehow it did not
get redrawn.
This looks very similar to bug 215055. Either should be marked as dup.
Attached file revised testcase — 
After viewing the slides on proper layout triaging from FOSDEM 2004, I decided
to revise my testcase.	It turns out this bug has nothing to do with tables; I
replaced the table with a div and the bug still shows.	Also, the DOM Inspector
shows that the bug starts appearing after what looks like 16,384 (=2^14)
pixels.
Attachment #137692 - Attachment is obsolete: true
(In reply to comment #11)
> This looks very similar to bug 215055. Either should be marked as dup.

I looked at the two testcases from that bug in detail and they essentially seem
to be the same as the one I just made, with the bug starting after 2^14 pixels.
 I think this bug should be marked as a dup of bug 215055.

*** This bug has been marked as a duplicate of 215055 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: