36430 - Ghost of scrollbar in pref/fonts - two scrollbars?

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[R.K.Aa.]

After bug 26508 (dead scrollbars in pref/fonts) got solved and one could scroll
again, i got a feeling there were really TWO scrollbars there.
The reason for this is that it took a second before the scrollbar reacted, but
when it had first reacted it was quick. Till next time i clicked it - then it
took another sec, untill it revived.

On april 4th another bug appeared: Font dropdown boxes in prefs had no scrollbar
at all. (bug 34525)

Tonight a fix for 30091 was checed in and when i now test moz with build
2000041908 M16, the dropdown widgets for fonts in prefs suddenly work again!

But what's more: The first time you click a dropdown box with a scrollbar in
prefs/fonts, you see a "ghost". The contours of second scrollbar is visible in
the "middle", and another to the right, in the correct position. This is visible
for around 1/3 of a second, then it adjusts and a seemingly normal dropdown box
appears.

With fonts and all, and usable.

But the strange behaviour remains - there's a lag before the scrollbar reacts to
mouseinput.

I don't think this extra scrollbar is only a visual echo of the "real" scrollbar
- i suspect there's double up with code for scrollbars here, which is causing
all the odd trouble now and then.

Comment 1

[R.K.Aa.]

in other words...i suspect there's both a gtk set of scrollbars - and a html
listbox type of scrollbars enabled - for the same areas in prefs. Competing.
They have the exact same look, but the recent changes made the listbox version
of them reflow a little different now, thus the visible ghost for a brief sec.
Perhaps i'm far out but the behaviour of those scrollbars is odd. I'm on a P120
so i notice quite easily when something is "wrong" speedwise.

Comment 2

[John Morrison]

I do see the doubled up scrollbars flash in as the panel loads.
These are the native scrollbars that are part of the list boxes (html:select).
I think this is pretty much a dup of bug #19608, which you can see while 
loading bugzilla.mozilla.org/query.cgi -- passing to waqar / HTML Form Controls
who has 19608.

Comment 3

[sairuh (rarely reading bugmail)]

confirming... and i only see it on linux [opt comm 2000.04.19.09-m16], but not
on Mac or winNT.

Comment 4

[R.K.Aa.]

I might add that i've tested almost all the runnable versions of nightlies since
M11 and never seen this bug before.

Comment 5

[R.K.Aa.]

but i HAVE seen bug 19608 - all the time. That seems different - that's a bug
where the boxes don't expand till mozilla has determined the size they should
have. This one's different and it's never looked like this before.
In addition there is no speed-problem with scrolling the scrollbars in listboxes
on web. But the lag before the preferences scrollbar reacts is striking.

Comment 6

[waqar]

I see it as well.

Comment 7

[R.K.Aa.]

I'm drawing the wrong conclusion on the speedmatter: Tested another dropdownbox
with scrollbar (http://www.cnn.com/WEATHER/) -  box titled "Or, choose a state".

The slider at first reacts slow there too. So that's not a part of the problem.
But the ghost now in prefs - and the various occations where scrollbars in prefs
have been suddenly stuck - or simply vanished "for no reason" - is odd. And no
fix for the "missing listbox" bug was checked in - it simply "fixed itself". The
only checkin in the relevant periode that i see can have had any significance,
is the fix for bug 30091. I still have a feeling there's "coding and
counter-coding" being done when it comes to widgets in the preferences box. But
female intuition may not help mozilla much ;)

Comment 8

[R.K.Aa.]

well i won't be nomiated bugreporter of the year for this one..
The CNN slider reacts a good deal quicker than it's sibling widget in prefs.
I've been scrolling for half an hour here. The lag is about double as long in
prefs - if you can call one second "long". No idea why it doesn't detect a grab
quicker though. It reacts instantly to mousewheel scrolling. Test it.

Comment 9

[R.K.Aa.]

hmm well someone cleaned up good. Now there are NO scrollbars in pref/fonts.
I filed bug 37304 as it seems to be a new case of lacking scrollbars.
[2000-042609-M16 Linux]

Comment 10

[waqar]

This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.

Comment 11

[R.K.Aa.]

after the whole layout in prefs was changed, that eliminated this problem.
Setting WFM.

Comment 12

[ckritzer (gone)]

small atomic mass update:
qacontact->jrgm