From http://code.google.com/p/chromium/issues/detail?id=48278
Created attachment 76862 [details] Patch
(Note: I am not a WebKit reviewer. You also need an r+ from a real reviewer.) LGTM
I believe senorblanco wrote this code. I don't quite understand why the patch works (it looks like setFillColor() still sets the gradient to NULL), but since the layout test passes and agl says it's ok, this is my fault and not the patch's :-)
(In reply to comment #3) > since the layout test passes Yes, I largely defer to the reality of layout tests when evaluating correctness!
So could any kind reviewer give r+ to this ? (In reply to comment #3) > I don't quite understand why the patch works (it looks like setFillColor() still sets the gradient to NULL), but since the layout test passes and agl says it's ok, this is my fault and not the patch's :-) What wrong here is, in my understanding, not the fill code but the gradient code. The gradient rendering refers color value which is set by setFillColor(), and uses the alpha component of that color to make things transparent. So setFillColor() and setFillGradient() weren't mutually exclusive, regardless they should be. Actually there are some confusions around how the transparency of each pixel is determined: we have State::m_alpha and State::m_fillColor on the chromium land, and have layers, blitters and shaders in the Skia land...
Comment on attachment 76862 [details] Patch OK
Committed r74386: <http://trac.webkit.org/changeset/74386>
(In reply to comment #6) > (From update of attachment 76862 [details]) > OK Landed. thank you for your r+!
http://trac.webkit.org/changeset/74386 might have broken Qt Linux Release The following tests are not passing: fast/gradients/gradient-after-transparent-border.html