NGLayout has trouble laying out a long document when the link is to an anchor within the document -- it fails to produce a scrollbar and neither scrolls nor moves to the anchor once the page has loaded. This only happens with some anchors within the above URL. (And, believe it or not, this time that link isn't because of a failure to conform to the CSS specs.) ‰

This isn't just related to movement to anchors. There are problems scrolling in this document and I think also in WD-XSL (a similar document in the same directory). The problems result when I drag the scrollbar. There are certain points where the document gets "stuck" and dragging the scrollbar doesn't move it for a bit, and then it gets "unstuck" and jumps to where it should be. Removing "with anchor in link" from title.

This document is now no longer displaying at all, since it now uses (in the new version) a CSS stylesheet that displays an image in the upper left corner. I think NGLayout gets stuck before loading the image, and it never displays. The scrollbar is drawn, though.

This document is now displaying again. Without the #text-indent, there are 2 problems. The scrollbar does seem about the right length, but when I scroll about a sixth to a quarter of the way down, it stops showing anything new when I keep going down (by pages) for a while, and then a bit farther down it starts displaying the text on top of old text without erasing anything. I think this deserves P1, but since you only use P1 for crashes, leaving as is...

Setting all current Open Critical and Major to M3

The behavior on this document is very erratic. Once, it loaded without the stylesheet, and the scrolling problems were massive. Twice, it didn't display anything more than a scrollbar (about the right length). Once, it displayed, with the stylesheet, right as I exited the browser, so I didn't get to see it. I have to say that I find this to be one of the most disturbing bugs in the layout engine.

Michael and I determined this is okay on NT, but miserable on Win95. Assigning to Michael

assigning Chris Dreckman as QA

*** Bug 2260 has been marked as a duplicate of this bug. ***

*** Bug 3947 has been marked as a duplicate of this bug. ***

I saw this bug mentioned when I was looking at other bug reports for beppe@netscape.com. I have a bug that seems very close but causes a different end result. I did not want to creat a duplicate bug report if it was related. As the previous people stated you will not be brought to the target. BUT in my case I can crash Apprunner (every time). http://users.ipa.net/~asj/computer.htm#M I copy and past this into the location line of Mozilla (4/2/99). Currently mozilla does not go to my "M" section. If I next click on the location line and press enter APPRUNNER crashes (every time). APPRUNNER caused an invalid page fault in module RAPTORHTML.DLL at 014f:0178ca36. Registers: EAX=00000000 CS=014f EIP=0178ca36 EFLGS=00010246 EBX=00000000 SS=0157 ESP=0076ee7c EBP=0076ee9c ECX=0076eea8 DS=0157 ESI=80000000 FS=4b67 EDX=00000003 ES=0157 EDI=04a8f470 GS=0000 Bytes at CS:EIP: 8b 18 e8 aa fe fe ff 50 68 60 4a 81 01 ff 75 ec Stack dump: 04aa3ad0 01814b50 00000000 00000000 0076eea4 04b38550 00000000 00000000 0076ef18 015b66d6 00000000 0076ee98 04a7ae78 04a7adf0 00000000 0044e920

I don't think the above comment is related. I filed it separately as bug 4580.

*** Bug 1815 has been marked as a duplicate of this bug. ***

patrick, the issure here (as far as i can tell) is that in these situations, the values being passed into the scrollbars for container size, etc. are simply too large for the native code to handle. there are two things that can be done: 1) get an xp scrollbar implementation. 2) make the scrollingview code send everything to the scrollbar in terms fo pixels rather than twips. this should give us about 15 times more coordinate space on most systems (i think). talk to me and i can point you in the right direction for #2.

Using a build from 4/12/99, I get very erratic behavior under viewer, extremely long pauses somewhere deep in StyleSetImpl::ResolveStyleFor(). However, the original behavior of scrolling to the anchor does work. This page is evidently a good general test case.

The scrolling to the anchor does work. However, the problem is in display, and is specific to Windows 95 (the problem does not occur on NT). Once it is at the anchor, hit PgUp. You should then see the text from the page up overwrite the old text, without erasing it with a background.

I can confirm this observation on the Mac, I've seen overlapping drawing, seems like a coordinate system overflow problem. I don't see a problem on Windows NT.

-> M6

Here's what's causing the overlapped drawing on Mac OS: When the document is scrolled to the #text-indent anchor, (0, 0) gets transformed to (0, -38112), which exceeds Quickdraw's representable coordinates. When a Rect is created from these coordinates, it is typically seen as empty, and Quickdraw stops painting the background color properly, hence overlapped drawing. There are several solutions to this problem, both cross platform, and platform specific: 1. pre-clip coordinates so they are always within the viewable area of the window. this may be hard to do in all cases, but it would guarantee fast drawing. 2. bullet-proof all of the OS specific calls with OS-specific knowledge of the coordinate system limitations. Option 2 is probably the only practical solution right now, but we will have to hunt all of the cases down. I have a fix for the Mac OS rendering context.

I'm not sure it is the entire problem. If you display that document on Windows, the page pointed to by the anchor is indeed displayed correctly while on Mac it's not, but if you scroll through the entire document, you will notice some areas where the text is overlayed over and over. It's the same bug as the one described in #2564.

I've fixed this on the Mac, but I don't know how to fix it on Win95. WinNT doesn't exhibit the problem.

Fixed in 5-3-99 1:22PM build Added a new method, ConditionRect which is used to fix coordinate overflow problems under WIN95. Condition rect converts nsRect to a RECT with cooordinates modified to acceptable ranges for WIN95. Modified nsRenderingContext::SetClipRect and nsRenderingContext::FillRect to make calls to ConditionRect before calling the native windows routines. This fixes long document loading under WIN95.

Fixed in the June 09 Build.