Tgis is spun off from Bug 770645 Comment 13 There are two fieldsets, one without overflow and another with. The second fieldset is working good in Firefox 25 but not in Firefox 27.0a2 STR Open attachment 8333818 [details] Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/9f8233fcce1d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131025025009 Bad: http://hg.mozilla.org/mozilla-central/rev/85ade1df0597 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131025092711 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f8233fcce1d&tochange=85ade1df0597 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/c79088ab4e0c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131024215509 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/c1578a4fc86d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131025004510 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c79088ab4e0c&tochange=c1578a4fc86d Suspected: 44de05b3239b Robert O'Callahan — Bug 261037. Support scrolled fieldsets. r=mats

The old rendering just showed us not actually applying the overflow property. The new rendering looks correct to me, insofar as you can reason about how CSS applies to <fieldset> at all.

I think attachment 730479 [details] might be a better testcase for the issue I had in mind. See attachment 731562 [details] for a screenshot of how other UAs rendered it 2013-03-30. It appears they have a different idea of where the (top) clip edge should be. I don't necessarily think they are correct, but nor are we IMO. I think the ideal would be to clip at the padding edge, like we do at the bottom, but yeah, I understand that's going to be tricky given that the inner anonymous block doesn't stretch that far. But that's where the padding edge of the *fieldset* should be as I see it, because that's where the border starts. IOW, the vertical space that the legend incurs belongs to the padding area.

I don't feel strongly about it though; I think our current rendering is fine for the time being, given that there's no spec for fieldset rendering.

It seems to me that the clip edge should be in the same exact place for overflow:scroll and overflow:hidden...

Absolutely, I didn't mean to imply otherwise.

The behavior in IE10 and Chrome33 seems identical. The legend moves out of view together with the content when I scroll. That doesn't seem right.

One drawback with having the clip edge below the border is that the content would appear under the (bottom half of) the legend when you scroll. Hmm, so maybe the current layout is the best compromise after all...

One way of dealing with that overlap during scroll could be a fading/blurring effect for the part under the legend so that it doesn't affect readability of the legend to much. Seems like a lot of work for not much gain though, so I'm leaning towards wontfix.

We can mostly fix this by laying out the fieldset's child at the top-left of the inner edge of the fieldset's border, and putting the space between the inner edge of the top border and the bottom of the legend into the fieldset's child's top padding. border-radius is still a bit broken though. This isn't all that important so I'm attaching my experiments here but not planning to work on this for now.

The rounded borders looks fine to me with that patch (on Linux) except on the corners that meets with a scrollbar, but that problem also occurs in Nightly so it seems like an existing problem. This looks nice when viewing the attached test, but when I change it to a default black- on-white colors it does become a bit messy when scrolling.

Mats, you can review that WIP patch if you want. I'm just a little bit worried about it causing regressions that I don't really want to spend time fixing :-).

Actually I just noted comment #9, and I agree with you. WONTFIX!

It's a pity because I really like the clipping that patch implements. It looks better and it feels more box model correct. I've thought of ways to avoid the overlap, by default, but it's hard because the legend and its siblings are normally in the same stacking level. I can think of two alternative solutions (and I'll write them down here just for the record - I don't plan to work on it). A. specify a default background in the UA sheet for the legend if it's in a fieldset that is scrollable. And give it some special priority in the stacking context, above its normal flow siblings. B. move the legend upward when scrolling occurs until its bottom edge meets the fieldset padding edge, but not further. That would avoid the overlap, but it will make the top of the legend overflow the fieldset frame, which might be a problem if the background above has the same color as its text, making it unreadable. That seems unlikely though and a minor issue if it occurs.