100574 - Bottom end of page is not displayed or disappears when scrolling

Status: RESOLVED DUPLICATE of bug 75214

(Core :: Layout, defect, P3)

Description

[Sebastian Leske]

The last few entries / articles on the above page are just cut off and
not displayed.

Look at the URL above. It is a very long page with frames. Scroll to the
very bottom, and you will usually see a lot of empty space at the end,
and before it an article which has obviously been cut off midway.

Often scrolling forwards and backwards makes more text disappear of reappear,
sometimes marking & unmarking the text also does that. If you cannot see
the problem the first time, just scroll violently up and down near the end
of the visible content a few times, and you'll see it.

Note: This also happens on some of the article pages, but not on all.
It seems the pages need to be very long for this to happen.

Note2: How much text appears / disappears during scrolling seems to 
depend on scrolling speed. Scroll quickly / slowly to see it.

Comment 1

[Sebastian Leske]

Attachment: screenshot of page with end not shown

Comment 2

[Sebastian Leske]

Attachment: snapshot of rendering mistake after marking some text & moving mouse

Comment 3

[Sebastian Leske]

Attachment: the page displayed correctly

Comment 4

[Sebastian Leske]

Created three attachment to illustrate the problem.
All three show the same page ( http://sueddeutsche.de/ of 2001/09/19).
No.1 shows the end of the page being cut off.
No.2 shows how parts of the text are not rendered after marking some text,
unmarking it again and moving the mouse.
No.3 shows what the page should look like. After some scrolling forward
and backward, I got it to display completely (weird, isn't it?).

It seems scrolling slowly causes parts of the page to be cut off, but
jumping fw / bw may make it display again.

Comment 5

[Marc Boullet]

WFM 0.9.4 NT4

Comment 6

[Marc Attinasi]

Yea, works fine for me in Win2K using CVS branch build. Is this Linux only? Can
anyone else confirm on Linux?

Comment 7

[R.K.Aa.]

I never saw this bug on linux myself, currently using a fresh CVS build.
However: The bug is repeatedly filed: Bug 97430 and bug 96614 seems to be about
the same thing.

In yet abother bug 90341 about same site, a "hang" problem is located to origin
from a too tall IFRAME, and marked dup of bug 91747.

Comment 8

[Chris Petersen]

I'm able to reproduce on Mac OS X build (2001-09-19-05) but not on the Windows
build. Will chceck on Linux too.

Comment 9

[Chris Petersen]

Simular paint issues occur when scrolling page under the Linux Sept 20th build.

Comment 10

[Chris Petersen]

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

Comment 11

[Marc Attinasi]

This page is made up of a series of IFRAMES - I do not see the screen
corruption, but when scrolling it looks absolutely AWFUL until about a second
after the scrolling ends, then it is OK.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: Source for iframe

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase. Problem is an absolutely positioned scrolling=no iframe

Comment 14

[Marc Attinasi]

Thanks Boris!  So it looks like the block that contains the abspos IFRAME is not
being sized correctly.  Moving off since it is not too severe, but it does
represent a kind of data loss I think (since the contents of that IFRAME cannot
be seen. Fortunately you can always 'open frame in new window' to see it, if you
can figure it out!).

Comment 15

[Wolfgang Kronberg]

'open frame in a new window' works for Boris' testcase. It does not work,
however, for www.sueddeutsche.de itself (the whole page is being displayed
(incompletely) again, mozilla 0.9.7, Win98). I don't know whether this is
another mozilla bug or some intentional 'magic' from the really strange
sueddeutsche.de site, but it seems to increase severity a bit.

Comment 16

[Sebastian Leske]

> 'open frame in a new window' works for Boris' testcase. It does not work,
> however, for www.sueddeutsche.de itself (the whole page is being displayed
> (incompletely) again, mozilla 0.9.7, Win98). 

Yes, www.sueddeutsche.de seems to use javascript to redirect you to the whole
frameset if you open an individual frame. If you disable javascript, you can
open just one frame, which is then displayed correctly. So yes, in principle the
workaround works for www.sueddeutsche.de as well.
A weird page, really...

Comment 17

[karnaze (gone)]

->jkeiser, m1.1

Comment 18

[Wolfgang Kronberg]

Since the affected URL http://www.sueddeutsche.de is one of the major German
sites, I'd suggest adding the top100 keyword, just as it has been done in bug
91747. Could someone with sufficient privileges please do that?

For the same reason, I am somewhat unhappy with the target milestone 1.1. Due to
the importance of the affected site, I think that 1.0 would be more appropriate.
I guess that the press - including Sueddeutsche Zeitung - will look much more at
1.0 than at 1.1.

Comment 19

[Jens Glaser]

Hi

let me also kindly underline the impact this bug has on the usability
of the browser with certain internet sites. Since the site in the URL -
sueddeutsche.de - is without doubt a very popular site (visit google and enter
the term "Zeitung" =  newspaper), it is assumed that mozilla should be capable
of displaying its page contents.

While navigation through the site is possible,
currently, mozilla "swallows" around 30-50% of the articles´ text,
depending on their length.

Please reconsider improving this unfortunate situation with regard to the
number of users for which it represents a handicap.

Comment 20

[Arthur]

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

Comment 21

[Boris 'pi' Piwinger]

As Boris' testcase shows (also a study of the problematic site), Mozilla
displays exactly what is intended. The iframe has a fixed sized and should not
be scrolled. I cannot see a bug here. Do I miss something?

I'd suggest to tell them to fix their site.

pi

Comment 22

[Wolfgang Kronberg]

Attachment: Boris' testcase with double height

Comment 23

[Wolfgang Kronberg]

Boris 'pi': I think you indeed miss something. Boris' testcase does not tell the
truth on some test systems: since the 2000px height can still be displayed
correctly on some machines (including mine), you might be tempted to say, "well,
obviously the given height just isn't enough to squeeze all that text in".

But this isn't the problem: the guys at sueddeutsche.de actually didn't
miscalculate. I created a new attachment which is just the one from Boris, but
this time with the height as being used by sueddeutsche.de (4000px). If you see
the problem on sueddeutsche.de (video driver dependent, I guess), you will now
probably also see the real problem in the testsuite: the text just ends in the
middle of the designated area, the rest is empty.

This is the data loss problem as pointed out in comment #14 by Marc, and it is
definitely a bug in Mozilla. In addition, I repeat what I wrote in comment #18:
this should get the "top100" keyword, and fixing it no earlier than in 1.1 will
make Mozilla look bad in German press.  :-(

Comment 24

[Wolfgang Kronberg]

Attachment: Boris' testcase with double height (corrected)

Sorry - I had a problem uploading the attachment. I hope it's correct this
time. Unfortunately, I'm not authorized to make obsolete my own buggy
attachment #79689 [details].

Comment 25

[Wolfgang Kronberg]

Attachment: Testcase from 04/17/02 in IE / small fonts (correct)

Comment 26

[Wolfgang Kronberg]

Attachment: Testcase from 04/17/02 in Mozilla (buggy)

Since some people did not see the real bug using the testsuite, there has been
some irritation. I created two new attachments, showing (a) the testsuite's
output on mozilla, and (b), for reference, its output on MS Internet Explorer.

I'd like to stress again that sueddeutsche.de is *not* faulty, but it is a bug
in mozilla, and quite an evil one (probably destoying output in other places as
well). I hereby ask the responsible people again to add the "top100" keyword
(it is really absolutely clear that it is appropriate here), and to seriously
consider moving the target to mozilla 1.0.

Comment 27

[Arthur]

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

Comment 28

[Arthur]

Adding top100 keyword as it's on one of the duplicates. Do we know what causes
this bug?

Comment 29

[Arthur]

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

Comment 30

[Robert Offinger]

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

Comment 31

[R.K.Aa.]

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

Comment 32

[Doron Rosenberg (IBM)]

is there anyone who is still seeing this with new builds??  I cannot reproduce
this.  

Comment 33

[Boris 'pi' Piwinger]

I still see the problem in "Boris' testcase with double height (corrected)"
using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020519.

pi

Comment 34

[Wolfgang Kronberg]

Doron: what are "new builds" for you? RC2 definitely still has this bug. I am
seeing it still on both Win98 and Linux, and many other people are, too (look at
all those recent dupes!).

Comment 35

[Doron Rosenberg (IBM)]

I don't see it with rc1 on the testcase.  Have you tried a new profile and
clearing mem/disk cache?

Comment 36

[Bob Clary [:bc] (inactive)]

I am not seeing the bug on bz's testcase with double height(corrected) in trunk
from 2002-05-18 or branch 2002-05-07 on win2k.

Comment 37

[Boris 'pi' Piwinger]

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

Comment 38

[Jens Glaser]

I am still seeing the problem on www.sueddeutsche.de (disappearing
text contained in white boxes at bottoom of page, try marking the
text for example with the mouse cursor)..
I am using mozilla1.0 RC 3 (2002052309).

Comment 39

[Boris Zbarsky [:bzbarsky]]

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

Comment 40

[Boris Zbarsky [:bzbarsky]]

This is likely a dup of bug 75214 or vice versa.

Comment 41

[Boris 'pi' Piwinger]

Looks very much the same for me as bug 75214, it also talks about the same page.
Duping and consequently removing dependency.

pi

*** This bug has been marked as a duplicate of 75214 ***