From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1a+) Gecko/20020622 BuildID: 2002062203 If an event occurs that would require the content area to expand to fill space formerly occupied by chrome of some kind, the needed expansion doesn't occur, and some blank, grey space is left behind. Reproducible: Always Steps to Reproduce: 1. Open a Navigator window, pointing to a URL (e.g., [http://www.mozilla.org/]) 2. Spawn a new tab 3. Switch back to the first tab, and scroll the content to the very bottom (such as by pressing the end key) 3. Dismiss the tab, leaving the original tab showing without a tab toolbar Actual Results: A grey space is displayed at the bottom of the content area, equal in height to the dismissed tab toolbar. Expected Results: The content area should have taken over the abandoned space. Care should be taken to ensure the space isn't just painted in the content's background color, but that the bottom of the content is actually moved to the bottom of the content pane.

Whoops, strike those steps. Use these instead. 1. Open a Navigator window, pointing to a URL (e.g., [http://www.mozilla.org/]) 2. Spawn a new tab 3. Switch back to the first tab, and scroll the content to the very bottom (such as by pressing the end key) 4. Switch back to the new tab and dismiss it, leaving the original tab showing without a tab toolbar

Confirmed on Mac OS X CFM 2002062903.

> 4. Switch back to the new tab and dismiss it, leaving the original tab showing > without a tab toolbar How are you dismissing it? Using the close button on the far right of the ``tab bar''? What are your tabbed browsing prefs set to? I can't seem to reproduce this on my Mac OS X build. Over to jag for a look since this is tabbed browsing/XUL related.

I'm dismissing it by clicking the close widget on the tab toolbar. My tabbed browsing preferences are set to hide the tab tab when only one tab is open.

Samir, have you had any luck reproducing this? If not let me know, and I'll try to come up with another reproduction regime.

This problem is still evident using FizzillaCFM/2002110808.

Has anyone been able to reproduce this, or is it headed for the big black hole of old Bugzilla bugs?

Couldn't reproduce using Win32/2002102704 (Classic and Modern). Can still reproduce using FizzillaMach/2002121607 (Classic and Modern).

Yes this is easy to reproduce. It only affects themes that use "Aqua" scrollbars, like Classic. Switch to the Classic theme, scroll to the bottom of a window, change the text zoom to 75% - result: gray at the bottom of the page. Or (still in Classic), compose a new mail message making the text long enough to cause the message to scroll. When at the very bottom of the message, delete a few lines. Instead of shifting the content down, you get gray at the bottem. Same effect in a composer window.

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

It seems like this bug ought to have a dependency relationship to bug 181293, one way or the other. What's up with that horrible medium gray? Another easy way to reproduce it is to press the silver jellybean (upper right corner of title bar) while scrolled to the bottom of a page.

The bug here is in the native scrollbar code, specifically nsNativeScrollbarFrame::AttributeChanged(). nsSliderFrame::AttributeChanged() (the XUL scrollbar) sets the curpos attribute on the scrollbar content when the max is set to a value smaller than the current value. nsNativeScrollbarFrame omits to do this, so we short-circuit some later code in nsGfxScrollFrameInner::AttributeChanged that scrolls the content back into the right place.

This patch copies a chunk of code from nsSliderFrame::AttributeChanged into nsNativeScrollbarFrame::AttributeChanged. I don't know whether we need the scroll mediator stuff, but we certainly need the setting of the curpos attribute.

Comment on attachment 115097 [details] [diff] [review] Possible fix in nsNativeScrollbarFrame r/sr=me

Taking

Checked in.