554237 - Dual vertical scrollbars if any type of add-ons exceed window area

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Tony Chung [:tchung]]

Attachment: Dual Sliders Screenshot

Dual vertical sliders appear if installed extensions exceed the window area of addons.  See screenshot.

A new instance of Addons Manager is opened whenever your reloading a disabled
plugin.  Instead, it should just detect the addons manager tab is already
opened, and navigate to it.

Repro:
1) Download Addons project branch nightly: Mozilla/5.0 (Macintosh; U; Intel Mac
OS X 10.6; en-US; rv:1.9.3a4pre) Gecko/20100321 Minefield/3.7a4pre
2) install a few extensions
3) Resize the firefox window so it forces the extension list too long that you need to pan down
4) Verify dual sliders appear

Expected:
- single vertical sliders

Actual:
- dual vertical sliders

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It's something simple Blair can fix. No input from ux needed here.

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Grr, another mac-only bug.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Went to find this on the Mac build, assuming it was Mac-only, since I never saw it on Windows - but I can't reproduce it on Mac either. 

It could potentially have been introduced by http://hg.mozilla.org/projects/addonsmgr/rev/035f20067079 

But I don't see anything that would have accidently fixed this in the past couple of days. Can you verify with a newer build?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I can see this on Windows too. In my case it is visible on the themes pane after installing the Waltnut theme. The innermost scrollbar has the height of all theme richlist entries while the outer one is for the panes.

Comment 5

[Paul [pwd]]

I see this on extensions, but not plugins.

Comment 8

[Markus Stange [:mstange]]

First guess: Maybe you need an addon with a multi-line description. Line-wrapping is known to cause headaches in XUL.

Why are there nested scrollboxes in the first place?

Comment 9

[Markus Stange [:mstange]]

Oh I see, the changeset you linked to...

Does this work? #search-list > scrollbox { overflow: visible; }

Though it would probably be cleaner to create non-scrolling-richlistbox binding that doesn't use a <scrollbox>.

Comment 12

[bogas04]

Bug on windows Confirmed

Comment 13

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #9)
> Oh I see, the changeset you linked to...
> 
> Does this work? #search-list > scrollbox { overflow: visible; }
> 
> Though it would probably be cleaner to create non-scrolling-richlistbox binding
> that doesn't use a <scrollbox>.

Note to self: This fixes it.

Comment 14

[[e-mail]]

(In reply to comment #9)
> Though it would probably be cleaner to create non-scrolling-richlistbox binding
> that doesn't use a <scrollbox>.
Why do you need a non-scrolling-richlistbox anyway?

Comment 15

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #14)
> (In reply to comment #9)
> > Though it would probably be cleaner to create non-scrolling-richlistbox binding
> > that doesn't use a <scrollbox>.
> Why do you need a non-scrolling-richlistbox anyway?

Because there are other things we want to scroll with the addon items, but shouldn't act like a richlistitem (such as the search filter checkboxes).

Comment 16

[Alfred Kayser]

Why make it yourself so hard in wanting to also scroll the filter checkboxes?
The richlistitem itself has scrolling implemented, re-implementing it will cause another series of bugs to be solved... (dual scrollbars, scroll to selected item, etc). With normal trees, the sort-direction in the treecol also doesn't scroll away...
Also, when the search filter checkboxes are scrolled away, will also cause usability issues...

Comment 17

[[not reading bugmail]]

(In reply to comment #3)
> Went to find this on the Mac build, assuming it was Mac-only, since I never saw
> it on Windows - but I can't reproduce it on Mac either. 
> 
> It could potentially have been introduced by
> http://hg.mozilla.org/projects/addonsmgr/rev/035f20067079 
> 
> But I don't see anything that would have accidently fixed this in the past
> couple of days. Can you verify with a newer build?

I noticed its in the new landing, but only came across it when I made the browser 1/4 the screen size of 1024x768.. it shows both scrollbars in the right hand side, but if the browser takes up the entire screen and the list is still scrollable, I only get one vertical scrollbar.  I'm on Windows 7.

Comment 18

[Paul [pwd]]

Attachment: Dual Scrollbars on Minefield Nightlies Windows 7

Just to re-confirm that this is still happening.

Comment 19

[Robert Strong (they/them - no direct email)]

Thanks... just so everyone knows, until this bug is fixed it will continue to happen so no need to confirm / re-confirm.

Comment 20

[WildcatRay]

FYI-I just found that installing FlashGot causes this for me. Uninstalling "corrected" things. Disabling had no effect. So long as FlashGot was installed, there appeared to be the extraneous scroll bar. I will attach a picture of the Add-on Mgr with FlashGot, Java Quick Starter and Java Console as the only installed add-ons. You will be able to see the scroll bar on the right even though there is not enough installed add-ons to trigger the normal window scroll bar.

Comment 21

[WildcatRay]

Attachment: AoMUI Scroll Bar Caused by having FlashGot Installed

Comment 22

[WildcatRay]

FYI-Without FlashGot installed, my nearly 30 installed add-ons installed on a new profile produces the expected normal scroll bar.

Comment 23

[d.a.]

This bug seem to be triggered if any of the extensions have an extensive description. When I shortened the description for FlashGot and NoScript (the two extension that had long descriptions) the extra scrollbar disappeared.

Comment 24

[WildcatRay]

I had the Add-on Mgr. in a maximized browser tab. Later when I windowed the browser, the second scroll bar would appear. Maximizing it again did not remove the added scroll bar.

Comment 25

[Dave Townsend [:mossop]]

Attachment: patch rev 1

Using nested scrollboxes is going to leave us implementing workarounds for all the stuff that richlistbox already implements itself so I think we should just go for a straight single richlistbox for the list views. The only real annoying part is that the sort service won't ignore the header elements but we can get around that by temporarily removing them from the list when sorting.

Comment 26

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 444796 [details] [diff] [review]
patch rev 1

This does indeed seem a lot better.

Comment 27

[[e-mail]]

Comment on attachment 444796 [details] [diff] [review]
patch rev 1

>-    this._listBox.collasped = aShow;
This isn't theme-friendly... although collasped wasn't either, being a misspelling ;-) Assuming it works, I prefer hidden anyway.

Comment 28

[[e-mail]]

(In reply to comment #27)
>(From update of attachment 444796 [details] [diff] [review])
>>-    this._listBox.collasped = aShow;
>This isn't theme-friendly... although collasped wasn't either, being a
>misspelling ;-) Assuming it works, I prefer hidden anyway.
Wait, I was looking at the wrong copy of this line (also misspelled).

Comment 29

[Dave Townsend [:mossop]]

Landed in http://hg.mozilla.org/mozilla-central/rev/b28ec304976f. Also removed the other broken collasped reference as it clearly wasn't needed.

Comment 30

[Robert Strong (they/them - no direct email)]

-> verified

Comment 31

[bogas04]

Fixed :D