<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>75860</bug_id>
          
          <creation_ts>2012-01-09 08:32:53 -0800</creation_ts>
          <short_desc>[Chromium Mac] no background is drawn for input elements</short_desc>
          <delta_ts>2012-01-09 17:08:11 -0800</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>Layout and Rendering</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>Mac</rep_platform>
          <op_sys>OS X 10.6</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc>data:text/html;charset=utf-8,&lt;input style=&quot;background-color:blue&quot;/&gt;</bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P1</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Cary Clark">caryclark</reporter>
          <assigned_to name="Beth Dakin">bdakin</assigned_to>
          <cc>abarth</cc>
    
    <cc>avi</cc>
    
    <cc>dglazkov</cc>
    
    <cc>dslomov</cc>
    
    <cc>mark</cc>
    
    <cc>rsesek</cc>
    
    <cc>sullivan</cc>
    
    <cc>thakis</cc>
    
    <cc>webkit.review.bot</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>532211</commentid>
    <comment_count>0</comment_count>
    <who name="Cary Clark">caryclark</who>
    <bug_when>2012-01-09 08:32:53 -0800</bug_when>
    <thetext>This change: https://bugs.webkit.org/show_bug.cgi?id=75654
breaks &lt;input&gt; elements on Chromium on Mac (all versions).
It is broken when using either CoreGraphics or Skia as the graphics engine.

The break appears to be connected to these lines in RenderThemeMac.mm (2111)

        // Setting a clear background on the cell is necessary for CSS-styled backgrounds
        // to show through. Ideally, there would be a better way to do this.
        [m_textField.get() setDrawsBackground:YES];
        [m_textField.get() setBackgroundColor:[NSColor clearColor]];

Locally changing these to:

        [m_textField.get() setDrawsBackground:NO];
        [m_textField.get() setBackgroundColor:[NSColor whiteColor]];

while incorrect, causes &lt;input&gt; to work (albeit hard-coded to a background of white)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532223</commentid>
    <comment_count>1</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2012-01-09 08:52:35 -0800</bug_when>
    <thetext>I checked, Safari port is not affected. Chromium bug here: code.google.com/p/chromium/issues/detail?id=109567</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532244</commentid>
    <comment_count>2</comment_count>
    <who name="Avi Drissman">avi</who>
    <bug_when>2012-01-09 09:35:41 -0800</bug_when>
    <thetext>Cary: I agree with your analysis. I&apos;m curious about the comment re &quot;CSS-styled backgrounds&quot;, as this implies a different painting model than us. We&apos;re just redrawing the control; does Safari do a full back-to-front repaint?

Dmitri: &quot;Safari port is not affected&quot;: Does the Safari port use RenderThemeMac, or RenderThemeSafari? (BTW, when is RenderThemeSafari used?)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532246</commentid>
    <comment_count>3</comment_count>
    <who name="Avi Drissman">avi</who>
    <bug_when>2012-01-09 09:45:51 -0800</bug_when>
    <thetext>We always have the short-term option of overriding paintTextField in RenderThemeChromiumMac and doing it our way if we can&apos;t figure out what&apos;s going on.

