541839 - <button style='overflow:hidden'> text at cusp of being entirely outside button displayed only at some zoom levels

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[[:nickname]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)

With the provided minimal test case, this button within the floated DIV will show the text of the button only on full page zoom levels > 100.

<style>
    div {
        float: left;
    }
    button {
        border:0 none;
        height: 23px;
        overflow: hidden;
        padding: 22px 0 0;
    }
</style>
<div>
<button>Foobar</button>
</div>

It does *not* show the text when on full page zoom level <= 100. Text-only zoom does not affect the rendering in this way.

The text cannot be selected. It looks like a rendering error.

Reproducible: Always

Steps to Reproduce:
1. Open test case in F 3.6
2. Ensure full page zoom level is > 100

Actual Results:  
The button text is shown below the button.

Expected Results:  
The button text should *not* be visible, i.e. FF 3.5 behavior.

Comment 1

[[:nickname]]

Attachment: Self contained HTML test case

Comment 2

[[:nickname]]

Attachment: Full page zoom 100, the text of the button is not visible

Comment 3

[[:nickname]]

Attachment: Full page zoom 110, the text of the button is visible

Comment 4

[[:nickname]]

Doing some variations to the CSS may *always* show the button text, which is inconsistent with the FF 3.5 behavior.

E.g., removing the float from the DIV always shows the text, no matter which zoom level.

Is this possibly a result of bug 491180?

My view without considering 491180: this is report is an error in that it shows the text which should not be shown.

Considering 491180: the text should always be shown, independent on the full page zoom level.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This seems pretty bad; perhaps the bug has something to do with telling the display list system that we're going to clip the content but then not actually doing it, so that if it determines that there's a slight overlap then the whole thing gets painted?  Or something else similar to that at paint time?

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And I see this on Linux as well, mozilla-central debug build from within the past week.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Or it could be we're failing to set the overflow area (of what?) properly.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oh, I see what's going on.

The testcase specifies 'overflow: hidden', but we don't actually do anything to support overflow:hidden on buttons.  However, when nsHTMLButtonControlFrame::Reflow calls ConsiderChildOverflow, ConsiderChildOverflow checks disp->IsTableClip(), which determines that we have overflow:hidden and don't need to add to the overflow area.

It seems like if we want to hard code behavior, perhaps we should be doing it with !important in the UA style sheet (and then changing the test in nsHTMLButtonControlFrame::BuildDisplayList to check the 'overflow' property) so that this sort of confusion doesn't happen.

Comment 9

[Boris Zbarsky [:bzbarsky]]

The test mentioned in comment 8 is added in bug 541382.  After that this text should just be clipped.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Yeah, the patch in bug 541382 fixes this: the text is never shown.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Fixed by checkin for bug 541382.