280711 - Corrupt display under XP when scrolling through output from Trac source code browser

Status: VERIFIED FIXED

(Core Graveyard :: GFX: Win32, defect)

Description

[David Rochberg]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When I load the page (and associated css) at 
  http://david.rochberg.com/tmp/firefox_scroll_bug.zip
and then scroll down, I see a corrupted display (same lines repeating over and
over again)  If I send Mozilla to the back and bring it to the front, the
corrupted area is not redrawn.


Reproducible: Always

Steps to Reproduce:
1.  Unpack http://david.rochberg.com/tmp/firefox_scroll_bug.zip
2.  Bring up the page firefox_scroll_bug/sanitized.htm
3.  Search for "Trouble starts around here"
4.  Scroll down with the down-arrow key

Actual Results:  
The line 
qqq (q = 0 ; q < qqqq ; q++) {
is displayed repeatedly

Expected Results:  
The remainder of the page should have been displayed

I am told that this does not occur under Linux.

The code in question was generated by the "Trac" source code browser.

Any sort of downward scrolling works to repro.

Comment 1

[DStile]

Just confirming that as reporter stated this works for me on Mandrake Linux 10.1
using Firefox nightly [ Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b)
Gecko/20050118 Firefox/1.0+ ].

Comment 2

[David Rochberg]

That .zip file made a lot more sense when I was planning to attach it to the bug.

I've unpacked it so you can skip that step though:
http://david.rochberg.com/tmp/firefox_scroll_bug/sanitized.htm

Comment 3

[David Rochberg]

At the behest of my shadowy masters, I have downloaded the trunk build
  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050201
and I'm afraid to say I see the same behavior with that build.

Comment 4

[Gérard Talbot]

> I'm afraid to say I see the same behavior with that build.

I'm using Mozilla 1.8b build 2005020106 under XP SP2 and I do see the wrong
behavior but the page is very long (1404 lines) and there are so many "q"
(17,924) everywhere...

Error: qqqqqqqqqqqqqqq is not defined
Source File: http://david.rochberg.com/tmp/firefox_scroll_bug/sanitized.htm
Line: 1289

Note that your file
http://david.rochberg.com/tmp/firefox_scroll_bug/sanitized.htm
has 1765 markup errors and has 966 markup errors if I choose HTML 4.01 strict.
Your bugreport certainly needs a reduced testcase.

What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

trac.css and browser.css (and that one imports @import url(code.css); on top of
that!) have hundreds of css declarations.
The view source will show many q in bold red color, maybe/most likely confused
by <q as start-tag for the q element.
Eg: line 597:
   q->qqqqqqq &= ~(0<<qqqqqqq_qqqq_qqqq); <I><span class="code-comment">/*

Comment 5

[David Rochberg]

Fair points, all of them.  My anonymizer script made a bad situation worse. 
Here is a smaller, stand-alone test case with fewer q's that validates CSS and
HTML4.01.

http://david.rochberg.com/tmp/firefox_scroll_bug/smaller.html

The problem still seems length-dependent---the trouble starts only after line
comment963.   If I remove the first 100 commentXXX lines, the problem does not
occur.

Comment 6

[Ere Maijala (slow)]

Looks like nsRenderingContextWin::ConditionRect is being called with wrong
coordinate set. Investigating.

Comment 7

[Ere Maijala (slow)]

I can't decipher the coordinate stuff going on in nsViewManager and
nsRenderingContextWin, bailing out :(

Basicly things go wrong when the view manager tries to set the clip rect to y
coordinates > 16384. ConditionRect in nsRenderingContextWin truncates the rect
so it fits in 16384 (apparently higher values wouldn't work for Win 95 and 98).
Why are we using such coordinates is beyond me.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is basically just "16-bit coordinates suck".

The overflow:auto element tries to create a widget that's > 2^14 pixels tall. We
do something to stop that killing us on Win9x. Now the widget isn't as tall as
it's supposed to be so we don't paint the bottom of the text.

We *could* fix it, I suppose, by somehow making too-large scrollareas not have a
widget at all. But I wouldn't really be able to test such a fix. This could be
done in the viewmanager by having the nsScrollPortView destroy its widget if its
size gets too large.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OTOH this would require reparenting any child widgets...

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Well that's probably not quite accurate ... we create a widget that's too big,
and then ConditionRect stops us from painting it. Similar solution probably...

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

ere, can you figure out what coordinates GDI can handle on different Windows
versions? My guess is that on all NT-derived versions, we don't need to do
ConditionRect at all. If so, then we should stop doing it on NT-derived versions
so things will just work there. That should make David happy.

Comment 12

[Ere Maijala (slow)]

Sure, that would be increasingly useful as old Windows versions get more rare.
Re-taking the bug if that's an acceptable solution. 

I'll try to find out if there actually is a limit on NT-based systems. At least
it's not as low.

Comment 13

[Ere Maijala (slow)]

Attachment: Patch v1.0

According to my tests there doesn't seem to be a limit in NT level Windows
versions. This patch removes the constraints for those. I also fixed some
comments and removed one redundant comment. I tested this patch on WinXP and
Win98SE. Works great in XP and "works" as before in 98.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 173783 [details] [diff] [review]
Patch v1.0

excellent!

Comment 15

[bk039]

*** Bug 281329 has been marked as a duplicate of this bug. ***

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 173783 [details] [diff] [review]
Patch v1.0

a=asa for 1.8b checkin.

Comment 17

[Ere Maijala (slow)]

Fix checked in.

Comment 18

[David Rochberg]

Now works for me.  Thanks very much.