STR: 1. Load attached testcase. ACTUAL RESULTS: The <input type="reset"> and <input type="submit"> elements have large overflow areas (as large as their text would be if it weren't clipped, it seems), despite the fact that they don't actually paint any overflowing text. EXPECTED RESULTS: The overflow area (revealed by the outline) should correspond to what's actually overflowing. The testcase includes some examples with <button> & various styling as well. <button> mostly behaves as I expect, except that for "overflow:auto" & "overflow:scroll", it has a large outlined region just like <input> does.

Here's a screenshot, with hand-drawn red underlines to highlight the outlined overflow-regions that I think are unnecessary/incorrect.

So the paint-clipping here happens as a result of this clause: > 120 if (IsInput() || StyleDisplay()->mOverflowX != NS_STYLE_OVERFLOW_VISIBLE) { > [...] > 126 clipState.ClipContainingBlockDescendants(rect, hasRadii ? radii : nullptr); > 127 } http://mxr.mozilla.org/mozilla-central/source/layout/forms/nsHTMLButtonControlFrame.cpp?rev=a2a7c4cc94dc#120 The "IsInput()" special-case there dates back to bug 491180, and the "overflow" check dates back to bug 541382. Neither bug seems to have made an intentional decision about leaving overflow areas un-clipped. I suspect it was just an oversight.

I think the patch is as simple as this -- this just makes us skip the "ConsiderChildOverflow" call during reflow, using the same conditions that we use to control clipping when we paint. This changes our rendering of testcase 1 to collapse away all of the red-underlined areas in my screenshot.

Try run to be sure this doesn't break any tests (on linux at least): https://treeherder.mozilla.org/#/jobs?repo=try&revision=e0aaae3ce6e0 If that looks good, I'll add a reftest & request review in the morning.

Comment on attachment 8737103 [details] [diff] [review] fix v1 r=mats

Thanks!

Added a reftest. Carrying forward r+. Try run with the reftest included (on all platforms, to catch any platform-specific formcontrol weirdness here): https://treeherder.mozilla.org/#/jobs?repo=try&revision=0ad60cbe2d96

I reproduced the initial issue on Nightly 48.0a1 (2016-03-31). I verified that the issue is fixed using Firefox-48.0b6 on Windows 10 x64, Ubuntu 14.04 x32, Mac 10.11.

I was able to reproduce the issue on nightly build 48.0a1. I verified the issue is fixed with firefox 48.0b7 on MAC Yosemite 10.10.2.

[bugday-20160713]

Thanks Cipri and Jules for your contribution :) Based on your results, marking here accordingly!