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
: WebKit
CSS
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
: http://dev.w3.org/csswg/css3-ui/#text...
:
:
: 109277
  Show dependency treegraph
 
Reported: 2011-06-30 21:48 PST by
Modified: 2013-08-31 02:13 PST (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2011-06-30 21:48:30 PST
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 From 2011-06-30 21:49:07 PST -------
Created an attachment (id=99425) [details]
test case
------- Comment #2 From 2012-03-27 16:32:25 PST -------
Created an attachment (id=134161) [details]
Patch
------- Comment #3 From 2012-03-27 19:10:16 PST -------
(From update of attachment 134161 [details])
Attachment 134161 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/12146777
------- Comment #4 From 2012-03-28 22:38:19 PST -------
*** Bug 23678 has been marked as a duplicate of this bug. ***
------- Comment #5 From 2012-03-28 23:05:47 PST -------
Created an attachment (id=134504) [details]
Patch
------- Comment #6 From 2012-03-29 17:08:01 PST -------
Created an attachment (id=134697) [details]
Patch
------- Comment #7 From 2012-04-01 19:01:18 PST -------
Created an attachment (id=135017) [details]
Patch
------- Comment #8 From 2012-04-01 20:55:58 PST -------
Created an attachment (id=135023) [details]
Patch
------- Comment #9 From 2012-04-01 22:50:54 PST -------
(From update of attachment 135023 [details])
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 From 2012-04-02 00:21:34 PST -------
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 From 2012-04-04 16:56:55 PST -------
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 From 2012-04-09 18:24:05 PST -------
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 From 2012-04-15 16:42:42 PST -------
Any update on this issue? The only adverse feedback so far has been a concern regarding content dependent on the former behavior.
------- Comment #14 From 2012-05-21 15:30:04 PST -------
(From update of attachment 135023 [details])
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 From 2012-05-21 18:57:33 PST -------
Created an attachment (id=143168) [details]
Patch

Addressed Eric's comments regarding setTimeout(). Neatened the test a little.
------- Comment #16 From 2012-05-28 23:52:52 PST -------
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 From 2012-05-29 16:08:03 PST -------
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 From 2012-05-29 16:10:53 PST -------
(From update of attachment 143168 [details])
It seems fine.
------- Comment #19 From 2012-05-29 16:21:13 PST -------
(From update of attachment 143168 [details])
Clearing flags on attachment: 143168

Committed r118852: <http://trac.webkit.org/changeset/118852>
------- Comment #20 From 2012-05-29 16:21:19 PST -------
All reviewed patches have been landed.  Closing bug.
------- Comment #21 From 2012-10-31 12:54:14 PST -------
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 From 2012-11-26 11:55:09 PST -------
David, please address the issues raised in comment 21.
------- Comment #23 From 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 From 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 From 2012-12-20 12:12:32 PST -------
Another ping.
------- Comment #26 From 2013-01-25 22:25:55 PST -------
What's happening with this bug?
------- Comment #27 From 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 From 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 From 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 From 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.