[DOGFOOD] [PP] Scrolling a long document yields text overwriting itself

VERIFIED FIXED in M11

Status

()

Core
Layout: Form Controls
P1
critical
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: Simon Fraser, Assigned: Stuart Parmenter)

Tracking

Trunk
Other
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] fix attached)

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
Load the above URL in viewer, and wait for it to finish loading. Then scroll
down. Notice that there are large areas which are completely blank (I see
two of them), as if some big chunks of the document have been rendered at
the wrong offset. There is nothing in the HTML that should cause these blank
areas.

This does not occur on Windows, where the entire file has no gaps.

An additional test would be to scroll the document up and down while it is
rendering, and see if that causes any positioning problems.

Updated

19 years ago
Status: NEW → ASSIGNED
OS: All

Comment 1

19 years ago
Bug #2385 also refers to big blank sections on the Mac.

Comment 2

19 years ago
Bug #2385 has been closed as dup of #2615. Apparently this problem and the one in
#2385/#2615 are different.

Comment 3

19 years ago
Inserting Milestone info.

Comment 4

19 years ago
Setting all current Open/Normal to M4.

Comment 5

18 years ago
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Updated

18 years ago
Target Milestone: M4 → M5

Comment 6

18 years ago
Changed target to M5

Updated

18 years ago
Target Milestone: M5 → M6

Updated

18 years ago
Target Milestone: M6

Updated

18 years ago
Assignee: pierre → kipp
Status: ASSIGNED → NEW
Hardware: Macintosh → All

Comment 7

18 years ago
I tried with a recent build on Windows and I got a very similar problem except
that instead of "big blank sections", we have big "black" sections. The "black"
sections contain text that is overlayed over and over.

Reassigned to kipp.

Comment 8

18 years ago
Bug #1117 might be related to this one.

Updated

18 years ago
Status: NEW → ASSIGNED
Priority: P2 → P3
Target Milestone: M9

Comment 9

18 years ago
I've fixed this on the Mac, still puzzled on Win95.

Updated

18 years ago
Assignee: kipp → ramiro
Status: ASSIGNED → NEW
Component: Layout → Widget Set

Comment 10

18 years ago
On linux we get smearing - it seems that the drawing of the background fails in
these situations. I suspect that the coordinate math isn't handling the large
coordinates that this results in (3,465,066 twips or 231,004 pixels!)
This is probably a coordinate overflow problem. On Win95
nsRenderingContext::SetClipRect and nsRenderingContext::FillRect need to have
the rectangles that they pass to the native rountines conditioned to prevent the
top and bottom of the RECT to be within WIN95's acceptable range. This is
probably what GTK needs as well.

Comment 12

18 years ago
Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze.  Widget Set component will be retired
shortly.

Updated

18 years ago
Target Milestone: M9 → M10

Comment 13

18 years ago
m10

Comment 14

18 years ago
Created attachment 1504 [details]
sample long doc

Updated

18 years ago

Comment 15

18 years ago
see also:

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=1357

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M10 → M11

Comment 16

18 years ago
Changed URL, marking assigned, m11.

I see the bug, the problem is that the arguments to XFillRectangle()
(gdk_draw_rectangle() actually) are overflowing at -(2^15) and +(2^16) cause of
the 'unsigned int' limit of x windows.

So, im going to add some code to clamp all arugments to X lib functions.

Comment 17

18 years ago
*** Bug 12298 has been marked as a duplicate of this bug. ***
This causes problems with http://www.w3.org/TR/REC-CSS1 once you've scrolled
about 2/3 of the way down.  I think it's the same problem as bug 1177 (not
1117!), which covered the fixes for Mac and Win95.
There are some comments relating to this bug on bug 6048.

Comment 20

18 years ago
*** Bug 13389 has been marked as a duplicate of this bug. ***

Comment 21

18 years ago
*** Bug 13657 has been marked as a duplicate of this bug. ***
*** Bug 14212 has been marked as a duplicate of this bug. ***
*** Bug 13690 has been marked as a duplicate of this bug. ***

Updated

18 years ago
OS: All → Linux
Hardware: All → Other
Summary: [PP] long document renders with big blank sections → [PP]Long document renders with big blank sections

Comment 24

18 years ago
I see the bug, the problem is that the arguments to XFillRectangle()
(gdk_draw_rectangle() actually) are overflowing at -(2^15) and +(2^16) cause of
the 'unsigned int' limit of x windows.

So, im going to add some code to clamp all arugments to X lib functions.

Comment 25

18 years ago
*** Bug 16045 has been marked as a duplicate of this bug. ***
*** Bug 16174 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Summary: [PP]Long document renders with big blank sections → [PP] Scrolling a long document yields text overwriting itself

Comment 27

18 years ago
As a courtesy, I've changed the bug description to reflect the behavior reported

by the many people who are still reporting this bug, in the hopes that it may be

easier for them to find. (Both here, and on the Most Frequent Bugs page.)
(Reporter)

Updated

18 years ago
Assignee: ramiro → pavlov
Status: ASSIGNED → NEW
(Reporter)

Comment 28

18 years ago
Reassign to pavvy pav pav

Comment 29

18 years ago
*** Bug 17238 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Blocks: 17432
(Assignee)

Comment 30

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

Updated

18 years ago
Severity: normal → critical
Status: NEW → ASSIGNED
Summary: [PP] Scrolling a long document yields text overwriting itself → [DOGFOOD] [PP] Scrolling a long document yields text overwriting itself
(Assignee)

Updated

18 years ago
Priority: P3 → P1
Created attachment 2519 [details] [diff] [review]
patch to fix bug
The above patch fixes the problem for me.  You might want to fiddle with the
numbers a little (perhaps even see how gdk_draw_rectangle works and give it more
margin for error if you think it's necessary).  Also, I'm not sure if it's
needed on InvertRect.  It probably is for DrawRect, though, since someone might
put a border around the CSS1 spec someday...

Updated

18 years ago
Whiteboard: [PDT+]

Comment 33

18 years ago
Putting on PDT+ radar.
Whiteboard: [PDT+] → [PDT+] fix attached
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 34

18 years ago
looks good.  checked in fix.

Updated

18 years ago
Blocks: 17907

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 35

18 years ago
Fixed in the Nov 12 Linux build.

Updated

17 years ago
No longer blocks: 17432

Updated

17 years ago
No longer blocks: 17907
You need to log in before you can comment on or make changes to this bug.