Closed Bug 864759 Opened 7 years ago Closed 2 years ago

Text is drawn over the {float:right} <input> when {white-space:nowrap} is applied.

Categories

(Core :: Layout: Block and Inline, defect)

20 Branch
x86
All
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: zbujtas, Unassigned)

References

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31

Steps to reproduce:

loaded a page with the following content:

<html>
<head>
<style>
  div {
    text-overflow: ellipsis;
    overflow: hidden;
    white-space: nowrap;
  }

  input {
    float: right;
  }
</style>
</head>
<body>
<div>
<input type="text">
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</div>
</body>
</html>


Actual results:

When the viewport is sized so that the text in the <div> overflows, the <input> gets overdrawn and cannot be activated.



Expected results:

The text should stop (including the ellipsis) at the left edge of the floating <input> and hittest should find the <input> instead of the text.
This bug is not entirely due to using ellipsis. This bug is mainly caused by using overflow: hidden togther with white-space: nowrap.

A slightly modified test case with two test (the later ellipsis): 

<html>
<head>
<style>
  div {
    overflow: hidden;
    white-space: nowrap;
    background: yellowgreen;
    margin: 20px 0;
  }

 input {
    float: right; margin: 5px;
  }

 .ellipsis {
    text-overflow: ellipsis;
  }
</style>
</head>
<body>

<div>
<input type="text">
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</div>

<div class="ellipsis">
<input type="text">
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</div>

</body>
</html>

In this slightly modified test case, it is possible to interact with the input area that is below the line box in Firefox, Safari, Chrome and Opera. IE10 seems to do the right thing in the test with ellipsis and that is to clip the text at the left edge of the input.
Attachment #740796 - Attachment mime type: text/plain → text/html
Component: Untriaged → Layout: Block and Inline
Product: Firefox → Core
Same in Nightly 2013-04-29-03-09-26-mozilla-central-firefox-23.0a1.en-US.linux-x86_64 and Beta 21.0.
OS: Mac OS X → All
It looks like for some reason we're not reducing the width of the overflow:hidden block in this case...  I wonder why.
Flags: needinfo?(dbaron)
(In reply to Boris Zbarsky (:bz) from comment #4)
> It looks like for some reason we're not reducing the width of the
> overflow:hidden block in this case...  I wonder why.

Boris. I don't think this is a bug unless you inclined to believe that both the test (the one without ellipsis and the one with the ellipse) are wrong. The overflow:hidden is applied to the div. The inline box is just flowing over the floated right input since nothing stops it.

Why should the overflow:hidden block be reduced? It's not like the case where it's a BFC and it's sibling is a float.
Oh, the input is _inside_ the overflow:hidden thing!  I totally missed that.

In that case, I think this bug is invalid; the behavior is correct per spec.
(In reply to Boris Zbarsky (:bz) from comment #6)
> Oh, the input is _inside_ the overflow:hidden thing!  I totally missed that.
> 
> In that case, I think this bug is invalid; the behavior is correct per spec.

Agreed. I will file a bug with Chrome and Safari and indicate that on the CSS mailing list in the thread that resulted in this bug be filed here in the first place.

http://lists.w3.org/Archives/Public/www-style/2013Apr/thread.html#msg540
(In reply to Alan Gresley from comment #7)
> Agreed. I will file a bug with Chrome and Safari and indicate that on the
> CSS mailing list in the thread that resulted in this bug be filed here in
> the first place.

When you file the WebKit bug, could you link to it here?
(In reply to Daniel Trebbien from comment #8)

> When you file the WebKit bug, could you link to it here?

Right here for Safari.. 

https://bugs.webkit.org/show_bug.cgi?id=115462
Based on the last few comments here (particularly comment 6 - comment 7), it sounds like this was not a bug & should be resolved as INVALID. Marking as such.

(Also, canceling later-obsoleted needinfo request from comment 4.)
(Also: FWIW, current Nightly renders both testcases the same as Chrome on my machine, presumably because Chrome fixed this issue on their end.)
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(dbaron)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.