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
Created attachment 99425 [details] test case
Created attachment 134161 [details] Patch
Comment on attachment 134161 [details] Patch Attachment 134161 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/12146777
*** Bug 23678 has been marked as a duplicate of this bug. ***
Created attachment 134504 [details] Patch
Created attachment 134697 [details] Patch
Created attachment 135017 [details] Patch
Created attachment 135023 [details] Patch
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.
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?
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
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.
Any update on this issue? The only adverse feedback so far has been a concern regarding content dependent on the former behavior.
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.
Created attachment 143168 [details] Patch Addressed Eric's comments regarding setTimeout(). Neatened the test a little.
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".
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 on attachment 143168 [details] Patch It seems fine.
Comment on attachment 143168 [details] Patch Clearing flags on attachment: 143168 Committed r118852: <http://trac.webkit.org/changeset/118852>
All reviewed patches have been landed. Closing bug.
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.
David, please address the issues raised in comment 21.
Simon, I was on vacation at the time of comment 21, but I'm back and will look at this bug today.
A quick note that this revert is non-trivial as the interface for nodeAtPoint() has changed since.
Another ping.
What's happening with this bug?
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.
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.
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.
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.
Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.
<rdar://problem/96912212>