Bug 63781

Summary:

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

Product:

WebKit

Reporter:

Philippe Wittenbergh <phiw2>

Component:

CSS

Assignee:

David Barr <davidbarr>

Status:

RESOLVED CONFIGURATION CHANGED

Severity:

Normal

CC:

aestes, bdakin, bfulgham, darin, davidbarr, eric, hyatt, igor.oliveira, jchaffraix, kennyluck, mikelawther, mitz, playmobil, rniwa, shanestephens, simon.fraser, syoichi, tonikitoo, tony, webkit-bug-importer, webkit.review.bot

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

URL:

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

Bug Depends on:

Bug Blocks:

233770, 109277

Attachments:

Description	Flags
test case	none
Patch	none
Patch	none
Patch	none
Patch	none
Patch	none
Patch	none

Philippe Wittenbergh

Reported 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

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
Show Obsolete (5) View All Add attachment proposed patch, testcase, etc.

Philippe Wittenbergh

Comment 1 2011-06-30 21:49:07 PDT

Created attachment 99425 [details] test case

David Barr

Comment 2 2012-03-27 16:32:25 PDT

Created attachment 134161 [details] Patch

Build Bot

Comment 3 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

David Barr

Comment 4 2012-03-28 22:38:19 PDT

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

David Barr

Comment 5 2012-03-28 23:05:47 PDT

Created attachment 134504 [details] Patch

David Barr

Comment 6 2012-03-29 17:08:01 PDT

Created attachment 134697 [details] Patch

David Barr

Comment 7 2012-04-01 19:01:18 PDT

Created attachment 135017 [details] Patch

David Barr

Comment 8 2012-04-01 20:55:58 PDT

Created attachment 135023 [details] Patch

Darin Adler

Comment 9 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.

Mike Lawther

Comment 10 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?

David Barr

Comment 11 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

David Barr

Comment 12 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.

David Barr

Comment 13 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.

Eric Seidel (no email)

Comment 14 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.

David Barr

Comment 15 2012-05-21 18:57:33 PDT

Created attachment 143168 [details] Patch Addressed Eric's comments regarding setTimeout(). Neatened the test a little.

Eric Seidel (no email)

Comment 16 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".

Mike Lawther

Comment 17 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?

Eric Seidel (no email)

Comment 18 2012-05-29 16:10:53 PDT

Comment on attachment 143168 [details] Patch It seems fine.

WebKit Review Bot

Comment 19 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>

WebKit Review Bot

Comment 20 2012-05-29 16:21:19 PDT

All reviewed patches have been landed. Closing bug.

Simon Fraser (smfr)

Comment 21 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.

Simon Fraser (smfr)

Comment 22 2012-11-26 11:55:09 PST

David, please address the issues raised in comment 21.

David Barr

Comment 23 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.

David Barr

Comment 24 2012-11-26 20:19:20 PST

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

Simon Fraser (smfr)

Comment 25 2012-12-20 12:12:32 PST

Another ping.

Ryosuke Niwa

Comment 26 2013-01-25 22:25:55 PST

What's happening with this bug?

Tony Chang

Comment 27 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.

David Barr

Comment 28 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.

Andy Estes

Comment 29 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.

Andy Estes

Comment 30 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.

Brent Fulgham

Comment 31 2022-07-12 14:55:01 PDT

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

Comment 32 2022-07-12 14:56:06 PDT

<rdar://problem/96912212>

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