Using the default Garland theme on 6.x.dev, fieldsets not always high enough to hold their content.
I first noticed this at admin/logs/dblog where the "Filter log messages" fieldset is not high enough to hold the SELECTs, which prevents selecting some of the values (Opera 9.21), but it also happens elsewhere, like at admin/settings/date-time where the "Formatting" fieldset has a similar problem.
In both cases, there is a horizontal scrollbar, but not a vertical one. The problem is not present when disabling CSS, in which case no scrollbar appears and the fieldset resizes properly.
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | opera_float_in_overflow_1.patch | 4.09 KB | dvessel |
| #16 | opera_float_in_overflow.patch | 3.87 KB | dvessel |
| #15 | hscroll.png | 22.44 KB | fgm |
| #9 | compare_opera.png | 97.43 KB | dvessel |
| #8 | date_time_reformat.patch | 3.58 KB | dvessel |
Comments
Comment #1
fgmScreenshot attached. Happens with dev version dated 2007-07-31.
Comment #2
dvessel commentedIt's due to an overflow property. These are always tricky.
Not sure why it was added in the first place. They are simple drop down fields.
Inside admin.css:
Comment #3
dvessel commentedThis plays a part in that. But have you run into any collapsible fieldsets that don't have the problem?
Sometimes the fields contained within the fieldsets containing margins can exhibit this behavior. Not sure about Opera, I don't have it.
Comment #4
fgmThis does not seem to be collapsible-related: on admin/settings/date-time, the problem happens on the second fieldset (non-collapsible) but doesn't happen on the first (non-collapsible either), while on admin/logs/dblog, it happens on a collapsible fieldset.
With today's version, it seems the second field on admin/settings/date-time and the one on admin/logs/dblog appear to be the only ones with this problem.
Comment #5
dvessel commentedIt makes sense that the date/settings --second set is being affected. Those are the fields with "date-container" class.
What's odd is that it was added in with a patch for db caching..
Look at revistion 1.14 and diff to previous.
http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/system/admin.css?v...
As for the dblog fieldset, it's related to this issue: http://drupal.org/node/67893..
There were issues with scrollbars appearing for firefox but I'm not seeing it after a few alterations.
Try this patch and see how it goes.
Comment #6
dvessel commentedChanging tags.
Comment #7
fgmThanks for the patch. It is indeed better: the problem disappears from
admin-settings-date-timeBut it remains in
admin/logs/dblogs. I've been able to remove it from there by removing theoverflow: autorule inmodules/system/system.csson#html.js fieldset.collapsible .fieldset-wrapper, which may be a problem, since it has apparently been added there to .You are also correct about the change from "Garland" to "theme system", because without this additional change, the problem on
admin/logs/dblogsis present with all core themes.Comment #8
dvessel commentedI forgot about this issue.. sorry.
The collapsible field set I cant' figure out so this patch skips it for now.
The date and time settings are way too wide when choosing a custom format. I now see why overflow was used. I think a better solution is to stack it vertically and remove the overflow completely.
A few styles where changed and the width of the custom field was toned down. There was a style to hide the custom field which prevents it from degrading well.
Tested in Opera, FF 2 and Safari 2. All worked well on my end.
Comment #9
dvessel commentedAnd here's a before/after in opera 9.22
Comment #10
dvessel commentedMaybe not so critical, whoops.
Comment #11
ChrisKennedy commentedThe horizontal layout was intentionally added to the custom date-time patch based on comments in http://drupal.org/node/105039 by Dries (#11) and a UI markup by m3avrck (#12). Surely there must be some way to tweak the CSS and keep it in there.
Comment #12
ChrisKennedy commentedMore accurate title.
Comment #13
dvessel commentedYeah, I guess the patch won't do then. Of course I decided to search for this problem a bit late and it's a known issue.
I'll try to put up a patch at a later date.
Comment #14
dvessel commentedAnd here's a possible fix!!?
http://archivist.incutio.com/viewlist/css-discuss/86919
Comment #15
fgmI'm not sure it's the same CSS problem, but there was an identical symptom on d.o. when adding a release node in Opera 9.23.
ISTR it was also there when editing a node even yesterday, but today I can only see it when adding the release node, so maybe a project maintainer has found a way to fix it in project module CSS and it could also be applied here.
Comment #16
dvessel commentedfgm, it does look like the same thing. The fields must be floating left. I got a fix though, and it solves the log pages and date time settings.
Selectors cleaned up a bit. Added new class for the date drop down does away with the immediate child selectors which can get messy.
Tested in Opera9, FF2 and Safari2 and IE6..
Comment #17
ChrisKennedy commentedTested logs/dblog and date-time settings on FF2, Opera 9, IE7, and Safari.
Comment #18
fgmWorks for me with this patch.
Comment #19
dvessel commentedSame patch with a note on Opera inside the style sheet.
Comment #20
dries commentedCommitted to CVS HEAD. Thanks.
Comment #21
junyor commentedFWIW, this Opera bug appears to be fixed (based on the test case at http://archivist.incutio.com/viewlist/css-discuss/86919) in internal builds of Opera 9.5, which will be available for public testing on Tuesday.
Comment #22
(not verified) commented