942341 - "top:0" for abspos content in a fieldset is no longer at the top of the <legend> (breaking e.g. the Mozillians "edit" page)

Status: RESOLVED INVALID

(Core :: Layout, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: screenshot.png

See attached screenshot of the lower section of https://mozillians.org/en-US/user/edit/.

The "Visible To" label & dropdown stomp on top of the descriptive text, making it unreadable.

(Viewed in up-to-date Firefox Nightly, on Ubuntu 13.10)

Comment 1

[Daniel Holbert [:dholbert]]

I'm guessing this looks great on Mac and/or Windows, due to a skinnier font being in use there, or something. You probably can reproduce it there by making your window skinnier, though.

e.g. I get pretty serious overlap when my window is barely wide enough for the Persona icon to still be rendered at the top. (If you make your window *too* skinny, it snaps into a "mobile" mode and the Persona icon disappears, and things render differently such that there's no longer overlap.)

(This bug has nothing to do with the persona icon overlapping stuff; I'm just using that as a hint for how small to make your window, to make it likely that you'll hit this.)

Comment 2

[Dan Poirier [:dpoirier]]

In my browser (Firefox/Linux) the dropdown is at the same level as the title, with the long sentence below the title and dropdown, so it goes across the screen and fits under the dropdown without overlapping.

Comment 3

[Daniel Holbert [:dholbert]]

Aha! I see that nicer rendering too, in Firefox 25. So this looks like it could be a browser bug (or change in behavior, at least).

Comment 4

[Daniel Holbert [:dholbert]]

(To be clear, my screenshot was taken with Nightly, and I confirmed that I still get overlapping text there, in a fresh profile.)

Comment 5

[Matt Brandt [:mbrandt]]

Daniel, thank you for continuing to dig :) Any chance you could retest using Firefox Beta? If it's a transient Firefox Nightly bug then perhaps we won't fix this.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Matt Brandt [:mbrandt] from comment #5)
> Daniel, thank you for continuing to dig :) Any chance you could retest using
> Firefox Beta?

I'll do you one better -- I ran mozregression and got this range:
{
Last good nightly: 2013-10-25
First bad nightly: 2013-10-26

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f8233fcce1d&tochange=ef3f5669b53e
}

So looks like a regression on trunk in the last month, in Firefox 27.

> If it's a transient Firefox Nightly bug then perhaps we won't
> fix this.

Yeah - for now, this looks like a Gecko regression. So, probably something you don't need to worry about fixing in the site, unless we get close to shipping it. :)

Based on the regression range above, I'm guessing this might be a regression from bug 261037, which was a reasonably large patch tweaking our <fieldset> behavior. (Inspect Element reveals that the "Visible To" text here is an abspos element, positioned at the upper-right of a <fieldset> element). It looks like it's expecting to be positioned next to the fieldset's <legend>, but instead, we're positioning it below the <legend>. roc, do you know if that was an expected change of bug 261037?

Comment 7

[Daniel Holbert [:dholbert]]

Reduced testcase:
data:text/html,<fieldset style="position:relative"><legend>hi</legend><div style="position:absolute;top: 0;">STOMP

In Firefox 25, STOMP is on top of hi.

In Nightly, STOMP is inside of the fieldset's border.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

FWIW I think the new rendering is more correct, for a few reasons:
-- top:0 for the abs-pos frame is inside its container's border, instead of outside
-- if the fieldset has 'overflow' not 'visible' and an abs-pos container, the abs-pos frame should be scrolled and clipped by the fieldset, and so we want top:0 to line up with the top of the scrollable/clipping area.
-- having a top:0 abs-pos child stomp the legend doesn't seem like a good thing

(The spec is silent on this, of course.)

Comment 9

[Daniel Holbert [:dholbert]]

I agree; I think the new behavior makes more sense, logically.

However, it raises interop issues, since unfortunately we're alone on the new rendering -- Chrome dev channel, Opera 12.16 (Presto), and IE11 all match our *old* behavior, using my testcase from comment 7.

