58539 - window.scrollbars.visible -> ns_error_failure 0x80004005

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Jesse Ruderman]

Trying to access window.scrollbars.visible gives a NS_ERROR_FAILURE.  It's 
supposed to return a boolean, although I'm not sure when it's true and when 
it's false.

Confusing 4.x documentation:
http://developer.netscape.com/docs/manuals/communicator/jsref/win1.htm#1187502

Comment 1

[Jesse Ruderman]

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

Comment 2

[Johnny Stenback (:jst)]

Dan, could you look into this, ScrollbarsPropImpl::SetVisible() and
::GetVisible() currently only return NS_ERROR_FAILURE, they need to access the
window flags passed to window.open() to determine if the window has scrollbars
enabled or not. Brendan, correct me if my understanding of scrillbars.visible is
incorrect.

Comment 3

[Dan M]

  Oops! Scrollbars were never hooked up to their windowprops, were they? At least 
n access attempt returns a nice error.
  To answer Jesse's question, once these are hooked up, the accessor will return 
FALSE if scrollbars are disabled, meaning the content area will never show 
scrollbars no matter what the content, and TRUE if they're enabled, meaning the 
content area may or may not actually be showing a scrollbar, depending on the 
size of its contents. I'm not quite sure if that's the exact behaviour of Nav 4 
and IE, but it's what we can do and it seems reasonable.

Comment 4

[Dan M]

After further investigation, it turns out that in Nav 4.74 (windows), 
scrollbars.visible is always true in a window with enabled scrollbars, even if 
they're not currently visible. (And IE (5) doesn't support the feature, so 
there's no help there.)

Comment 5

[Henrik Gemal]

testcase URL:
http://gemal.dk/browserspy/showprop.html?window.scrollbars

"uncaught exception" on build 20010130

Comment 6

[Jesse Ruderman]

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

Comment 7

[Dan M]

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

Comment 8

[Dan M]

I'm attaching a mostly straightforward implementation. The one tweaky thing is 
the modification to nsContentTreeOwner::GetInterface; asking it to go to the 
root nsContentTreeOwner when asked for nsIWebBrowserChrome, rather than 
volunteering itself. Makes sense, but wants extra review. The rest of the patch 
just rips out the unnecessary special-case code implementing the ability to open 
a window without scrollbars, and implements the general case.

Comment 9

[Dan M]

Attachment: scrollbar.visible implementation

Comment 10

[Dan M]

.

Comment 11

[Henrik Gemal]

I just have to reopen this one. I no longer get the "ns_error_failure" error but 
the results are a bit weird (I think).

The documentation says:
"The value of the scrollbars property itself has one property, visible. If true, 
both scrollbars are visible; if false, they are hidden."

But if you go to:
http://gemal.dk/browserspy/showprop.html?window.scrollbars
and the scrollbars doesn't show because the browser window is large enough to 
show the page content shouldn't the scrollbar.visible be false?

Currrently the visible seems to be true all the time. Is this another or is 
there something that I misunderstood?

Comment 12

[Dan M]

See my comments above, dated 2000-12-14 and 2000-12-19.

On the plus side, hyatt plans to check in a change to make scrollbars always 
visible, even if they're disabled, as IE does.