Closed Bug 126592 Opened 20 years ago Closed 15 years ago

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

Categories

(Core :: Web Painting, defect, P1)

defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: sicking, Assigned: sfraser_bugs)

References

()

Details

(Keywords: testcase)

Attachments

(3 files, 3 obsolete files)

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: 15 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.