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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fgm’s picture

FileSize
40.53 KB

Screenshot attached. Happens with dev version dated 2007-07-31.

dvessel’s picture

It'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:

/**
 * Date and time settings page
 */
div.date-container {
  overflow: auto;
  clear: left; /* LTR */
}
dvessel’s picture

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...

This plays a part in that. But have you run into any collapsible fieldsets that don't have the problem?

/* Avoid jumping around due to margins collapsing into collapsible fieldset border */
html.js fieldset.collapsible .fieldset-wrapper {
  overflow: auto;
}

Sometimes the fields contained within the fieldsets containing margins can exhibit this behavior. Not sure about Opera, I don't have it.

fgm’s picture

This 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.

dvessel’s picture

Title: Incorrect sizing of fieldsets » overflow in fieldsets makes Opera sad
Status: Active » Needs review
FileSize
1006 bytes

It 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..

Patch #138706 by hunmonk: fixed PostgreSQL caching problem

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.

dvessel’s picture

Component: Garland theme » theme system
Priority: Minor » Normal

Changing tags.

fgm’s picture

Status: Needs review » Needs work

Thanks for the patch. It is indeed better: the problem disappears from admin-settings-date-time

But it remains in admin/logs/dblogs. I've been able to remove it from there by removing the overflow: auto rule in modules/system/system.css on #html.js fieldset.collapsible .fieldset-wrapper, which may be a problem, since it has apparently been added there to Avoid jumping around due to margins collapsing into collapsible fieldset border.

You are also correct about the change from "Garland" to "theme system", because without this additional change, the problem on admin/logs/dblogs is present with all core themes.

dvessel’s picture

Title: overflow in fieldsets makes Opera sad » fix layout of date and time settings.
Priority: Normal » Critical
Status: Needs work » Needs review
FileSize
3.58 KB

I 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.

dvessel’s picture

FileSize
97.43 KB

And here's a before/after in opera 9.22

dvessel’s picture

Priority: Critical » Normal

Maybe not so critical, whoops.

ChrisKennedy’s picture

The 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.

ChrisKennedy’s picture

Title: fix layout of date and time settings. » Fix Opera CSS quirk in date-time settings.

More accurate title.

dvessel’s picture

Status: Needs review » Needs work

Yeah, 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.

dvessel’s picture

fgm’s picture

FileSize
22.44 KB

I'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.

dvessel’s picture

Title: Fix Opera CSS quirk in date-time settings. » Fix Opera CSS quirk
Status: Needs work » Needs review
FileSize
3.87 KB

fgm, 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..

ChrisKennedy’s picture

Status: Needs review » Reviewed & tested by the community

Tested logs/dblog and date-time settings on FF2, Opera 9, IE7, and Safari.

fgm’s picture

Works for me with this patch.

dvessel’s picture

Same patch with a note on Opera inside the style sheet.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

Junyor’s picture

FWIW, 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.

Anonymous’s picture

Status: Fixed » Closed (fixed)