Closed Bug 188564 Opened 22 years ago Closed 20 years ago

Native widgets limited to 16bit coordinates

Categories

(Core :: Web Painting, defect)

defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: earthsound, Assigned: roc)

References

()

Details

(Keywords: testcase)

Attachments

(12 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212 Note: This (the left frame of the URL above) is an *extremely* long page (10181 lines, iirc). When moving down that frame either by using the mouse and scrolling down, or by using the keyboard (down arrow key, Page Down or Ctrl+End) the rendering stops not even halfway down the page. Notice that the links are still picked up by the mouse, but for some reason Mozilla refuses to render the code correctly. Instead, it just smears the last part of the window as you keep moving down the page. I.e., the rendering screwup changes depending on whether you're paging down or using the mouse. Once you get to the part of the page that Mozilla doesn't render, you can move other windows over it and see a trail effect remaining on the bad part of the page Mozilla isn't rendering correctly. If I scroll down to the "bad" part of the page, switch to another tab, and then switch back to the tab with the bad page, it'll have the rendering of the former tab on the frame that is not rendered. Beginning with the newsgroup jp.dev.component, the browser will not display anything else down the page. In composer, when trying to edit the frame, it won't render anything past internetexplorer.win95 Because of this, it is nearly impossible to navigate their groups (and please, no flames about trying to participate in a M$ newsgroup :P) Reproducible: Always Steps to Reproduce: 1. load http://communities.microsoft.com/newsgroups/default.asp?icp=mscom&slcid=US 2. in the left frame, the list of newsgroups, after it finishes loading (warning! it will take some time to do so), scroll down the page either w/ your mouse or keyboard Actual Results: the rendering of the page will eventually get screwed up, although using the mouse over the badly rendered areas of the page will show the correct links...just nothing visually. Expected Results: Correct rendering of page. It works fine in IE6, I don't have another browser on this box to test I'm on Windows XP, SP1, on a Dell OPTIPLEX GX50, with a 17" 1702FP Dell Flat Panel monitor, 1200MHz Celeron & 256 MB of RAM. All drivers are currently up-to-date, afaik.
Note that the mouse is hovering over the badly rendered part of the frame, but the correct URL is shown in the status bar. :\
Here, I switched to the tab containing the bugzilla page and then switched to the tab containing the badly rendered frame. Notice the imagery is from the previous tab. :\
WARNING!! It's 10181 lines long...
I saved the frame locally and then edited it with composer. Notice that it begins the bad rendering in a different location (in the Normal tab) than the browser does. Also notice the size of the blinking cursor next to the mouse. That cursor grows in size the further down the badly rendered part of the page you click with the mouse (note where in the screenshot the mouse had been clicked).
This was taken in composer, in the "HTML Tags" tab. Note that it begins the bad rendering in a different location than the browser or composer's "Normal" tab. Also, notice the enormous size of the blinking cursor due to clicking in the page where the mouse is in the screenshot.
Notice that the frame is scrolled all the way to the bottom. (this screenshot has been modified to fit the views of screen captor, and may not necessarily reflect the actual wording found on the referenced URL)
happens on linux too; looks like coordinate space overflow...
Assignee: asa → roc+moz
Component: Browser-General → Views
OS: Windows XP → All
QA Contact: asa → ian
Hardware: PC → All
I don't understand why you're seeing this bug in NT. NT widgets have 32-bit coordinates. But it's pretty clear that the body (40K pixels) is overflowing the 16-bit GTK coordinates and there's not much we can do about that.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 Robert: I'm not sure what you're referring to wrt the "40K pixels" but not only does XP have this bug, but moz1.2.1 in 98 does, too. And, as you can see w/ the screenshot, it's worse. :\ In XP, you can scroll back to the top and see the first half of the frame, but in 1.2.1 in 98 you get crap...
see how the whole frame is messed up, as opposed to the latter half, as in the XP screenshots?
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021212 Notice that you can't even see the left frame before scrolling. :(
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021212 Notice, that like in XP, you can click on links in Windows 98, but you cannot see any of them, except as they appear in the status bar.
Hardware: All → HP
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021212 Screenshot of frame opened in New Window, notice that while loading it is properly viewable through jp.dotnet...
after approx. 95% loading, the view goes from decent (see attachment 112115 [details]) to completely fscked....
changing hardware to All, as I see this on Intel, as well, and this doesn't appear to be hardware-specific. Also, confirming as New, as seen in at least XP, 98 & Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: HP → All
seeing this is 1.3b
Changing summary to reflect real problem
Summary: scroll down the left frame, the listing of the newsgroups, and eventually the rendering gets messed up → Native widgets limited to 16bit coordinates
*** Bug 196014 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030902 Firebird/0.6.1+, Windows 2000 Pro seeing this in Firebird nightly
Isn't this a duplicate of bug 126592?
Attached file simplified test case
I have created a simplified test case by removing all unnecessary stuff (images, links, scripts, etc). Please note the fact that there is no corrupted rendering if any one of the following changes is made in the HTML source: 1) Remove a substantial number of table rows. 2) Remove the style attribute "overflow: auto;" in the BODY element. 3) Remove the style attribute "overflow: hidden" in the TD elements. BTW: I am using the following browser version. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-AT; rv:1.6) Gecko/20040113.
Attached file Testcase
Keywords: testcase
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 This now WFM (in Firefox). As I don't use Mozilla suite anymore, someone else should reopen this if they still hit this problem.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
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: