Bug 127101 – [CSS Regions] Fix selection and hover effect of content in region with overflow:hidden

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Mihai Maerean]

Created attachment 221368 [details]
sample html file

The content that's flowed into a region with overflow:hidden can't be selected and the hover css class is not activated.

[Mihai Maerean]

Created attachment 221370 [details]
sample html file

[Mihai Maerean]

Created attachment 222331 [details]
patch

[Mihnea Ovidenie]

I am not a big fan of the proposed solution. The function isHitCandidate was added for https://bugs.webkit.org/show_bug.cgi?id=24686 in a different context. This function is run after the hit testing was done for a layer, but in the case of RenderNamedFlowFragment, we know upfront that is not a hit candidate. I would like you to investigate other options that would skip calling hit testing methods for this case before settling for this solution (or if you did investigate other options, i think it is worth mentioning here).

[Mihai Maerean]

(In reply to comment #3)
> I am not a big fan of the proposed solution. The function isHitCandidate was added for https://bugs.webkit.org/show_bug.cgi?id=24686 in a different context. This function is run after the hit testing was done for a layer, but in the case of RenderNamedFlowFragment, we know upfront that is not a hit candidate. I would like you to investigate other options that would skip calling hit testing methods for this case before settling for this solution (or if you did investigate other options, i think it is worth mentioning here).

This is how the tree looks like for the layout test:
Named flows
  Named flow 'flow'
    layer 0x7fd410e582c0 at (0,0) size 991x38
      RenderNamedFlowThread 0x7fd410e6b5a0 at (0,0) size 991x38
        RenderBlock 0x7fd410e4eb50 {DIV} at (10,10) size 971x18 class="content" (layout overflow 0,0 971x18) (visual overflow -10,-10 991x38)
          RenderText 0x7fd410e4ec50 {#text} at (0,0) size 60x18
            text run at (0,0) width 60: "hover me"

The proposed fix for this bug is called from the last if(isSelfPaintingLayer()) instruction in RenderLayer::hitTestLayer.
Moving the check more up front would make it less intuitive (than returning false when asked if it's a hit candidate) or just incorrect because the code wouldn't hit the contents of the region any more.
Also, isHitCandidate is called in 4 different places so RenderNamedFlowThread will be skipped in all those situations too.

[Mihnea Ovidenie]

Comment on attachment 222331 [details]
patch

r=me

[Mihai Maerean]

Created attachment 222973 [details]
patch for landing

[WebKit Commit Bot]

Comment on attachment 222973 [details]
patch for landing

Rejecting attachment 222973 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.appspot.com', '--bot-id=webkit-cq-03', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 222973, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
ubmit
    return self.open(self.click(*args, **kwds))
  File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_mechanize.py", line 203, in open
    return self._mech_open(url, data, timeout=timeout)
  File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_mechanize.py", line 255, in _mech_open
    raise response
webkitpy.thirdparty.autoinstalled.mechanize._response.httperror_seek_wrapper: HTTP Error 500: Internal Server Error

Full output: http://webkit-queues.appspot.com/results/4876789134393344

[Mihnea Ovidenie]

Comment on attachment 222973 [details]
patch for landing

Retrying...

[WebKit Commit Bot]

Comment on attachment 222973 [details]
patch for landing

Clearing flags on attachment: 222973

Committed r163302: <http://trac.webkit.org/changeset/163302>