42974 - "Ultra narrow" horizontal & vertical scrollbars.

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[timeless]

2000061720
I'm not sure what triggered this, at first view source had scrollbars that just 
started drawing too low, and then I noticed they were being drawn to fit.

The bars do not match the correct widths [system 9 or moz 13?].

Comment 1

[timeless]

Attachment: short horizontal scrollbars.

Comment 2

[Peter Trudelle]

There are no steps to reproduce here, and I don't see anything like this using 
Win98.  Is it Win2000-specific, wfm, or invalid?

Comment 3

[timeless]

2000062108 win32 talkback
www.aol.fr (ah i love it when this page displays symptoms)
the right vertical scrollbar is micro.

Comment 4

[Joseph Elwell]

linux build 2000062108 - I see this too, ain't it weird? Mac cvs pull from the
20th - doesn't display that page at all. It looks like the server is sending "."
as the mimetype.

Comment 5

[timeless]

This is All/All and probably blocks bug 39797. qawanted to make a 
reduced testcase.

Comment 6

[John Morrison]

Okay, this boils down to a relatively simple condition (and only affects 
GFX scrollbars [mac/linux/win32]).

If the *entire* document is created from javascript, e.g.:

  document.open();
  document.write("all of the HTML content");
  document.close();

Then both the horizontal and vertical browser scrollbars will be positioned 
partially outside the window boundaries, resulting in only about 4px of usable
scrollbar that is visible in the browser.

I will attach the simple testcase.

Nominating nsbeta3 since this is core DOM functionality which needs to be 
fixed before RTM, but I don't believe that this is a widely used pattern 
(writing _entirely_ new documents out with document.open();document.write()).

However, someone may disagree with how common this is, or point out that this
affects AOL France, and might argue that this should have higher priority 
(e.g., nsbeta2).

Comment 7

[John Morrison]

Attachment: testcase; simple js-generated page; vertical/horizontal scrollbars are partially outside the window boundaries

Comment 8

[John Morrison]

Actually, I am guessing that it's the position, and not the width of the 
scrollbars that is wrong, but it could be that it is the width that is 
wrong. Either way ...

Comment 9

[David Krause]

I'm pretty sure that this bug is also causing the narrow scrollbars in
chatzilla.  If you turn off gfx scrollbars then the bug disappears in chatzilla.
Since chatzilla is basically all js and xul it is affected.

Nominating for nsbeta2.

Comment 10

[Jay Patel [:jay]]

Putting on [NEED INFO] radar. What other major sites show this behavior?  Can we 
get another reproducible testcase?

Comment 11

[John Morrison]

I'm not aware of another major site that currently displays this behaviour.
I also do not have another testcase that isn't a repeat of the same basic
'document.open;document.write(everything)' pattern.

(However, I note that there were reports of similarily narrow scrollbars
appearing on www.mozilla.org and www.adobe.com for about 3 weeks in April
(mac-only), but this stopped occurring at the beginning of May. (But this
may well have had a different underlying cause, since solved).)

Comment 12

[Robert Ginda]

These scrollbars look like they have no style, as opposed to incorrect
placement.  If you zoom up on them (say, with xmag on linux) you'll see that the
beveled border exists on all four edges.  If the scrollbars were being
misplaced, you'd expect the right/bottom borders to be clipped.

Comment 13

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 14

[John Morrison]

jst's 7/21 checkin fixed this problem for www.aol.fr and for the reduced 
testcase (mac/linux/win32). Anyone want to comment on how it works in chatzilla
now? [I expect this is FIXED].

Comment 15

[Robert Ginda]

looks fixed to me.

Comment 16

[David Krause]

marking fixed, chatzilla, www.aol.fr, and the testcase are fine now

Comment 17

[John Morrison]

thanks. verified fixed.

Comment 18

[Chris Nelson]

Reopening this bug. Reproducible (got confirmation in #mozillazine)

Using a 2000072808 build for Windows, follow these steps:

1) Load a page like www.icq.com or www.cnn.com (I think any page will do, but I 
was able to get the bug to occur on these pages).

2) Hit the stop button before the page loads. This is the tricky part. You need 
to let enough of the page load in that when you hit the stop button it will lay 
out and require a vertical scrollbar. But you don't want so much to come in that 
the scrollbar appears before you hit the stop button.

3) If for some reason you don't get a scrollbar after stopping the page load, 
try resizing the window smaller so that a scrollbar will appear.

4) The scrollbar will be as described in the original report for this bug.

Comment 19

[David Krause]

Sigh, I guess this was only a partial fix.  I can reproduce it on a linux cvs
tip build from an hour ago.  I can reproduce it on several different pages.
This may affect every page.

Comment 20

[David Krause]

This sucks.  I've reproduced this on many pages now including:

http://www.netscape.com/
http://www.microsoft.com/
http://www.cnn.com/

Hopefully this can be fixed before nsbeta2/m17 ships.

Comment 21

[John Morrison]

I'd really think that this bug should remain as FIXED (since the particular
condition noted here is fixed), and a new bug be opened for the new steps to
trigger the narrow scrollbars. [I've just spent the past few days looking at
bugs for nsbeta3 priorities, and bugs that drag on through several iterations
are a real pain to follow].

I've opened bug #46912 to track the recent comments. Thanks (but I've put it
to a future milestone -- not enough time left for everything to get done).

Comment 22

[John Morrison]

re-verified for the noted JS-generated pages at www.aol.fr