Bug 7691 – REGRESSION: imdb.com search button looks wrong because "Submit" is drawn

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Daniele Metilli]

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?

[Daniele Metilli]

Created attachment 6972 [details]
Test case

I have added a test case that shows two example buttons.

[Daniele Metilli]

Created attachment 6979 [details]
Better reduction

[Gustaaf Groenendaal (MysteryQuest)]

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.

[Darin Adler]

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.

[Alice Liu]

<rdar://problem/4483867>

[Tim Omernick]

I'm taking this one.  I've got a fix and a layout test.  Will submit for review soon.

[Tim Omernick]

Created attachment 7264 [details]
Patch w/ fix and layout test

[Darin Adler]

Comment on attachment 7264 [details]
Patch w/ fix and layout test

r=me

[Tim Omernick]

Fix landed to TOT, r13464.

[Daniele Metilli]

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).

[Darin Adler]

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!

[Darin Adler]

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.

[Darin Adler]

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.

[Darin Adler]

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.

[Daniele Metilli]

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 :)

[Darin Adler]

Follow-up bug is in bug 8683.