The yellow button in the "Search the IMDb" section on the left does not render correctly. This is the problem: - The background image already has a text. - WebKit tries to add another text on top of it (the "value" attribute or, if this is empty, "Submit"). Maybe a check should be made to ensure that the Aqua button is not used when the CSS class of the button has a "background" value?
Created attachment 6972 [details] Test case I have added a test case that shows two example buttons.
Created attachment 6979 [details] Better reduction
Confirmed with release 13202 and 13244, setting severity to normal in stead of minor, since some pages on some sites could be unaccesable. Also set priority to P1 since this is a regression bug and added to the summary.
The difference from Firefox seems to be that we display "Submit" rather than an empty string. Perhaps the fix is to supply "Submit" only when there is no value specified. If so, this can be fixed by simply changing HTMLInputElementImpl::valueWithDefault to supply the default only if isNull rather than isEmpty. The key would be finding test cases.
<rdar://problem/4483867>
I'm taking this one. I've got a fix and a layout test. Will submit for review soon.
Created attachment 7264 [details] Patch w/ fix and layout test
Comment on attachment 7264 [details] Patch w/ fix and layout test r=me
Fix landed to TOT, r13464.
I'm reopening this bug since it still happens in this case: 1 - Go to http://imdb.com/title/tt0120907/ 2 - Click on "David Cronenberg". 3 - Go back using Safari's back button. 4 - The search button is rendered incorrectly. This happens in TOT (r14126).
Please don't reopen a bug when the original site now works fine and there's a test case that also still works. A new bug report is much better for cases like that!
The new bug doesn't have to do with the button rendering itself, but rather with the way form data is saved and restored. Apparently a null is saved, but an empty string is restored, or vice versa.
Another reason to not reuse the original bug report is that this now shows up in the list of bugs with fixes to be landed.
It would be best to change this bug back to FIXED and open a new bug about the fact that this happens after going back. The fix will be to change HTMLInputElement::state and HTMLInputElement::restoreState so they can distinguish a state of null string from a state of empty string, which should be straightforward.
Sorry about that, I thought that since it was so strictly related (same site, same button) it could be that the fix was incomplete. I didn't imagine that it was a completely different problem. I will now do exactly as you said and report a new bug. Thanks for your help :)
Follow-up bug is in bug 8683.