Position adjustment for composited scrolling is not needed if the layer has box decorations.

Source/web/LinkHighlight.cpp

 /*
  * Copyright (C) 2012 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  *
  * 1.  Redistributions of source code must retain the above copyright
  *     notice, this list of conditions and the following disclaimer.
  * 2.  Redistributions in binary form must reproduce the above copyright
@@ skipping 195 matching lines @@
     ASSERT(quads.size());
     Path newPath;
 
     FloatPoint positionAdjustForCompositedScrolling = IntPoint(m_currentGraphicsLayer->offsetFromLayoutObject());
 
     for (size_t quadIndex = 0; quadIndex < quads.size(); ++quadIndex) {
         FloatQuad absoluteQuad = quads[quadIndex];
 
         // FIXME: this hack should not be necessary. It's a consequence of the fact that composited layers for scrolling are represented
         // differently in Blink than other composited layers.
-        if (paintInvalidationContainer->layer()->needsCompositedScrolling() && m_node->layoutObject() != paintInvalidationContainer)
+        if (!paintInvalidationContainer->layer()->hasBoxDecorationsOrBackground() && paintInvalidationContainer->layer()->needsCompositedScrolling() && m_node->layoutObject() != paintInvalidationContainer)

[chrishtr, 2015/04/27 17:50:03]

Can you explain why it's not needed if there are box decorations?

[pals, 2015/04/28 10:28:24]

I am not very familiar of this code. I thought as the composited layer bounds is
larger than the layoutObject()-> absoluteBoundingBoxRect() because of the box
shadow and the highlight is offset by the size of the box shadow. 

[chrishtr, 2015/04/29 05:11:41]

Ok. I'll need to think about this some more. This whole class is in kind of a
sad state. :( 

[chrishtr, 2015/06/06 05:28:09]

I just tried deleting the adjustment hack in lines 216-217 entirely, and all
layout tests passed. Could you update the CL to remove this code, run the tests,
and test various real situations with scrolled areas to make sure they are
correct?

It may be that this hack was compensating for other compositing code, which is
now fixed. Or it could be that we no longer test this situation.. please check
for possible disabled tests of link highlight.

[pals, 2015/06/15 06:01:04]

Done.

             absoluteQuad.move(-positionAdjustForCompositedScrolling.x(), -positionAdjustForCompositedScrolling.y());
 
         // Transform node quads in target absolute coords to local coordinates in the compositor layer.
         FloatQuad transformedQuad;
         convertTargetSpaceQuadToCompositedLayer(absoluteQuad, m_node->layoutObject(), paintInvalidationContainer, transformedQuad);
 
         // FIXME: for now, we'll only use rounded paths if we have a single node quad. The reason for this is that
         // we may sometimes get a chain of adjacent boxes (e.g. for text nodes) which end up looking like sausage
         // links: these should ideally be merged into a single rect before creating the path, but that's
         // another CL.
@@ skipping 134 matching lines @@
     // Make sure we update geometry on the next callback from WebViewImpl::layout().
     m_geometryNeedsUpdate = true;
 }
 
 WebLayer* LinkHighlight::layer()
 {
     return clipLayer();
 }
 
 } // namespace blink