Closed Bug 280711 Opened 20 years ago Closed 20 years ago

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


(Core Graveyard :: GFX: Win32, defect)

Windows XP
Not set


(Not tracked)



(Reporter: rochberg=bugzilla, Assigned: emaijala+moz)





(1 file)

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
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
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.
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+ ].
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:
Component: General → Layout: View Rendering
Product: Firefox → Core
Version: unspecified → 1.7 Branch
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.
> 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:
Line: 1289

Note that your file
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?

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">/*
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

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

Looks like nsRenderingContextWin::ConditionRect is being called with wrong
coordinate set. Investigating.
Assignee: firefox → emaijala
Component: Layout: View Rendering → GFX: Win32
Ever confirmed: true
Version: 1.7 Branch → Trunk
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.
Assignee: emaijala → win32
QA Contact: general → ian
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.
OTOH this would require reparenting any child widgets...
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...
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.
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.
Assignee: win32 → emaijala
Attached patch Patch v1.0Splinter Review
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.
Attachment #173783 - Flags: review?(roc)
Comment on attachment 173783 [details] [diff] [review]
Patch v1.0

Attachment #173783 - Flags: superreview+
Attachment #173783 - Flags: review?(roc)
Attachment #173783 - Flags: review+
*** Bug 281329 has been marked as a duplicate of this bug. ***
Attachment #173783 - Flags: approval1.8b?
Comment on attachment 173783 [details] [diff] [review]
Patch v1.0

a=asa for 1.8b checkin.
Attachment #173783 - Flags: approval1.8b? → approval1.8b+
Fix checked in.
Closed: 20 years ago
Resolution: --- → FIXED
Now works for me.  Thanks very much.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.