This was broken by http://trac.webkit.org/changeset/39924 which enabled search fields for Windows, but chromium on windows doesn't support this.
Created attachment 28503 [details]
Comment on attachment 28503 [details]
themeWin.css is not in a subdirectory. why should this one be?
>+ * Copyright (c) 2009, Google Inc. All rights reserved.
nit: Copyright (C) 2009 Google Inc. All rights reserved.
>+/* These styles override the default styling for HTML elements as defined in
>+ WebCore/css/themeWin.css. */
>+/* Windows should render input[type="search"] the same as input with no type.
>+ This search thing is an Apple-ism to get mac style search inputs. */
>+ -webkit-box-sizing: content-box;
this rule is not obvious to me. what is this correcting for?
Created attachment 28522 [details]
> themeWin.css is not in a subdirectory. why should this one be?
Qt did so: http://trac.webkit.org/browser/trunk/WebCore/css/qt so I was following that, but you make a really good point about Win which is an early precedent, so I'll move it up.
About that css style question, I was restoring the style to be exactly what it was before the change reference in the ChangeLog. I thought I tried the change without it and the test failed but I was wrong, so I've removed it.
Comment on attachment 28522 [details]
Given that qt uses a subdirectory, it may be a good idea to ask about this on #webkit to see if there is an effort to move these files into subdirectories.
Seems this is an OK temporary fix. But we should really consider fixing to support type=search as something other than type=text.
HTML5 mentions (although doesn't say much) about search:
personally, I'm a huge fan of having a "winnowing search widget" as part of the web.
If we're not going to add support for it. We should convince Apple to pull this CSS out into a themeWinApple.css file.
I agree with Eric. We should implement input type=search, just without the rounded corners as those are there for matching the aqua theme.
Here's the relevant Chrome bug: http://crbug.com/17