Bug 63781 – [text-overflow: ellipsis] WebKit should ignore the ellipsis for the purpose of dispatching mouse events

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: CSS

[Philippe Wittenbergh]

The editor draft recently changed and clarified what should happen when the pointer is over the ellipsis.

[quote]
Ellipsing only affects rendering and must not affect layout nor dispatching of pointer events. 
[/quote]
http://dev.w3.org/csswg/css3-ui/#text-overflow

In the testcase: mousing over the ellipsis (covering the link) should show the :hover color/background, clicking on it should follow the link (as it is 'part of the link').

This is what recent Firefox nightly builds and Opera 11.10+  do.

related discussion thread
http://lists.w3.org/Archives/Public/www-style/2011Jun/0633.html

[Philippe Wittenbergh]

Created attachment 99425 [details]
test case

[David Barr]

Created attachment 134161 [details]
Patch

[Build Bot]

Comment on attachment 134161 [details]
Patch

Attachment 134161 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/12146777

[David Barr]

*** Bug 23678 has been marked as a duplicate of this bug. ***

[David Barr]

Created attachment 134504 [details]
Patch

[David Barr]

Created attachment 134697 [details]
Patch

[David Barr]

Created attachment 135017 [details]
Patch

[David Barr]

Created attachment 135023 [details]
Patch

[Darin Adler]

Comment on attachment 135023 [details]
Patch

It’s good to match the spec, but since this is an 8 year old feature in WebKit we also need to test existing content that uses text-overflow: ellipsis to make it does not depend on this.

[Mike Lawther]

Hi Darin - did you mean that we try and figure out if there are any websites that would be broken by this change? Or were you thinking about Apple properties using WebKit?

What's the usual plan of attack in cases like this?

[David Barr]

The discussion leading up to the spec change (pasted below):
http://lists.w3.org/Archives/Public/www-style/2011Jul/0007.html

On Tue, Jun 28, 2011 at 11:29, Tab Atkins Jr. <[e-mail]> wrote:
> On Sun, Jun 26, 2011 at 3:45 PM, Robert O'Callahan <[e-mail]> wrote:
>> On Sun, Jun 26, 2011 at 3:29 PM, Philippe Wittenbergh
>> <[e-mail]> wrote:
>>> What should happen when the user hovers over the ellipsis when the clipped
>>> string is part of a link ? IOW, does the ellipsis become part of the link or
>>> does the 'box' generated by the ellipsis cover the link (and blocks hit
>>> testing on said link) ?
>>>
>>> Implementations disagree with WebKit and IE (tested IE 8) on one side,
>>> Opera and Firefox nightly on the other.
>>
>> More accurately, Firefox simply ignores the ellipsis for the purpose of
>> dispatching mouse events.
>
> This is the best behavior imo, as the ellipsis is "generated content",
> and generated content generally doesn't participate in mouse events
> beyond the interaction pseudoclasses that CSS defines.

Thanks RoC and Tab, I have updated the spec accordingly to explicitly
note that ellipsing must not affect dispatching of pointer events.

http://dev.w3.org/csswg/css3-ui/#text-overflow

Tantek

[David Barr]

Hi Darin - have you found any specific content that depends on the current behavior?
For the record, the current behavior is that the EllipsisBox is a black-hole for cursor events.

[David Barr]

Any update on this issue? The only adverse feedback so far has been a concern regarding content dependent on the former behavior.

[Eric Seidel (no email)]

Comment on attachment 135023 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=135023&action=review

I don't think you need any of this setTimeout stuff.  This can just be an inline <script>.  Do you need eventSender.fastForward()?

> LayoutTests/fast/css/text-overflow-ellipsis-hit-test.html:30
> +  setTimeout('release()', 0);

Why the setTimeout?

> LayoutTests/fast/css/text-overflow-ellipsis-hit-test.html:33
> +window.onload = runTest;

You don't actualy have to wait for onload here.

[David Barr]

Created attachment 143168 [details]
Patch

Addressed Eric's comments regarding setTimeout(). Neatened the test a little.

[Eric Seidel (no email)]

It appears hyatt added ellipsis boxes in http://trac.webkit.org/changeset/6877, including this hittesting code.

The current behavior seems a bit odd.  That we only seem to hittest the height of the elipses in that example.  I guess after this change we won't hit (thus :hover) anywhere near the elipsis, only on the "li".

[Mike Lawther]

So if the current behaviour is a bit odd, and this patch updates that behaviour to be to spec and matching Firefox and Opera - can we land the patch?

[Eric Seidel (no email)]

Comment on attachment 143168 [details]
Patch

It seems fine.

[WebKit Review Bot]

Comment on attachment 143168 [details]
Patch

Clearing flags on attachment: 143168

Committed r118852: <http://trac.webkit.org/changeset/118852>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Simon Fraser (smfr)]

This fix is incorrect. EllipsisBox is also used when the -webkit-line-clamp property is applied, and in those cases we need hit testing on links to work.

You can see the damage caused by trying to hover over the links in
LayoutTests/fast/overflow/line-clamp.html

Please revert this change and do a correct fix.

[Simon Fraser (smfr)]

David, please address the issues raised in comment 21.

[David Barr]

Simon, I was on vacation at the time of comment 21, but I'm back and will look at this bug today.

[David Barr]

A quick note that this revert is non-trivial as the interface for nodeAtPoint() has changed since.

[Simon Fraser (smfr)]

Another ping.

[Ryosuke Niwa]

What's happening with this bug?

[Tony Chang]

I think this is fine to rollout if someone knows how to resolve the merge conflicts.

FWIW, David hasn't worked at Google since sometime in August of last year.

[David Barr]

Apologies for the delayed response, it was a national holiday weekend and a regional state of emergency - I've been offline for several days. As previously stated, the revert is non-trivial due to subsequent interface changes. My commitment to WebKit is no longer full-time so I have to decide where best to spend my time. I am willing to come back to this bug but I have already spent 3 days full-time chasing down the dependency chain for this revert.

[Andy Estes]

To add to the importance of rolling this out, this change broke content in the Mac App Store, which uses -webkit-line-clamp in the Updates tab. Apple can't ship a new version of WebKit with this in the tree.

[Andy Estes]

I started the rollout process in <https://bugs.webkit.org/show_bug.cgi?id=109277>. I verified that the change fixes the Mac App Store, but I'd like to add a test that verifies the original behavior since it sounds like we don't have one. We can probably just take LayoutTests/fast/overflow/line-clamp.html and have it dispatch a mouse click on one of the links.

Layout experts should take a look to see if what I did makes sense.

[Brent Fulgham]

Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.

[Radar WebKit Bug Importer]

<rdar://problem/96912212>