405179 - Lots of scrollbar remnants when scrolling

Status: VERIFIED FIXED

(Camino Graveyard :: General, defect)

Description

[Samuel Sidler (old account; do not CC)]

Attachment: Screenshot

When I scroll the main window or any multi-<select> widget, I get remnants in the scrollbar view. I don't see this in Minefield, only in Camino.

Note: I'm scrolling using the two-fingered trackpad trick. But clicking and holding the down arrow of a scrollbar has the same effect until release. On release, the scrollbar redraws.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9b2pre) Gecko/2007112201 Camino/2.0a1pre (like Firefox/3.0b2pre)

Comment 1

[philippe (part-time)]

I don't see that on 10.4 ppc. Only some grey detritus (bug 385058).

Comment 2

[Chris Lawson (gone)]

I can still reproduce the gunk in both comment 0 and comment 1 fairly regularly, though it's much more difficult to get comment 0 than it is to get comment 1.

cl

Comment 3

[Colin Barrett [:cbarrett]]

Can you change the SCROLLBAR_VISUAL_DEBUG define in widget/src/cocoa/nsNativeThemeCocoa.mm (it's near the top of the file) from 0 to 1, and post a screenshot?

Haven't problems with XUL scrollbars in past been caused by missing xpi files (I don't understand how)?

Do you have a regression range? Perhaps fallout from bug 384612 ?

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I've not seen this bug, but if someone can give me solid STR, I'll look and play with XPTs when I get back.  OTOH, bug 396803 is a superset of this and can be seen in Minefield....

Comment 5

[Joel Craig]

My last good build was Camino Version 2007111900 (2.0a1pre), I went into the hospital for a few days and it was there on the 23rd when I was released.

Comment 6

[philippe (part-time)]

Got it: you need to have Place scroll arrows 'Together' selected in the system prefs. (I normally have it set to 'At top and bottom ')
That regressed between 
2007111900 (2.0a1pre) Ok
2007112001 (2.0a1pre) Fails

The XBL changes from bug 384612 probably.

Comment 7

[Samuel Sidler (old account; do not CC)]

(In reply to comment #6)
> The XBL changes from bug 384612 probably.

Thanks for finding that Philippe. CCing Jonas.

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Adding the content xpts from bug 371860 doesn't make this go away.  Nothing among the other xpts we aren't packaging jumps out at me as likely to cause this, either.  So at the very least, more investigation is needed :(

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Please mark regressions properly so that they don't get lost (using the blocking field).

Does this only happen in camino? This looks very much like bug 377439. Are you guys honoring the look-and-feel flags properly when painting scrollbars?

Comment 10

[Colin Barrett [:cbarrett]]

They paint the same way that Minefield does, we're using the same widget toolkit.

I believe that the viewport scrollbar is Gecko, not native, as well.

When testing, make sure you're not triggering bug 377439. Patches welcome for it, btw. It should be pretty easy.

Comment 11

[Stuart Morgan]

(In reply to comment #10)
> When testing, make sure you're not triggering bug 377439.

I never change my pref, and I see this, so it's definitely not 377439.

Comment 12

[Stuart Morgan]

Ah, but the up arrow still behaves as if it were at the top. So the issue is that the pref isn't being applied at *all* (not just that it's not live, like in bug 377439)

Comment 13

[Stuart Morgan]

Bug 384612 made some css/xml changes in toolkit only; probably we just need to sync those changes over to xpfe. I'll take a look later tonight or tomorrow morning when I have more time.

Comment 14

[Stuart Morgan]

Attachment: fix

This applies the toolkit changes from bug 384612 to the corresponding xpfe files.

Comment 15

[Stuart Morgan]

Landed on trunk.