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

VERIFIED FIXED

Status

Core Graveyard
GFX: Win32
VERIFIED FIXED
13 years ago
8 years ago

People

(Reporter: David Rochberg, Assigned: Ere Maijala (slow))

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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

13 years ago
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+ ].
(Reporter)

Comment 2

13 years ago
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
Component: General → Layout: View Rendering
Product: Firefox → Core
Version: unspecified → 1.7 Branch
(Reporter)

Comment 3

13 years ago
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

13 years ago
> 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">/*
(Reporter)

Comment 5

13 years ago
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.



(Assignee)

Comment 6

13 years ago
Looks like nsRenderingContextWin::ConditionRect is being called with wrong
coordinate set. Investigating.
Assignee: firefox → emaijala
Status: UNCONFIRMED → NEW
Component: Layout: View Rendering → GFX: Win32
Ever confirmed: true
Version: 1.7 Branch → Trunk
(Assignee)

Comment 7

13 years ago
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.
(Assignee)

Comment 12

13 years ago
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
(Assignee)

Comment 13

13 years ago
Created attachment 173783 [details] [diff] [review]
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.
Attachment #173783 - Flags: review?(roc)
Comment on attachment 173783 [details] [diff] [review]
Patch v1.0

excellent!
Attachment #173783 - Flags: superreview+
Attachment #173783 - Flags: review?(roc)
Attachment #173783 - Flags: review+

Comment 15

13 years ago
*** Bug 281329 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

13 years ago
Attachment #173783 - Flags: approval1.8b?

Comment 16

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

a=asa for 1.8b checkin.
Attachment #173783 - Flags: approval1.8b? → approval1.8b+
(Assignee)

Comment 17

12 years ago
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Reporter)

Comment 18

12 years ago
Now works for me.  Thanks very much.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.