In a navigator window, go to the above url: (bugzilla's query page)
Choose View Source from the menu (or command-u)
Notice that the bottom arrow of the scrollbar seems to be under the growbox.
Also notice that I don't have a horizontal scrollbar even though the text scrolls
off the right edge of the window.
On Linux, I see both scrollbars and the resize corner is not obscureed (not that
it would be on Linux tho).

Hrm, no.
What's odd here is that sometimes the bottom scrollbar shows up, and sometimes
not. It seems to depend on what the source is like (though, in both cases, the
source can be wide enough that there ought to be a scrollbar).

I think that this has been fixed for a while. I can certainly see the bottom
vertical scroll arrow and the entire horizontal scrollbar in the 'Source' window
listing for the Bugzilla Query page URL.
I'm using the 2001-07-12-08 build on Mac OS 9.1 and the 2001-07-24-08 build on
Mac OS 8.6.

I have confirmed this bug using both the Modern theme and the 'Little Mozilla
1.1' theme. See attachment id=95684 which shows the lack of this arrow.
Mac OS 9.2.2 English-North American
Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1) Gecko/20020814
Build ID 2002081422
Why no patch after nearly 5 months? Isn't the idea to be *better* than MS IE ?

I downloaded and installed Build ID: 2002082808 only to find that the scroll
arrows no longer initiate scrolling in either direction. They do highlight when
selected; but, no scrolling takes place. The ability to intiate scrolling via
moving the cursor in or around the highlighted control is also no longer
present. What changed?

This bug is still alive, after two years!?
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826
Steps to Reproduce:
1. Open the Help window
2. Select a topic with a lot of content (Browsing the web)
3. Look at the lower right corner of the window, there is no down arrow !

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b)
Gecko/20021016 MultiZilla/v1.1.21
This bug is also seen in some cases where a new browser window is opened through
a javascript. Go to :
http://www.wired.com/news/mac/0,2125,55395-2,00.html
and click on one of the thumbnails.
Also, if you go to Menu: View -> Show/Hide -> Status Bar and toggle this off for
a normal browser window (like the one you are watching now), the bottom arrow
disappears below the window growbox. Thus, this bug seems to be dependent on
whether a status bar is displayed or not.

