Closed Bug 126592 Opened 23 years ago Closed 18 years ago

native widgets limited to 16-bit coordinates cause errors on long pages

Categories

(Core :: Web Painting, defect, P1)

Product:
Core
Component:
Web Painting
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: sicking, Assigned: sfraser_bugs)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(3 files, 3 obsolete files)

screenshot of problem
42.81 KB, image/png
Details
Um... real better minimal testcase -- just look at the very bottom
289 bytes, text/html
Details
better fix for GTK
7.53 KB, patch
blizzard
: review+
blizzard
: superreview+
Details | Diff | Splinter Review
Ok, i havn't slept tonight so i might see a vision. When looking at comment 285 bug 68136 there grey box with a native scrollbar in it. This is on a Win98SE build from maybe a week ago I have no idea where this bug belongs, but i figured at least someone on layout can see what code creates the frame/does the painting...
wfm with a current CVS build ? Do you have a screenshot ?
Target Milestone: --- → Future
I see it too with 2002022003 on w98. Screenshot coming...
Attached image screenshot of problem —
yes, that is exactly what i got here too (still rebuilding a clobber here, so i couldn't make a screenshot)
I see the gray scrollable box also. I'm using Win95 with the 0.9.8 release (2002020406).
Changing QA contact
QA Contact: petersen → amar
I think it appears on many (most? all?) bugzilla pages, but it's only visible on once that are really long. Another example is http://bugzilla.mozilla.org/show_bug.cgi?id=40867#c277 But i have seen the familiar "jumping scrollbar" even when loading shorter bugzilla pages where i couldn't see the box so i think that it's there, it's just that i couldn't scroll down to it
QA Contact: amar → petersen
Priority: -- → P3
The scrollbox is a mirror of the CC listbox, over to formcontrols.
Assignee: attinasi → rods
Component: Layout → HTML Form Controls
QA Contact: petersen → madhur
Attached file minimum testcase (obsolete) —
Scroll down to the bottom of the testcase and scroll slowly up, you should run in to the scrollbox pretty fast. The scrollbox is a mirror of the listbox at the top of the page. It has the same size and shape as the listbox, and if you scroll one the other scrolls too. This seems to appear on all bugzilla pages, but can be quite hard to spot since most pages are too short to show the mirror
Attachment #71105 - Attachment is obsolete: true
Seeing this on Linux too. the testcase shows that this happens as soon as the page is a bit over 65500 pixels tall. Seems a lot like bug 115526 to me.
OS: Windows 98 → All
Hardware: PC → All
*** Bug 132744 has been marked as a duplicate of this bug. ***
QA Contact: madhur → tpreston
*** Bug 160948 has been marked as a duplicate of this bug. ***
*** Bug 159019 has been marked as a duplicate of this bug. ***
Another good test case: Load <http://www.xopus.org/index.jsp?menu=mozce> Control- (command-) click the link "plans to incorporate" in the second paragraph to open it in a new tab. Go to that tab, and you'll see the gray box of doom (on Mac, at least).
I have just filed bug 164625 which addresses a similar, but I think different, problem. I think bug 164625 is caused by 16-bit overflow in the native regions used by nsViewManager. That happens with pages a little of 2K pixels high, because the view manager is working in twips space (16 twips or so per pixel). That bug is fairly easy to fix by switching to our nsRegion region implementation inside the view manager. This bug is presumably caused by 16-bit pixel coordinates in GTK itself. This is much harder to fix (*cough* need XBL Form Controls *cough*).
Also if I understand Windows correctly, this bug should NOT happen in any NT-based system (NT4, 2000, XP), because NT's GDI and USER use 32-bit coordinates.
Also, blizzard says GTK2 uses 32bit coordinates, so we shouldn't see this there either.
Dup of bug 51385.
Depends on: 51385
*** Bug 132448 has been marked as a duplicate of this bug. ***
Changing summary to reflect the real problem. I think this could actually be solved by adding a set of checks which would hide native widgets for views which have been completely scrolled out of sight. Thus even when the 16-bit coordinates for those widgets wrap, they wouldn't interfere with the display. I'll take this bug.
Assignee: rods → roc+moz
Summary: strange scrollable box on bugzilla page → native widgets limited to 16-bit coordinates cause errors on long pages
actually, bug 132448 was not repeating at 2^16 pixels, but ~3200. However, bug 159556 (misduped against bug 132448 by my evil twin) is a dupe here. isn't this GFX Compositor?
*** Bug 51385 has been marked as a duplicate of this bug. ***
You're right about the duplicates, but I don't really care, the important thing is that this bug is the remaining issue. I'll call this a views bug.
Status: NEW → ASSIGNED
Component: HTML Form Controls → Views
Attached patch Fix for GTK (obsolete) — — Splinter Review
Here's my fix. I decided we should do it platform by platform because that's where the problem lies; some platforms don't need this at all. My fix for GTK basically hides any widget that gets moved or scrolled out of its parent's bounds. It works. This fix should be ported to Mac and Windows, at least.
Hmm, this patch appears to cause popups to fail sometimes. But not always repeatably.
This fixes a bug I had with top-level windows not being shown properly. We should always show top-level windows without any special handling because they're not contained by their parents.
Attachment #98682 - Attachment is obsolete: true
*** Bug 172766 has been marked as a duplicate of this bug. ***
Comment on attachment 100065 [details] [diff] [review] better fix for GTK r=blizzard
Attachment #100065 - Flags: review+
Comment on attachment 100065 [details] [diff] [review] better fix for GTK Hey blizzard, you already reviewed this patch, care to add your sr stamp too? Ta.
Attachment #100065 - Flags: superreview?(blizzard)
Comment on attachment 100065 [details] [diff] [review] better fix for GTK sr=blizzard
Attachment #100065 - Flags: superreview?(blizzard) → superreview+
WFM in 1/08/03 Trunk, Win XP and 1/07/03 Trunk Mac OSX.
Keywords: testcase
bug still exists with linux trunk 20030109 roc: is this patch now ready to get checked in?
Yes it is. I'll check it in.
Priority: P2 → P1
I've checked in the fix for GTK1. I'm not sure what the status is for other platforms. I would expect this to work on NT and the Mac (and according to Blizzard, GTK2). It probably doesn't work on Win9x but do we care? If not, I'll close the bug.
Bug still shows on Mac OS X (macho). taking for Mac fix.
Assignee: roc+moz → sfraser
Status: ASSIGNED → NEW
This bug still occurs on Win98 which i think is a farily well-used platform still.
"It probably doesn't work on Win9x but do we care?"
Gtk2 should be 32bit clean.
FYI, Win98 still has more users than any other version
Someone could port the technique I used here to Win9x. Not me, since I don't have a Windows development environment anymore. Plus it would have to be tested on Win9x, obviously.
(In reply to comment #37) > I've checked in the fix for GTK1. I'm not sure what the status is for other > platforms. I would expect this to work on NT and the Mac (and according to > Blizzard, GTK2). It probably doesn't work on Win9x but do we care? If not, I'll > close the bug. > > Roc, this bug was only kept open to port your previous patch to Win98, but on the trunk now we've dropped support for that OS. So can we close this bug as FIXED?
ok
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: