307654 - Scrollbars in Extension Manager are not displayed with the default 1.0.x EM width

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Ria Klaassen (not reading all bugmail)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050908 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050908 Firefox/1.6a1

When I upgrade from 1.0.6 to latest branch build the EM has no scrollbar.
But if I make the EM wider in 1.0.6 it does inherit the scrollbar.
Hm, they are both 12 cm wide but in 1.0.6 it has a scrollbar but not in 1.4.

Reproducible: Always

Steps to Reproduce:
1. Run 1.0.6 in a new profile.
2. Install some extensions
https://addons.mozilla.org/extensions/?application=firefox (I tried the first five).
3. Restart 1.0.6 and verify that there is a scrollbar.
4. Then run the latest branch build. 


Actual Results:  
The EM shows no scrollbar.

Expected Results:  
Inherit the scrollbar.

Don't know if this is a EM bug or a manifestation of a localstore.rdf problem.

Comment 1

[Ria Klaassen (not reading all bugmail)]

It is a regression: somewhere between 25 July and 28 July. If it is important
enough I'll narrow it down but I don't expect so.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Here's a screenshot: http://img291.imageshack.us/img291/5991/comp9pp.png

Comment 3

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

I believe the actual problem is that the width is maintained from when it was
used with 1.0.6 and stored in the localstore.rdf... so, in a manner the width
*is* migrated and the default width from 1.0.6 is not wide enough now that the
"Find Updates" button is wider due to it only having the text "Update" previously.

Comment 4

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

On linux using both a new gnome and kde environment the EM in a new profile is
also in this state where no scrollbars are displayed due to the window not being
wide enough. New profiles are not in this state on Win32. Not sure about Mac OS
X but I wouldn't be surprised if it is also affected as well as other platforms.

Comment 5

[Dan Potter]

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

Comment 6

[Dan Potter]

I've written an extension that had basically exactly this problem.  It's
definitely caused by the width being saved in localstore.  The way I wound up
working around it in the extension was to actually alter the localstore RDF and
unassert the width/height values, which is rather - well, cludgey.  It worked in
my extension because the width/height should never have been persisted in the
first place; however they should in this case.

As for handling this in Firefox 1.5, that's a more interesting question.  I can
come up with a few solutions that involve various API enhancements :) (minimum
window sizes, allowing the prefered size to be obtained through JavaScript,
etc.)  I suppose simply unasserting the various localstore RDF values on upgrade
would work.

It should be noted that since the localstore values are placed onto the window
AFTER onload is called (or at least they were when I ran across this with my
extension), so altering the size in the onload event handler won't work.

I really don't have any good suggestions about this, but I'm attaching a
screenshot that shows the extension windows "before" and "after".  The real
problem is that on Windows XP, the extensions window sizes such that it doesn't
really look "wrong", it just looks like there's no scrollbar.  In reality the
window is just a good 30 pixels or so too narrow.

What I'd like to suggest is to pull the size that sizeToContent() would produce
and compare it with the localstore values on upgrade.  If the localstore values
are too small, remove them from the localstore.  Unfortunately I don't know any
way to do this, so I can't submit a patch.

Comment 7

[Dan Potter]

Attachment: Compares the 1.0 and 1.5 extension window, showing the clipped scrollbar in 1.5.

This shows how the two Extensions windows (from Firefox 1.0 and Firefox 1.5)
compare.  Note that the lower window is sized such that it really doesn't look
"wrong," exactly, it just looks like the scrollbar is missing.	(Although "Get
More Extensions" is slightly clipped.)

Comment 8

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

Attachment: patch

Sets the min-width of #commandBar to 1px as is done with toolbars so when the
window is not as wide as the width of the contents of #commandBar the scrollbar
for the richlistbox is still shown.

This also increases the default width of the EM window by 20px since it appears
that the current default size did not get adjusted when the update button's
text was changed from 'Update' to 'Find Updates'... at least it is cropped with
a default Linux config. I increased the width by 20px instead of trying to come
up with the minimum amount required since this is OS theme dependent and the
window is still 80px less wide than the theme manager window which does not
need adjustment.

Comment 9

[Ria Klaassen (not reading all bugmail)]

See Bug 308264.

Comment 10

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

This will take care of that as well.

Comment 11

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

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

Comment 12

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

Comment on attachment 195852 [details] [diff] [review]
patch

Didn't realize you changed your email.

Comment 13

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

Checked in on trunk

Comment 14

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

Checked in on MOZILLA_1_8_BRANCH

Comment 15

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

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

Comment 16

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

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

Comment 17

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

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

Comment 18

[Kevin Brosnan]

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

Comment 19

[Kevin Brosnan]

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

Comment 20

[Chris Zubak-Skees]

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