Closed Bug 405179 Opened 15 years ago Closed 15 years ago

Lots of scrollbar remnants when scrolling


(Camino Graveyard :: General, defect)

Not set


(Not tracked)



(Reporter: samuel.sidler+old, Assigned: stuart.morgan+bugzilla)




(2 files)

Attached image 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)
I don't see that on 10.4 ppc. Only some grey detritus (bug 385058).
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.

Can you change the SCROLLBAR_VISUAL_DEBUG define in widget/src/cocoa/ (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 ?
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....
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.
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.
(In reply to comment #6)
> The XBL changes from bug 384612 probably.

Thanks for finding that Philippe. CCing Jonas.
Flags: blocking1.9?
Keywords: regression
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 :(
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?
Blocks: 384612
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.
(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.
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)
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.
Attached patch fixSplinter Review
This applies the toolkit changes from bug 384612 to the corresponding xpfe files.
Assignee: nobody → stuart.morgan
Attachment #290527 - Flags: superreview?(dbaron)
Attachment #290527 - Flags: review?(dbaron)
Attachment #290527 - Flags: approval1.9?
Attachment #290527 - Flags: superreview?(dbaron)
Attachment #290527 - Flags: superreview+
Attachment #290527 - Flags: review?(dbaron)
Attachment #290527 - Flags: review+
Attachment #290527 - Flags: approval1.9?
Attachment #290527 - Flags: approval1.9+
Landed on trunk.
Closed: 15 years ago
Flags: blocking1.9?
Keywords: regression
Resolution: --- → FIXED
Target Milestone: --- → Camino2.0
You need to log in before you can comment on or make changes to this bug.