Closed Bug 697696 Opened 9 years ago Closed 6 years ago
Highlight issue in amazon's password box
30.75 KB, image/jpeg
23.27 KB, image/jpeg
388.20 KB, text/plain
10.01 KB, text/html
1.86 KB, text/html
Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20100101 Firefox/8.0 In amazon.com in the password box the upper highlight follows the entered characters. Issue can be observed at the log in or when checking out. This is reproducible on Windows Vista, Windows 7 and Windows XP. Reproducible: always Steps to reproduce: 1. Navigate to https://www.amazon.com and select Sign in. 2. Enter your e-mail address. 3. Enter the first characters of your password. Actual results: As the password is written a weird highlight appears at the top of the password box. Expected results: The highlight of the password box should be the same with the highlight of the e-mail box.
Can you reproduce that with a Nightly? With other OS? On GNU/Linux, with Firefox 7, I see no issue. with an old mozilla-central, when I press a key, the text field appearance changes from the native one to the default one. This is actually what you see in your screenshots but only a part of it is updated. I guess there is a bug that make us only repaint only part of the text field. Though, it's weird that Amazon behaves this way and I'm pretty sure it's not what they were expecting. Would be interesting to know why the text field changes to the default one (appearance: none).
Tried with the latest Nightly and I could reproduce the weird highlight only at checking out using Windows XP: Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20111101 Firefox/10.0a1 Issue is reproducible on the latest Nightly for both sign in and checkout on Windows 7: Mozilla/5.0 (Windows NT 6.1; rv:10.0a1) Gecko/20111101 Firefox/10.0a1 Issue is not reproducible on Linux 11.10 or on Mac OS X 10.7.
Issue is reproducible as described in Comment 3 ever since Firefox 3.6.16.
Reproducible also on Firefox 9 beta 1. Mozilla/5.0 (Windows NT 6.0; rv:9.0) Gecko/20100101 Firefox/9.0
Unable to reproduce this with Firefox 9.0b2 on Windows XP. Please confirm if this is still reproducible.
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #6) > Unable to reproduce this with Firefox 9.0b2 on Windows XP. Please confirm if > this is still reproducible. Issue is still reproducible on Firefox 9.0b2. On Windows XP issue is more visible when checking out. I will attach a screen cast made while on Windows Vista.
Sorry for the previous attachment. The screen cast can be seen here: http://dl.dropbox.com/u/50408579/AutoScreenRecorder_06%20Nov.%2021%2016.50.avi
Can you please create a minimized testcase (html snippet) which reproduces this issue and attach it to this bug?
The password box has a style change triggered in a function onkeypress. The style does not apply to the whole input box, just for the length of the inputted text.
Thanks Simona. Over to Dev to see if there is anything more we can do to debug this issue.
I can reproduce the bug but I was expecting the test case to be reduced a bit more than that. Currently, it's quite big and I'm pretty sure the bug is still reproducible with a big part of it being removed.
Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 Issue is also reproducible on Firefox 11 beta 1.
Simona, can you please try to reduce the testcase even further?
In reply to Comment 14: Added reduced test case.
The script is playing with .style.background. When this is set, we don't show the native widget rendering and fallback to the default one. Amazon should be careful and only set it when they actually want a value (IOW, not set it to #FFFFFF when they want to reset the value). Switching this to Evengelism. Thank you for your reduced test case Simona! :) (Note: if this is a regression, we should fix it, if there is a clever way to fix it, we should fix it but I don't think of any and on Linux, no other browser except Firefox use native rendering so I'm a bit limited to see how other browsers behave).
Assignee: nobody → english-us
Component: Layout: Form Controls → English US
Product: Core → Tech Evangelism
QA Contact: layout.form-controls → english-us
Version: Trunk → unspecified
Is Firefox behavior following the spec? (And can I have a link to this so that I can give it to Amazon?)
(In reply to Jean-Yves Perrier [:teoli] from comment #17) > Is Firefox behavior following the spec? (And can I have a link to this so > that I can give it to Amazon?) AFAIK, there is no spec regarding this behavior. So the issue here is that when a background is set on an input element, we revert to the default rendering because we don't know how to draw a native element with a specific background color. Somehowe, Chrome seems to draw the input element with the background color while keeping the native rendering. Safari too. Opera has the same behavior as we do. That is the result of testing on MacOS X. On Linux, as I said, we are the only browser to draw a native element so other browsers don't have to fallback to anything. We could probably try to see if we can draw a native element with a specific background color but I guess that would require all widgets of our tier-1 platforms to allow this in their API (assuming we don't want to have a behavior on some platforms and another on other platforms...). Otherwise, I guess we can also try to hack around it. CCing Roc and Boris who might know may more than I do on that subject.
We could draw Windows text controls with a background just by drawing the background first and then drawing the text control over the top. That would only work for platforms and controls where we know the background can be drawn to fill the padding-box without messing anything up.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #19) > We could draw Windows text controls with a background just by drawing the > background first and then drawing the text control over the top. That would > only work for platforms and controls where we know the background can be > drawn to fill the padding-box without messing anything up. Actually, I was thinking of less hacky ways. For example, with our GTK widget, I can make Gecko draw the background color very easily by adding those lines to moz_gtk_entry_paint: GdkColor colorRed; gdk_color_parse("red", &colorRed); gtk_widget_modify_base(widget, GTK_STATE_NORMAL, &colorRed); If moz_gtk_entry_paint is called with a RGB color (or a special value for default), we should be able to draw a background color with our GTK widget. I wonder if we couldn't do similar things on other platforms (MacOS X and Windows given those are the other tier-1 platforms that have native text fields).
I don't see that Windows can, but I could be wrong.
Jim and Steven, do you think Windows and Cocoa widgets could draw native text fields with a colored background?
(In reply to comment #22) What do you mean by "native text fields"? Cocoa widgets doesn't use *any* native UI widgets. Every single UI widget you see is in fact drawn and controlled by Gecko. So if Gecko can draw a text field with a colored background, so can Cocoa widgets. I believe the same is true of Windows and Linux.
He means the native theme APIs we use to draw the widgets.
> He means the native theme APIs we use to draw the widgets. OK. I don't know the answer and will need to check.
(Following up comment #25) But even if the native theme APIs don't already support drawing a text field with a colored background, they could presumably be changed (without too much trouble) to do so.
Odd bug, in IE the entire text box gains the inset on the first character typed, we seem to be doing it per character. Chrome has custom text inputs with yellow border, but they to seem to add the inset at some point. I wonder what the correct behavior is supposed to be?
Taking the theme lib for a spin for these elements, the background that is rendered is opaque. Although this looks more like a border problem to me. We should be refreshing the entire widget area when a character is typed, doesn't look like we are doing that. If we did, I think we would look correct.
Yes, it seems to be an invalidation bug.
Another odd thing about the behavior on Windows (at least on XP): The entire text box gets the inset when the window loses focus, as long as at least one character has been typed in it. Testing with the non-reduced testcase (attachment 580398 [details]) in FF 11. (Like others, I don't see the problem at all on OS X. I tested on 10.6.8.)
(Following up comment #30) Which is consistent with this being an invalidation bug.
There is indeed an invalidation bug but there is also a bug regarding the text field being rendered as -moz-appearance: none as soon as you work around the invalidation bug (you can zoom for example).
(In reply to comment #22) > Jim and Steven, do you think Windows and Cocoa widgets could draw > native text fields with a colored background? I'm not sure it's still relevant, but I've been able to find out more about how it might be possible to use native theme APIs to use an arbitrary color to draw a widget's background. The current native theme API (as declared in nsITheme.h) doesn't support this. But nsNativeThemeCocoa::DrawWidgetBackground() contains a number of calls to CGContextSetRGBFillColor() and CGContextFillRect(), which might be able to do the job.
It's working for me in Firefox 32.0.3 Mac. I'm closing the bug. Reopen if I have missed something.
Assignee: english-us → nobody
Status: NEW → RESOLVED
Closed: 6 years ago
Component: English US → Desktop
Resolution: --- → WORKSFORME
Whiteboard: [country-us] [needaccount]
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.