BTW, WKDrawBezeledTextFieldCell is just a wrapper over _NSDrawCarbonThemeBezel, so it&apos;s not crystal clear what the old behavior was.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532247</commentid>
    <comment_count>4</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2012-01-09 09:50:55 -0800</bug_when>
    <thetext>(In reply to comment #2)
&gt; Cary: I agree with your analysis. I&apos;m curious about the comment re &quot;CSS-styled backgrounds&quot;, as this implies a different painting model than us. We&apos;re just redrawing the control; does Safari do a full back-to-front repaint?
&gt; 
&gt; Dmitri: &quot;Safari port is not affected&quot;: Does the Safari port use RenderThemeMac, or RenderThemeSafari? (BTW, when is RenderThemeSafari used?)

RenderThemeMac -&gt; Safari Mac
RenderThemeSafari -&gt; Safari Windows</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532254</commentid>
    <comment_count>5</comment_count>
    <who name="Nico Weber">thakis</who>
    <bug_when>2012-01-09 10:00:54 -0800</bug_when>
    <thetext>Bug 75742 was caused by this revision as well.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532262</commentid>
    <comment_count>6</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2012-01-09 10:10:51 -0800</bug_when>
    <thetext>(In reply to comment #3)
&gt; We always have the short-term option of overriding paintTextField in RenderThemeChromiumMac and doing it our way if we can&apos;t figure out what&apos;s going on.
&gt; 
&gt; BTW, WKDrawBezeledTextFieldCell is just a wrapper over _NSDrawCarbonThemeBezel, so it&apos;s not crystal clear what the old behavior was.

+1 on a quick and dirty fix for now.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532277</commentid>
    <comment_count>7</comment_count>
    <who name="Nico Weber">thakis</who>
    <bug_when>2012-01-09 10:26:47 -0800</bug_when>
    <thetext>I can&apos;t repro this when I build on Lion, with the 10.6 SDK. So this problem might be triggered by us using the 10.5 sdk (which we have to, since we ship on 10.5).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532289</commentid>
    <comment_count>8</comment_count>
    <who name="Avi Drissman">avi</who>
    <bug_when>2012-01-09 10:32:45 -0800</bug_when>
    <thetext>(In reply to comment #7)
&gt; So this problem might be triggered by us using the 10.5 sdk (which we have to, since we ship on 10.5).

Oh joy, one of those &quot;let&apos;s change the behavior of an API call depending on what version you linked&quot;. It&apos;s reproducible for me with the 10.5 SDK.

I&apos;m OK with overriding as a QND fix, but the question is now what to override it with. It would suck if we had to use the SPI again. I&apos;m playing around with explicitly filling the background.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532319</commentid>
    <comment_count>9</comment_count>
      <attachid>121690</attachid>
    <who name="Avi Drissman">avi</who>
    <bug_when>2012-01-09 10:55:27 -0800</bug_when>
    <thetext>Created attachment 121690
patch

Sigh. This does work, and I&apos;d be OK with it for a quick-n-dirty fix. In the long run, what to do? If the official Cocoa code works with the 10.6 SDK, do we just let this go until that&apos;s our minimum?

(BTW, this patch is off my Git checkout with some massaging. I hope the CQ can cope.)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532325</commentid>
    <comment_count>10</comment_count>
    <who name="WebKit Review Bot">webkit.review.bot</who>
    <bug_when>2012-01-09 11:01:33 -0800</bug_when>
    <thetext>Attachment 121690 did not pass style-queue:

Failed to run &quot;[&apos;Tools/Scripts/check-webkit-style&apos;, &apos;--diff-files&apos;]&quot; exit_code: 1

Total errors found: 0 in 0 files


If any of these errors are false positives, please file a bug against check-webkit-style.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532326</commentid>
    <comment_count>11</comment_count>
      <attachid>121690</attachid>
    <who name="Nico Weber">thakis</who>
    <bug_when>2012-01-09 11:02:56 -0800</bug_when>
    <thetext>Comment on attachment 121690
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=121690&amp;action=review

Looks fine. Can you check if this fixes fast/forms/input-disabled-color.html (the bug I linked to above) too?

&gt; Source/WebCore/rendering/RenderThemeChromiumMac.h:36
&gt; +    virtual bool paintTextField(RenderObject*, const PaintInfo&amp;, const IntRect&amp;);

OVERRIDE? :-)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532358</commentid>
    <comment_count>12</comment_count>
    <who name="Nico Weber">thakis</who>
    <bug_when>2012-01-09 11:26:10 -0800</bug_when>
    <thetext>*** Bug 75742 has been marked as a duplicate of this bug. ***</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532361</commentid>
    <comment_count>13</comment_count>
    <who name="Avi Drissman">avi</who>
    <bug_when>2012-01-09 11:28:23 -0800</bug_when>
    <thetext>(In reply to comment #11)
&gt; Looks fine. Can you check if this fixes fast/forms/input-disabled-color.html (the bug I linked to above) too?

That was my test to see if it was a functional patch. So yes.

&gt; OVERRIDE? :-)

I don&apos;t consider this code as Chromium code for the purposes of the style guide.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532381</commentid>
    <comment_count>14</comment_count>
    <who name="Avi Drissman">avi</who>
    <bug_when>2012-01-09 11:45:28 -0800</bug_when>
    <thetext>We might as well leave this fix in until we drop 10.5 support. Poking around the guts of NSTextFieldCell doesn&apos;t sound very fun, and since this is apparently fixed with the 10.6 SDK it can join the cruft-we-keep-around-for-Leopard party.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532473</commentid>
    <comment_count>15</comment_count>
      <attachid>121690</attachid>
    <who name="WebKit Review Bot">webkit.review.bot</who>
    <bug_when>2012-01-09 13:21:57 -0800</bug_when>
    <thetext>Comment on attachment 121690
patch

Rejecting attachment 121690 from commit-queue.

Failed to run &quot;[&apos;/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch&apos;, &apos;--status-host=queues.webkit.org&apos;, &apos;-...&quot; exit_code: 2

Last 500 characters of output:
t/git/webkit-commit-queue/Source/WebKit/chromium/v8 --revision 10314 --non-interactive --force --accept theirs-conflict --ignore-externals&apos; in &apos;/mnt/git/webkit-commit-queue/Source/WebKit/chromium&apos;
46&gt;At revision 10314.

________ running &apos;/usr/bin/python tools/clang/scripts/update.py --mac-only&apos; in &apos;/mnt/git/webkit-commit-queue/Source/WebKit/chromium&apos;

________ running &apos;/usr/bin/python gyp_webkit&apos; in &apos;/mnt/git/webkit-commit-queue/Source/WebKit/chromium&apos;
Updating webkit projects from gyp files...

Full output: http://queues.webkit.org/results/11184655</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532476</commentid>
    <comment_count>16</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2012-01-09 13:23:38 -0800</bug_when>
    <thetext>Found no modified ChangeLogs, cannot create a commit message.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532478</commentid>
    <comment_count>17</comment_count>
      <attachid>121690</attachid>
    <who name="Adam Barth">abarth</who>
    <bug_when>2012-01-09 13:24:32 -0800</bug_when>
    <thetext>Comment on attachment 121690
patch

Strange.  The patch does seem to have a ChangeLog.  The style-queue has similar problems.  Maybe we should land this manually.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532480</commentid>
    <comment_count>18</comment_count>
    <who name="Avi Drissman">avi</who>
    <bug_when>2012-01-09 13:25:16 -0800</bug_when>
    <thetext>(In reply to comment #17)
&gt; (From update of attachment 121690 [details])
&gt; Strange.  The patch does seem to have a ChangeLog.  The style-queue has similar problems.  Maybe we should land this manually.

This was a diff from my git repro. Let me recreate it in a real svn repo and repost.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532553</commentid>
    <comment_count>19</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2012-01-09 15:13:06 -0800</bug_when>
    <thetext>Committed r104494: &lt;http://trac.webkit.org/changeset/104494&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532659</commentid>
    <comment_count>20</comment_count>
    <who name="Avi Drissman">avi</who>
    <bug_when>2012-01-09 16:52:35 -0800</bug_when>
    <thetext>(In reply to comment #19)
&gt; Committed r104494: &lt;http://trac.webkit.org/changeset/104494&gt;

Thanks! I had to go, and my WebKit checkout was so old that svn up was still cranking after half an hour.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>532675</commentid>
    <comment_count>21</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2012-01-09 17:08:11 -0800</bug_when>
    <thetext>No problem.  The issue was just that the patch was incorrectly based.  We use -p1 but the patch was using -p0.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>121690</attachid>
            <date>2012-01-09 10:55:27 -0800</date>
            <delta_ts>2012-01-09 13:24:32 -0800</delta_ts>
            <desc>patch</desc>
            <filename>x</filename>
            <type>text/plain</type>
            <size>2612</size>
            <attacher name="Avi Drissman">avi</attacher>
            
              <data encoding="base64">LS0tIFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZworKysgU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9n
CkBAIC0xLDMgKzEsMTcgQEAKKzIwMTItMDEtMDkgIEF2aSBEcmlzc21hbiAgPGF2aUBjaHJvbWl1
bS5vcmc+CisKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lk
PTc1ODYwCisgICAgICAgIFtDaHJvbWl1bSBNYWNdIG5vIGJhY2tncm91bmQgaXMgZHJhd24gZm9y
IGlucHV0IGVsZW1lbnRzCisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisK
KyAgICAgICAgUmV2ZXJ0cyByMTA0MjQwIGZvciBDaHJvbWl1bS4gVW5mb3J0dW5hdGVseSB0aGUg
Y29kZSB0aGF0IHVzZXMgQ29jb2EKKyAgICAgICAgQVBJIG1pc2JlaGF2ZXMgd2hlbiBidWlsdCB3
aXRoIHRoZSAxMC41IFNESywgc28gd2UgdXNlIFNQSS4gRm9yIG5vdy4KKworICAgICAgICAqIHJl
bmRlcmluZy9SZW5kZXJUaGVtZUNocm9taXVtTWFjLmg6CisgICAgICAgICogcmVuZGVyaW5nL1Jl
bmRlclRoZW1lQ2hyb21pdW1NYWMubW06CisgICAgICAgIChXZWJDb3JlOjpSZW5kZXJUaGVtZUNo
cm9taXVtTWFjOjpwYWludFRleHRGaWVsZCk6CisKIDIwMTItMDEtMDcgIENocmlzIE1hcnJpbiAg
PGNtYXJyaW5AYXBwbGUuY29tPgogCiAgICAgICAgIEZpeGVkIEFOR0xFIGJ1aWxkIGZvciBHTlUg
YW5kIFFUIGJyb2tlbiBpbiBodHRwczovL3RyYWMud2Via2l0Lm9yZy9jaGFuZ2VzZXQvMTA0MzYz
Ci0tLSBTb3VyY2UvV2ViQ29yZS9yZW5kZXJpbmcvUmVuZGVyVGhlbWVDaHJvbWl1bU1hYy5oCisr
KyBTb3VyY2UvV2ViQ29yZS9yZW5kZXJpbmcvUmVuZGVyVGhlbWVDaHJvbWl1bU1hYy5oCkBAIC0z
Myw2ICszMyw3IEBAIHB1YmxpYzoKICAgICBzdGF0aWMgUGFzc1JlZlB0cjxSZW5kZXJUaGVtZT4g
Y3JlYXRlKCk7CiAKIHByb3RlY3RlZDoKKyAgICB2aXJ0dWFsIGJvb2wgcGFpbnRUZXh0RmllbGQo
UmVuZGVyT2JqZWN0KiwgY29uc3QgUGFpbnRJbmZvJiwgY29uc3QgSW50UmVjdCYpOwogI2lmIEVO
QUJMRShWSURFTykKICAgICB2aXJ0dWFsIHZvaWQgYWRqdXN0TWVkaWFTbGlkZXJUaHVtYlNpemUo
UmVuZGVyU3R5bGUqKSBjb25zdDsKICAgICB2aXJ0dWFsIGJvb2wgcGFpbnRNZWRpYVBsYXlCdXR0
b24oUmVuZGVyT2JqZWN0KiwgY29uc3QgUGFpbnRJbmZvJiwgY29uc3QgSW50UmVjdCYpOwotLS0g
U291cmNlL1dlYkNvcmUvcmVuZGVyaW5nL1JlbmRlclRoZW1lQ2hyb21pdW1NYWMubW0KKysrIFNv
dXJjZS9XZWJDb3JlL3JlbmRlcmluZy9SZW5kZXJUaGVtZUNocm9taXVtTWFjLm1tCkBAIC0xOSwx
MCArMTksMTIgQEAKICAqLwogCiAjaW1wb3J0ICJjb25maWcuaCIKKyNpbXBvcnQgIkxvY2FsQ3Vy
cmVudEdyYXBoaWNzQ29udGV4dC5oIgogI2ltcG9ydCAiUmVuZGVyVGhlbWVDaHJvbWl1bU1hYy5o
IgogI2ltcG9ydCAiUGFpbnRJbmZvLmgiCiAjaW1wb3J0ICJQbGF0Zm9ybVN1cHBvcnQuaCIKICNp
bXBvcnQgIlJlbmRlck1lZGlhQ29udHJvbHNDaHJvbWl1bS5oIgorI2ltcG9ydCAiV2ViQ29yZVN5
c3RlbUludGVyZmFjZS5oIgogI2ltcG9ydCAiVXNlckFnZW50U3R5bGVTaGVldHMuaCIKICNpbXBv
cnQgPENhcmJvbi9DYXJib24uaD4KICNpbXBvcnQgPENvY29hL0NvY29hLmg+CkBAIC0xMjUsNiAr
MTI3LDIzIEBAIGJvb2wgUmVuZGVyVGhlbWVDaHJvbWl1bU1hYzo6c2hvdWxkU2hvd1BsYWNlaG9s
ZGVyV2hlbkZvY3VzZWQoKSBjb25zdAogICAgIHJldHVybiB0cnVlOwogfQogCitib29sIFJlbmRl
clRoZW1lQ2hyb21pdW1NYWM6OnBhaW50VGV4dEZpZWxkKFJlbmRlck9iamVjdCogbywgY29uc3Qg
UGFpbnRJbmZvJiBwYWludEluZm8sIGNvbnN0IEludFJlY3QmIHIpCit7CisgICAgLy8gVXNpbmcg
dGhlIENvY29hIGNvZGUgdG8gcGFpbnQgdGhlIHRleHQgZmllbGQgYXMgUmVuZGVyVGhlbWVNYWMg
ZG9lcyBydW5zCisgICAgLy8gaW50byBhIGJ1ZyB3aGVuIGJ1aWxkaW5nIGFnYWluc3QgdGhlIDEw
LjUgU0RLLCBzbyB3ZSBhcmUgZm9yY2VkIGhlcmUgdG8KKyAgICAvLyB1c2UgdGhlIFNQSS4gVGhp
cyBvdmVycmlkZSBvZiBwYWludFRleHRGaWVsZCBzaG91bGQgYmUgYWJsZSB0byBiZSByZW1vdmVk
CisgICAgLy8gd2hlbiAxMC42IGlzIHRoZSBtaW5pbXVtIHJlcXVpcmVkIHN5c3RlbSBhbmQgQ2hy
b21pdW0gaXMgYnVpbHQgYWdhaW5zdAorICAgIC8vIHRoZSAxMC42IFNESy4KKyAgICAvLworICAg
IC8vIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD03NTg2MAorICAgIC8v
IGh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9jaHJvbWl1bS9pc3N1ZXMvZGV0YWlsP2lkPTEwOTU2
NworCisgICAgTG9jYWxDdXJyZW50R3JhcGhpY3NDb250ZXh0IGxvY2FsQ29udGV4dChwYWludElu
Zm8uY29udGV4dCk7CisgICAgd2tEcmF3QmV6ZWxlZFRleHRGaWVsZENlbGwociwgaXNFbmFibGVk
KG8pICYmICFpc1JlYWRPbmx5Q29udHJvbChvKSk7CisKKyAgICByZXR1cm4gZmFsc2U7Cit9CisK
ICNpZiBFTkFCTEUoVklERU8pCiAKIHZvaWQgUmVuZGVyVGhlbWVDaHJvbWl1bU1hYzo6YWRqdXN0
TWVkaWFTbGlkZXJUaHVtYlNpemUoUmVuZGVyU3R5bGUqIHN0eWxlKSBjb25zdAo=
</data>
<flag name="review"
          id="122262"
          type_id="1"
          status="+"
          setter="dglazkov"
    />
    <flag name="commit-queue"
          id="122263"
          type_id="3"
          status="-"
          setter="webkit.review.bot"
    />
          </attachment>
      

    </bug>

</bugzilla>