61826 - Double ended "smart" scrollbars on Mac OS require reload to become visible

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Andrew Thompson]

When I first start Moz. (December 2nd, source debug build) I can't see the smart
scolling arrows (2 arrows at the same end of a scrollbar) that Hyatt just
implemented.

When I press reload, they show up.

Looks like maybe a problem with the first "bindingattached" event?

Comment 1

[Adam]

This happens everytime a new window is open (either by command-cliking a link,
manually from the File menu, or at Mozilla startup). The next page you (re)load,
the arrows will appear correctly. This might also be the reason why the arrows
are wrong in the Page Source window. 2000120608 trunk.

Comment 2

[Andrew Thompson]

Fixinf summary

Comment 3

[hirata masakazu]

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

Comment 4

[Mike Pinkerton (not reading bugmail)]

bringing in the important people ;)

Comment 5

[hirata masakazu]

Since important people are here, I would like to point to another related bug
62466, where in 3pane window, the message pane scroll window is not following
the Appearance settings.

Comment 6

[Peter Trudelle]

->mstoltz, per hyatt - CAPS and security stuff is denying the scrollbar load,
for some reason.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

I'll update my Mac build and take a look.

Comment 8

[Mitchell Stoltz (not reading bugmail)]

How do I enable the smart scrollbars? I tried enabling them in the Mac's
Appearance control panel, but that doesn't seem to make them appear in Mozilla.
(I'm using a build from 3/5 or so)

Comment 9

[Mike Pinkerton (not reading bugmail)]

which skin are you using? and the bug is that you have to go to a webpage or two 
for them to show up in the content area.

when you say "they don't appear in mozilla" what do you see?

Comment 10

[Mitchell Stoltz (not reading bugmail)]

Setting milestone to Moz0.9.

Comment 11

[Mitchell Stoltz (not reading bugmail)]

Forget what I said, I can reproduce the bug in the Modern skin. Hyatt, what made
you think the problem is in caps? I don't see any 'access denied' exceptions go
by. Do you have a stack trace that passes through caps? I'm seeing the
"Scrollbars in this skin are not properly supporting mac smart-scrolling prefs!"
exception thrown by scrollbarBindings.xml. I will continue to delve, but let me
know why you fingered caps.

Comment 12

[David Hyatt]

I stepped far enough through to watch the load of the scrollbars be denied...
something odd about the page being about:blank still.

Comment 13

[Mitchell Stoltz (not reading bugmail)]

Denied by what? By nsScriptSecurityManager::CheckScriptAccess?

Comment 14

[Phil Schwartau]

Problem still occurring with nightly binary 2001051508 Mac OS9.

Steps to reproduce: 

1. Bring up Mozilla for the first time (blank page)
2. Load the URL for this bug
3. Reload the URL for this bug


On the first load, the scrollbar is not "smart"; the arrows are on opposite
ends. On the reload, it's smart: both arrows appear at the bottom.

Comment 15

[Marek Z. Jeziorek]

setting to 0.9.2 per PDT triage

Comment 16

[Mitchell Stoltz (not reading bugmail)]

milestone 0.9.4

Comment 17

[Brad Tiffany]

I think the mailnews messagepane scrollbar problems (bug 62466 and bug 74688)
are closely related to this one, for the following reasons:

First, enabling javascript for mailnews makes the message-pane scrollbar behave
as it should.  Second, disabling javascript for navigator makes the navigator
scrollbars _always_ behave badly (no smart scrolling and context menus when long
clicking on the thumb).

Third, if I put

user_pref("capability.policy.icky.sites", "http://www.mozilla.org");
user_pref("capability.policy.icky.javascript.enabled", false);

into user.js, I get scrollbars that are always badly behaved at www.mozilla.org,
but not at mozilla.org (or elsewhere).

It seems that the problem is that the scrollbar's permissions are those of the
scrolled content area (which, per Hyatt's comment, might be anomalous during the
first load into a window) rather than those of chrome.  The difference seems to
be that in this bug the problem manifests itself as denied DOM access whereas in
the mailnews message-pane bugs the problem shows up as denied script access.  I
came to this conclusing after removing the try/catch in the initScrollbar method
in scrollbar.xml.  Having done so, I saw access to property denied messages in
the javascript console when first loading a page into a new window (as in this
bug) and when opening the view source window.  I didn't see any js console
errors at all in the mailnews case.

Could these two cases be fixed simultanously, or should perhaps the mailnews
bugs be transferred to security:caps?

Comment 18

[John Morrison]

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

Comment 19

[Mitchell Stoltz (not reading bugmail)]

Moving to 0.9.5.

Comment 20

[Greg K.]

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

Comment 21

[Mitchell Stoltz (not reading bugmail)]

time marches on. Retargeting to 0.9.6.

Comment 22

[Mike Pinkerton (not reading bugmail)]

mitch, if i buy you a 6-pack of your favorite beverage, will you fix this? ;)

Comment 23

[Mitchell Stoltz (not reading bugmail)]

Moving the most time-critical bugs and minor security fixes to 0.9.7

Comment 24

[Andrew Thompson]

This now works for me in any recent build. Tested both skins, classic and modern.

Someone verify

Comment 25

[Mike Pinkerton (not reading bugmail)]

no way. it does work. how did this get fixed?!