Bug 63781 - [text-overflow: ellipsis] WebKit should ignore the ellipsis for the purpose of dispatching mouse events
: [text-overflow: ellipsis] WebKit should ignore the ellipsis for the purpose o...
Status: REOPENED
Product: WebKit
Classification: Unclassified
Component: CSS
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To: David Barr
http://dev.w3.org/csswg/css3-ui/#text...
:
Depends on:
Blocks: 109277
  Show dependency treegraph
 
Reported: 2011-06-30 21:48 PDT by Philippe Wittenbergh
Modified: 2013-08-31 02:13 PDT (History)
19 users (show)

See Also:


Attachments
test case (567 bytes, text/html)
2011-06-30 21:49 PDT, Philippe Wittenbergh
no flags Details
Patch (2.68 KB, patch)
2012-03-27 16:32 PDT, David Barr
no flags Details | Formatted Diff | Diff
Patch (2.86 KB, patch)
2012-03-28 23:05 PDT, David Barr
no flags Details | Formatted Diff | Diff
Patch (2.90 KB, patch)
2012-03-29 17:08 PDT, David Barr
no flags Details | Formatted Diff | Diff
Patch (5.80 KB, patch)
2012-04-01 19:01 PDT, David Barr
no flags Details | Formatted Diff | Diff
Patch (5.92 KB, patch)
2012-04-01 20:55 PDT, David Barr
no flags Details | Formatted Diff | Diff
Patch (5.74 KB, patch)
2012-05-21 18:57 PDT, David Barr
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Wittenbergh 2011-06-30 21:48:30 PDT
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
Comment 1 Philippe Wittenbergh 2011-06-30 21:49:07 PDT
Created attachment 99425 [details]
test case
Comment 2 David Barr 2012-03-27 16:32:25 PDT
Created attachment 134161 [details]
Patch
Comment 3 Build Bot 2012-03-27 19:10:16 PDT
Comment on attachment 134161 [details]
Patch

Attachment 134161 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/12146777
Comment 4 David Barr 2012-03-28 22:38:19 PDT
*** Bug 23678 has been marked as a duplicate of this bug. ***
Comment 5 David Barr 2012-03-28 23:05:47 PDT
Created attachment 134504 [details]
Patch
Comment 6 David Barr 2012-03-29 17:08:01 PDT
Created attachment 134697 [details]
Patch
Comment 7 David Barr 2012-04-01 19:01:18 PDT
Created attachment 135017 [details]
Patch
Comment 8 David Barr 2012-04-01 20:55:58 PDT
Created attachment 135023 [details]
Patch
Comment 9 Darin Adler 2012-04-01 22:50:54 PDT
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.
Comment 10 Mike Lawther 2012-04-02 00:21:34 PDT
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?
Comment 11 David Barr 2012-04-04 16:56:55 PDT
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. <jackalmage@gmail.com> wrote:
> On Sun, Jun 26, 2011 at 3:45 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> On Sun, Jun 26, 2011 at 3:29 PM, Philippe Wittenbergh
>> <ph.wittenbergh@l-c-n.com> 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
Comment 12 David Barr 2012-04-09 18:24:05 PDT
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.
Comment 13 David Barr 2012-04-15 16:42:42 PDT
Any update on this issue? The only adverse feedback so far has been a concern regarding content dependent on the former behavior.
Comment 14 Eric Seidel 2012-05-21 15:30:04 PDT
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.
Comment 15 David Barr 2012-05-21 18:57:33 PDT
Created attachment 143168 [details]
Patch

Addressed Eric's comments regarding setTimeout(). Neatened the test a little.
Comment 16 Eric Seidel 2012-05-28 23:52:52 PDT
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".
Comment 17 Mike Lawther 2012-05-29 16:08:03 PDT
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?
Comment 18 Eric Seidel 2012-05-29 16:10:53 PDT
Comment on attachment 143168 [details]
Patch

It seems fine.
Comment 19 WebKit Review Bot 2012-05-29 16:21:13 PDT
Comment on attachment 143168 [details]
Patch

Clearing flags on attachment: 143168

Committed r118852: <http://trac.webkit.org/changeset/118852>
Comment 20 WebKit Review Bot 2012-05-29 16:21:19 PDT
All reviewed patches have been landed.  Closing bug.
Comment 21 Simon Fraser (smfr) 2012-10-31 12:54:14 PDT
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.
Comment 22 Simon Fraser (smfr) 2012-11-26 11:55:09 PST
David, please address the issues raised in comment 21.
Comment 23 David Barr 2012-11-26 17:55:49 PST
Simon, I was on vacation at the time of comment 21, but I'm back and will look at this bug today.
Comment 24 David Barr 2012-11-26 20:19:20 PST
A quick note that this revert is non-trivial as the interface for nodeAtPoint() has changed since.
Comment 25 Simon Fraser (smfr) 2012-12-20 12:12:32 PST
Another ping.
Comment 26 Ryosuke Niwa 2013-01-25 22:25:55 PST
What's happening with this bug?
Comment 27 Tony Chang 2013-01-28 09:31:23 PST
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.
Comment 28 David Barr 2013-01-28 21:45:49 PST
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.
Comment 29 Andy Estes 2013-02-08 01:18:09 PST
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.
Comment 30 Andy Estes 2013-02-08 02:55:29 PST
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.