Closed Bug 1177 Opened 26 years ago Closed 25 years ago

Problems laying out long documents

Categories

(Core Graveyard :: GFX, defect, P2)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
Windows 95
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: kmcclusk)

References

(
URL
)

Details

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.)
‰
Status: NEW → ASSIGNED
Summary: Problems laying out long documents with anchor in link → Problems laying out long documents
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.
Assignee: kipp → michaelp
Status: ASSIGNED → NEW
Component: Layout → Compositor
Michael and I determined this is okay on NT, but miserable on Win95. Assigning
to Michael
QA Contact: 4110
assigning Chris Dreckman as QA
Target Milestone: M3 → M4
*** 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. ***
Assignee: michaelp → beard
Target Milestone: M4 → M5
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.
Status: NEW → ASSIGNED
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.
Target Milestone: M5 → M6
-> 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.
Assignee: beard → kmcclusk
Status: ASSIGNED → NEW
I've fixed this on the Mac, but I don't know how to fix it on Win95. WinNT
doesn't exhibit the problem.
Status: NEW → ASSIGNED
Target Milestone: M6 → M7
QA Contact: 4110 → 4144
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Fixed in the June 09 Build.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.