697696 - Highlight issue in amazon's password box

Status: RESOLVED WORKSFORME

(Web Compatibility :: Desktop, defect)

Description

[Simona Badau, Desktop QA]

Attachment: Screenshot of the issue when checking out

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.

Comment 1

[Simona Badau, Desktop QA]

Attachment: Screenshot of the issue at Sign in

Comment 2

[Mounir Lamouri (:mounir)]

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

Comment 3

[Simona Badau, Desktop QA]

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.

Comment 4

[Simona Badau, Desktop QA]

Issue is reproducible as described in Comment 3 ever since Firefox 3.6.16.

Comment 5

[Simona Badau, Desktop QA]

Reproducible also on Firefox 9 beta 1.
Mozilla/5.0 (Windows NT 6.0; rv:9.0) Gecko/20100101 Firefox/9.0

Comment 6

[u279076]

Unable to reproduce this with Firefox 9.0b2 on Windows XP. Please confirm if this is still reproducible.

Comment 7

[Simona Badau, Desktop QA]

Attachment: Video

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

Comment 8

[Simona Badau, Desktop QA]

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

Comment 9

[u279076]

Can you please create a minimized testcase (html snippet) which reproduces this issue and attach it to this bug?

Comment 10

[Simona Badau, Desktop QA]

Attachment: Testcase

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.

Comment 11

[u279076]

Thanks Simona. Over to Dev to see if there is anything more we can do to debug this issue.

Comment 12

[Mounir Lamouri (:mounir)]

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.

Comment 13

[Simona Badau, Desktop QA]

Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0

Issue is also reproducible on Firefox 11 beta 1.

Comment 14

[u279076]

Simona, can you please try to reduce the testcase even further?

Comment 15

[Simona Badau, Desktop QA]

Attachment: Reduced testcase

In reply to Comment 14:
Added reduced test case.

Comment 16

[Mounir Lamouri (:mounir)]

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

Comment 17

[Jean-Yves Perrier [:teoli]]

Is Firefox behavior following the spec? (And can I have a link to this so that I can give it to Amazon?)

Comment 18

[Mounir Lamouri (:mounir)]

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

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 20

[Mounir Lamouri (:mounir)]

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

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't see that Windows can, but I could be wrong.

Comment 22

[Mounir Lamouri (:mounir)]

Jim and Steven, do you think Windows and Cocoa widgets could draw native text fields with a colored background?

Comment 23

[Steven Michaud [:smichaud] (Retired)]

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

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

He means the native theme APIs we use to draw the widgets.

Comment 25

[Steven Michaud [:smichaud] (Retired)]

> He means the native theme APIs we use to draw the widgets.

OK.  I don't know the answer and will need to check.

Comment 26

[Steven Michaud [:smichaud] (Retired)]

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

Comment 27

[Jim Mathies [:jimm]]

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?

Comment 28

[Jim Mathies [:jimm]]

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.

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, it seems to be an invalidation bug.

Comment 30

[Steven Michaud [:smichaud] (Retired)]

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

Comment 31

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #30)

Which is consistent with this being an invalidation bug.

Comment 32

[Mounir Lamouri (:mounir)]

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

Comment 33

[Steven Michaud [:smichaud] (Retired)]

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

Comment 34

[Karl Dubost💡 :karlcow]

It's working for me in Firefox 32.0.3 Mac.
I'm closing the bug. Reopen if I have missed something.