Regardless of which behavior makes more sense _logically_, I wonder if we might need to preserve the old behavior for compat & not-breaking-the-web reasons...

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think we should wait a bit longer and see how much fallout there is.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

One problem with "preserving the old behavior" is that I don't see how to do that and simultaneously support *scrolling* fieldsets with abs-pos children in any kind of sane way.

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Matt Brandt [:mbrandt] from comment #5)
> Daniel, thank you for continuing to dig :) Any chance you could retest using
> Firefox Beta? If it's a transient Firefox Nightly bug then perhaps we won't
> fix this.

Matt: Probably worth working around this on mozillians.org, if possible, as this behavior-change looks likely to ship with Firefox 27 (and may stick permanently, per comment 11 and before).

[Tagging for needinfo? to make sure you're aware.]

Comment 14

[Daniel Holbert [:dholbert]]

[er, looks like my needinfo attempt in comment 13 didn't actually take effect. Trying again.]

Comment 15

[Matt Brandt [:mbrandt]]

Thanks for the minimal testcase to repro :dholbert as well as pointing out that this behavior will be likely be shipped in FX 27.

Should we retarget this bug to Community Tools :: Phonebook or would you prefer I file a new one against the project?

(sorry for the delayed response; I just returned from a month off/climbing trip)

Comment 16

[Daniel Holbert [:dholbert]]

It'd probably be best to leave this bug to be about Gecko, and spin off a separate bug to work around this in the Phonebook.  Then we can track any other fallout here, and decide whether it's worth trying to adjust the behavior (again), per comment 10 - comment 11.

Comment 17

[Daniel Holbert [:dholbert]]

(BTW: one easy backwards-compatible workaround on the phonebook would be something like:
 - Wrap each <fieldset> in a div
 - Move the "position:relative" styling off of the <fieldset> element and up to the div
Then, the abspos content will position itself with respect to the top of the div (i.e. alongside the <legend>), instead of at the top of the fieldset-body.)

Comment 18

[James Gilliland]

I've been using the feedback tool to report these for quite a few months now since I noticed it in the nightlies. Fieldsets aren't used that often so I haven't been able to narrow down a simple test case so its probably lost somewhere. 

This problem affects fieldsets theming on a large portion of Drupal installations(somewhat theme dependent). It actually makes the fieldsets completely unusable though because they collapse and if you can't toggle it with the legend you can't reach the content of the fieldsets.

Relevant discussion on drupal.org https://drupal.org/node/2158353

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you give me a link to an example?

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think we need to back 261037 out of mozilla-beta if we possibly can to give us more time to fix the Drupal issue in https://drupal.org/node/2158353. I will prepare a beta backout patch ASAP.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: testcase 1 (simplified testcase)

This seems to be what's happening in the Drupal case. You can't click on the DIV in the legend.

This problem is probably not related to positioning; once I've confirmed that, I'll spin it off into its own bug.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Moving the Drupal issue to bug 960277.

Comment 24

[rlayeh]

This bug will also occur when fieldset has top,bottom,left,right set to 0.

Please check this jsfiddle:
http://jsfiddle.net/K72C5/4/

With legend element entire fieldset is moved down a little bit and div inside it is also wrongly placed.

This was working on Firefox 27 it suddenly stopped working on Firefox 28.

Comment 26

[cesutherland]

This looks like https://bugzilla.mozilla.org/show_bug.cgi?id=450418 and it's test case https://bug450418.bugzilla.mozilla.org/attachment.cgi?id=333579 reproduces in FF28 and 29.

Comment 27

[Daniel Holbert [:dholbert]]

Attachment: screenshot of bug 450418's testcase in Firefox 3

(In reply to cesutherland from comment #26)
> This looks like https://bugzilla.mozilla.org/show_bug.cgi?id=450418

Not quite. Here's a screenshot of what that bug's testcase looked in Firefox 3 -- there's much more padding on the abspos element than what we have now. I believe that Firefox-3-era behavior wasn't explicitly intentional -- it was just what fell out of what we had implemented at the time.  In contrast, per comment 8, the behavior we have now is intentional and among the most reasonable behaviors, and it's unclear how we could make the intermediate "stomp on the legend" behavior work when the fieldset is scrollable.

Comment 28

[Daniel Holbert [:dholbert]]

Attachment: screenshot of bug 450418's testcase in current nightly (ver. 32)

Comment 29

[jcready]

This bug is almost two years old and it's been nearly a year since it was modified. What is taking so long to fix this? This is still broken in Firefox 41.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) (offline July 8-10) from comment #8)
> FWIW I think the new rendering is more correct, for a few reasons:
> -- top:0 for the abs-pos frame is inside its container's border, instead of
> outside

Setting the border to "none" or "0" is still causing the incorrect positioning. And if the container is supposed to start below the legend, then why does inspecting the fieldset in Firefox clearly show that the containing "box" extends above the legend? Shouldn't the area highlighted in Firefox's inspector show the same "box" that absolutely positioned child elements see/obey? And shouldn't the reported CSS height of fieldset also be forced to respect this magical containing box that only affects fieldsets with a legend?

No other browser has this behavior. When will Firefox fix this bug and match every other browsers' behavior?

Comment 30

[tomliv]

Is there an update or workaround for this issue. I have run into this with a current project and would rather not have to change my structure at this point.

No other browser is showing this issue.

Comment 31

[Nathan]

Hey guys,

It looks like there was a regression in Firefox Quantum relating to this bug. I've managed to reproduce only in Firefox Quantum and Safari 11. All other browsers I've tested are okay.


Bug Summary:
- Absolute positioned elements do not align top with fieldset element when legend is present.
- Bug demonstration: https://codepen.io/nathanch/pen/rYVKBv
- Bug screenshot: https://i.imgur.com/iFRJZso.png
- Bug screenshot (Chrome): https://i.imgur.com/6uMVYT9.png

Steps to Reproduce:
1. Have a fieldset element with position relative.
2. Inside the fieldset have a legend element.
3. Also inside the fieldset have a button positioned absolute top; 0, right; 0.

Expected Results:
- Button should align top, flush with fieldset element.

Actual Results:
- Button does not align top, instead, legend creates an invisible margin which is not selectable with CSS.

Version/Build:
Firefox Quantum (57, latesT)

Configuration:
Default, new install.


Let me know if you need more information. Thanks.
[e-mail]

Comment 32

[Daniel Holbert [:dholbert]]

(In reply to Nathan from comment #31)
> It looks like there was a regression in Firefox Quantum relating to this
> bug.

Are you sure you're actually seeing a regression? I just tested Firefox Nightly from nearly a year ago (2017-01-01) on your codepen, and it looks identical to your quantum "regression" screenshot to me.

If you're sure you found a regression in Quantum (57), please file a new bug with more details -- note that this bug here has been open for quite a while, so it's best not to co-opt it for newly-introduced issues.  (But as far as I can tell, the Firefox vs. Chrome difference on your testcase is indeed due to this bug and is not a regression.)

Note also that per comment 8 and comment 11, the current Firefox behavior might be the intended/preferable behavior for the general case (at least, in the absence of spec text that requires an alternate behavior).

Comment 33

[Mats Palmgren (inactive)]

I agree with roc's opinion in comment 8.  I think the current layout
is the only sane one from a box model point of view.  Try setting
overflow:scroll on a <fieldset> in Chrome to witness the horror
that ensues with a different model.

Given that there are no major web-compat issues here, I suggest we
close this bug.  Since dholbert and roc seems to agree, doing so...

Comment 34

[Daniel Holbert [:dholbert]]

I'm not sure I agree. I do agree that this is underspecified and low-priority, and we're not knowingly violating any spec text around this.  But other browsers have come to something of a consensus behavior on this, which may create webcompat issues (though thus far, not on major sites that we know of).

I'd marginally prefer to keep this open to track the known interoperability issue where we differ from everyone else, which we might possibly fix someday if this gets specified or if we decide that it's important enough to put resources into implementing something more interoperable here (or if a contributor cares deeply enough to write a patch that passes review). 

After doing a bit of further testing: let me reply to comment 11:
(In reply to Robert O'Callahan (:roc) (email my personal email if necessary) from comment #11)
> One problem with "preserving the old behavior" is that I don't see how to do
> that and simultaneously support *scrolling* fieldsets with abs-pos children
> in any kind of sane way.

It seems that Chrome/Edge handle this by placing the scrollframe (scrollbars, etc) one level higher than we do -- they place it around the fieldset as a whole, with the scrollbar (somewhat confusingly) protruding from the fieldset's border.

So basically: for them, the scrollable area and the abspos area are both the area *up to the top of the <legend>* (which is a bit larger than the bordered area).  And if you move the scrollbar, the contents (including abspos children) *and* the legend all get scrolled (and you can see them visibly scrolling across the top border of the fieldset).

This is all a bit wacky, and personally I prefer our behavior, but I can imagine a coherent implementation that'd mimic the Chrome/Edge behavior here. We'd need a special hack to draw the fieldset's border in the correct place (since it's drawn around the fieldset content but does not scroll with the fieldset content).

Comment 35

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (exercising scrollable fieldsets)

Comment 36

[Boris Zbarsky [:bzbarsky]]

We should really get the interop story sorted out.  If you think that the Chrome behavior is broken, please file a bug on them so they're aware of that.  And probably raise this with the CSS WG.

Comment 37

[Mats Palmgren (inactive)]

It turns out I did file a Chrome bug about <fieldset> scrolling,
but I forgot about it:
https://bugs.chromium.org/p/chromium/issues/detail?id=786475
The response was:
"Realistically we're not going to fix this prior to LayoutNG."
(closed as Wontfix)

I read that as confirmation that Chrome's current layout is a bug
and that they'll fix that later in their new layout engine.

Regarding CSS specs for this, my impression is that the CSSWG isn't
interested in specifying any layout details about <fieldset>,
or form controls in general.

Comment 38

[Boris Zbarsky [:bzbarsky]]

> and that they'll fix that later in their new layout engine.

I see no guarantee of that, if they're not tracking it.  :(

> my impression is that the CSSWG isn't interested in specifying any layout details about <fieldset>

Elika, is this correct?  This is causing interop problems in practice...

Comment 39

[fantasai]

I think we're interested in having a form controls spec, but we don't have anyone to work on it. For fieldset specifically, it might make sense to put the spec in the HTML Rendering section, working with both the HTML and CSS folks to get it right. Depending on where you think the expertise for that is, would make sense to file an issue against HTML or css-ui-4 (or both).

For form controls in general, that's a big project that's probably best as a separate module--and no one has volunteered to do it even though we've needed one for years. Important and tricky considerations there are not just back compat, but also cross-platform considerations, security, and future compat: form controls differ by platform/device and are expected to evolve over time. These are a lot less important for fieldsets, though, which would ideally be describable in pure CSS terms. (They're forms markup, but not really interactive controls in the same way as input/textarea.)

Comment 40

[Boris Zbarsky [:bzbarsky]]

Right, I was talking about fieldsets specifically.  General form controls are... complicated.

Comment 41

[fantasai]

Yeah, file an issue. I'm sure HTML can host a spec just for <fieldset>, whether we work out the details in their repo or ours. I think we'd all be thrilled (authors included) if it's possible to do in a Web-compatible way with just some UA stylesheet rules... I honestly know nothing about this (other than it's unnecessarily complicated) though, so I don't know how much I can help.

Comment 42

[Boris Zbarsky [:bzbarsky]]

> if it's possible to do in a Web-compatible way with just some UA stylesheet rules

Last I checked, it's not.

I filed https://github.com/whatwg/html/issues/3660

Comment 43

[Mats Palmgren (inactive)]

FWIW, Safari TP now appears to be compatible with Firefox both for
fieldset scrolling and the abs.pos. CB (testcase 2 renders the same).
Also, the Chromium bug has been reopened:
https://bugs.chromium.org/p/chromium/issues/detail?id=786475