This bug keeps annoying me, and it is REALLY annoying.
When clicking the 'toggle toolbar' button in the right corner of the OS X title
bar, wich i do often to make more room available, the down-arrow of the vertical
scrollbar disappears behind the resize-thing...
I have a (very simple) workaround in mind, wich would make life much easier for
me: do not make the status bar disappear when clicking on the 'toggle toolbar'
button. I've already disallowed scripts to remove the status bar, so i the bug
really only bugs me when using the toggle toolbar button.
Personally i think this would be ideal for OS X users. (At least as an option...
I don't mind losing 18 pixels of space, now i'm not using the toggle function
i'm 'losing' far more...)

Yes, it is highly annoying and bothersome to deal with "evangelical" comments --
strong words actually have effects, you know, and sometimes they actually
motivate people. We must have None Of That! And for dealing with a bug that has
been opened for two years, why nothing is more appropriate than steadfast
silence! After all, it's a commonly-known truth in the open source world that
everyone can code just as well as everyone else! Why don't I just submit the fix
myself instead of being a bug senteniel and beta-testing the product? I should
immediately forgo all of those activities (and my own Moz evangelism, too,
because evangelism is a big no-no apparently) and just vote or code. But on the
serious side of the fence, it is absolutely preposterous to expect bugs with
long histories to NOT have their occasional posts by frustrated users.

Thanks for the help, Tarage,
Well, I WOULD certainly contribute a fix for this bug, if i had te required
programming knowledge. I am not (yet!) a programmer, so i am relying 0n the
great work of the Moz engineers. (Moz is a great job after all!) It just annoys
me that the app is unpolished in some ways. This bug is easy to workaround (i
cannot imagine that it is hard for a programmer to implement a 'NEVER hide the
status bar' option) but there is NOt A SINGLE ONE of the great developers fixing
it or making a workaround, or even watching this tread. That annoys me...
No offence to anyone... I just want a 'Never hide the status bar' option so this
bug wioll never bug me again...

Comment on attachment 170944[details][diff][review]
patch
This won't work, since it resizes any scrollbar, whether or not it actually
hides behind the grow box. I'll attach a patch that shows the issue.
What's really needed is to see if the scroll bar actually overlaps the grow
box, and only then resize it.

In this testcase, the scrollbar in the middle of the page should span the full
document (should go off the page on the right). And the bottom scrollbar
should look correct and have the right arrow button visible, when the status
bar is both visible and hidden (View->Status Bar).

As for fixing other themes, this is what roc suggested on IRC:
roc: add an API to nsIWidget that nsGfxScrollFrameInner can call
to see if it needs to reserve space, and if so, how much?
or just to check if it needs to at all.
roc: this API would return true if the widget has a native resizer
then nsXULScrollFrame would have to reserve space as if there
are two scrollbars.
I guess this doesn't matter for nsHTMLScrollFrame since we
currently don't allow windows to be just HTML.

(In reply to comment #79)
> *** Bug 358328 has been marked as a duplicate of this bug. ***
>
I'm running Mac OS X. 10.3.9 with Firefox 2.0.0.3 and this bug just popped up a few weeks ago. Is that any clue?

With the new scrollbar implementation, would it be possible to fix this by changing the way the painting and hit-detection is mapped to and from HITheme, so that it's shorter from HITheme's perspective without Gecko having to know about it?

YES this bug is alive and well under OSX 10.4.10, Firefox 2.0.0.6 AND Minefield 3.0a8pre. (iBook G4) A real fix would be much appreciated by THIS user.
Recap: ONLY the 'UP' scroll arrow is visible/useable at the screen/page lower right in many/majority of web pages. (But recalling comment above, SOME pages work properly.)
If I can understand how to u/l a small screen shot (titled no_down.png) it will show this defect appearing on THIS page. Also www.nytimes.com, etc etc.
Turning on Status Bar (View Menu) or opening a Find window cause the paired UP/DOWN scroll arrows to appear and operate properly.

I thank Mr. Morgan for his 'avviso' but would point out that I have long scratched my head at this particular Firefox defect. AND gnashed my teeth. Not a pro visitor to Bugzilla, I did what I hoped was 'due diligence' (which consumed a not small amount of my time and patience) in the FAQs, lists, and so on, before adding my notes above. I think that not inappropriate, but would add my sincere wish that the extra email or two to those following this will NOT be read as 'hurry-up' flags, so much as 'hey, it IS still a bit of craziness' out here.
Mozilla so far as I know gets around this problem...
I note that the first FAQ in the Gran Paradiso development page says
# What can I do to help?
We need help from developers and the testing community to provide as much feedback as possible to make Firefox even better.
Ecco, ci qua... da Torino

Worth noting some users, like me, prefer to have the statusbar turned off (looks more mac-like, plus with fission extension the progress bar is placed with the address bar so no need for statusbar)
Instead of hide statusbar, any way to make the statusbar only take up the space underneath the scrollbar arrows? Thus pushing down arrow back up into view again

Mac OS 10.5.2 Firefox 3.0b5. This has been going on for a long time in Firefox 2 as well as various beta releases. The down scroll arrow is missing or in the same place as the expand square. It happens on all original screens using Firefox. The down scroll arrow usually works correctly on linked pages.
It happens whether the up arrow is at the top or the bottom of the scroll bar. Past time to solve problem.

(In reply to comment #91)
> That, I think, is the plan.
Colin, when you said the above, did "that" refer to the immediately preceding comment (comment 90), or to Stuart's comment 84, or to something else entirely?
What *is* the current plan for this, in other words? I'm assuming the stuff from 2005 and earlier isn't still relevant now.

On my 17" screen, MAC 10.5, the down arrow and the resize widget are
separate and the horizontal scroll bar appears when the vertical area
is full or less and the horizontal area is about 3/4 of the available
space or less. The Status Bar is unchecked. The problem seems to occur on a fuller horizontal screen and when an original page like this one is opened.
Or, as you expand with the resize widget one or both problems appear.
It usually, although occasionally, doesn't happen on linked pages.

It appears the vertical down arrow has been solved by the latest revision of Firefox 3.0.1. The horizontal scroll bar still disappears when more than about 3/4 of the screen is used including this page.

(In reply to comment #111)
> Roc, where should I look if I want to fix it for trees, too? I haven't been
> able to find the right place yet.
Heh, I wasn't CCed on the bug :-)
Trees are in layout/xul/base/src/tree/src.

Hmm.
This approach is a bit strange. So if the viewport has no scrollbar (say the HTML document is overflow:hidden), but you position an overflow:scroll child element so that it has a vertical scrollbar whose down-arrow happens to be at the bottom-right of the window, then we'll tweak its scrollbar to be shorter.
But, if you put the element somewhere away from the window edge, then scroll the overflow:hidden window (e.g. by setting scrollTop/scrollLeft from JS) so that the vertical scrollbar down-arrow is at the bottom-right corner of the window, there's no reflow so the scrollbar will appear under the resizer. So we'd need to do something on scrolling to fix up any scrollbar ends that appeared under the resizer. Which seems weird.
It's also weird that if a vertical scrollbar overlaps the resizer horizontally, then we'll shorten it, but if it misses the resizer horizontally then it will suddenly snap out to its full height (possibly outside the window).
Yet it seems that this behaviour is exactly what Safari does...

(In reply to comment #115)
> Trees are in layout/xul/base/src/tree/src.
Yeah, but where does the scrollbar layout happen? In nsTreeBodyFrame.cpp the scrollbar's attributes (curpos, maxpos, increment, pageincrement) are updated, but I can't see the scrollbar rects anywhere.
(In reply to comment #118)
> Maybe the issue of scrolling causing an element's scrollbar to fall under the
> resizer is not worth worrying about
That's what I thought. When scrolling causes an element's scrollbar to fall under the resizer, there's usually another scrollbar covering that scrollbar.

+NS_IMETHODIMP nsChildView::AdjustScrollbar(nsRect &aScrollbarRect, PRBool aVertical)
Make this nsIntRect. I'd also prefer to make it a pointer to a rect to make it clear that it's in/out.
+ float overlapWidth = corner.x - (bounds.width - resizeIndicatorSize.width);
+ float overlapHeight = [topLevelView isFlipped] ?
+ corner.y - (bounds.height - resizeIndicatorSize.height) :
+ resizeIndicatorSize.height - corner.y;
+
+ if (overlapWidth > 0.0f && overlapHeight > 0.0f) {
I think it would be more clear if we just computed the intersection of the resizer rect with the scrollbar rect and tested whether they intersect. That would also handle potential bidi situations where the scrollbar is on the left.
+ if ((aVertical && !aRect.width) || (!aVertical && !aRect.height))
if ((aVertical ? aRect.width : aRect.height) == 0)
The rounding issues here are nasty. I think it might make more sense for nsIWidget to return a pixel-rect containing the resizer area, then we can convert that to appunits and adjust the scrollbar rect in AdjustScrollbarRect.

(In reply to comment #119)
> (In reply to comment #115)
> > Trees are in layout/xul/base/src/tree/src.
>
> Yeah, but where does the scrollbar layout happen? In nsTreeBodyFrame.cpp the
> scrollbar's attributes (curpos, maxpos, increment, pageincrement) are updated,
> but I can't see the scrollbar rects anywhere.
Hmm. I think maybe there's an XBL binding for <tree> that creates a standalone XUL scrollbar which uses nsIScrollbarMediator to manage scrolling for the tree? That sounds even harder. I'd tackle that separately, if at all.

Curious, to me this does not happen under Thunderbird.
With the page recized to the bottom of the screen the vertical down arrow is separate from the recizer on Mac Leopard as it should be.
When the recizer is about 1/2 across the screen the horizontal scroll bar is there. As the recizer is pulled to the right the grey bar gets longer until it reaches the right end of the space available. Then as the resizer is moved further right the horizontal scroll bar and scroll arrow disappears.

Comment on attachment 332744[details][diff][review]
fix v2.0
The logic in AdjustScrollbarRect can only deal with resizers in the bottom right corner but I think that's enough until we discover an OS that puts it somewhere else.

I don't know - roc, can it be tested? Maybe with a mochitest that opens a new dialog, puts an overflow:auto box in the corner, synthesizes a mouseclick on the corner and checks if the box has been scrolled?

Just make sure the test still works even if the test machine has non-default settings for where the scroll arrows go.
Another option is to use canvas.drawWindow in mochitest to do a "manual" reftest of the appearance of a window with resizer.

See attachment 361209[details]. This issue is not resolved in FF 3.0.6 (and remained a problem all through 2.X). System is OS X 10.4, problem occurs regardless of whether or not scroll buttons are grouped in System Preferences -> Appearance. Should be a simple fix by drawing on the same code that positions both scrollbars under X && Y overflow to position scrollbars under X only, or Y only overflow.