592663 - SmithBarney login form broken on Minefield

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Fritz]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre

For almost all of 4.0pre logging onto SmithBarney.com produces weird behavior.

Until recently that behavior was:
1) Type in username
2) Tab over or click password box
3) Try to input -- but input will fail.
Result: You had to close the tab and start again.  The only way to make it work would be to type in the password first and then your username.

Now the new results are:
1) Type in username
2) Tab over or click password box
3) Try to input -- but input will fail.
Result: Password input area will become a black box (see screenshot) and the browser UI will become unresponsive.  You must click close and close the browser (so, it's not a full hang... you don't need to kill the process).

Reproducible: Always

Comment 1

[Fritz]

Attachment: Black password form on Smith Barney

This is the result of:
1) entering username
2) pressing tab
3) pressing first letter of password
Result: Input  box became black as in screenshot and browser had to be closed via X in right corner.

Comment 2

[Brian Carpenter [:geeknik]]

Just tested this out on the latest hourly build of Minefield, I can confirm this behavior.

Comment 3

[Fritz]

Two notes:

1) In most recent nightly (2010/09/01) it only fails when using the tab key.

2) You don't need a Smith Barney account.  It's only a form input issue so use any name and password, no need to submit form.

Comment 4

[alex_mayorga]

Confirming as well on Mozilla/5.0 (Windows NT 6.0; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre ID:20100901041125 so this is not only win7.

The offending form is at https://www.smithbarney.com/cgi-bin/login/login.cgi

Comment 5

[Bill Gianopoulos [:WG9s]]

Fails on Linux as well.

OS -> All

Comment 6

[Bill Gianopoulos [:WG9s]]

This is a regression from bug 130078.  Narrowed down using hg bisect.

Comment 7

[Timothy Nikkel (:tnikkel)]

When I type one letter into the password field after tabbing I get these assertions:

###!!! ASSERTION: bad action nesting!: 'mActionNesting>0', file ../../../../editor/libeditor/text/nsTextEditRules.cpp, line 250
###!!! ASSERTION: bad state: 'mUpdateCount > 0', file ../../../../editor/libeditor/base/nsEditor.cpp, line 4080
###!!! ASSERTION: already started a batch!: '!mRootVM', file ../../../dist/include/nsIViewManager.h, line 304
###!!! ASSERTION: bad action nesting!: 'mActionNesting>0', file ../../../../editor/libeditor/text/nsTextEditRules.cpp, line 250

Comment 8

[(no longer active)]

(In reply to comment #7)
> When I type one letter into the password field after tabbing I get these
> assertions:

Filed bug 592920 about that.

Comment 9

[Timothy Nikkel (:tnikkel)]

I actually think the assertions might be pointing out the problem here. I'm investigating.

Comment 10

[Fritz]

(In reply to comment #6)
> This is a regression from bug 130078.  Narrowed down using hg bisect.

Just to note, while the black box and unresponsive Minefield are post 130078, prior to that you could not input data into the username before the password field.  It always had to be in reverse.  So, there was something wrong before 130078 landed, I just never filed a bug since it had an easy work around (type password then username).

Comment 11

[Timothy Nikkel (:tnikkel)]

(In reply to comment #10)
> Just to note, while the black box and unresponsive Minefield are post 130078,
> prior to that you could not input data into the username before the password
> field.  It always had to be in reverse.  So, there was something wrong before
> 130078 landed, I just never filed a bug since it had an easy work around (type
> password then username).

This is useful information, thank you.

Please feel free to file bugs on issues like this in the future, even if there is an easy workaround.

Comment 12

[Timothy Nikkel (:tnikkel)]

I get the same assertions, and the content window goes blank in the m-c rev just before 130078 landed, so I think 130078 is just amplifying the existing bug.

Comment 14

[(no longer active)]

(In reply to comment #12)
> I get the same assertions, and the content window goes blank in the m-c rev
> just before 130078 landed, so I think 130078 is just amplifying the existing
> bug.

Do you get the black field pre-130078?  If not, we should reopen bug 592920 I think.

Comment 15

[(no longer active)]

FWIW, I can't reproduce the black field on Mac.

Comment 16

[Timothy Nikkel (:tnikkel)]

(In reply to comment #14)
> Do you get the black field pre-130078?  If not, we should reopen bug 592920 I
> think.

I see painting weirdness. But let's reopen bug 592920. Sorry to step on your toes.

Comment 17

[(no longer active)]

FWIW, I've seen a lot of broken-ness in the editor, but none of that broken-ness should result in a text field being broken.  There's definitely something wrong going on here no matter what the editor does!

Comment 18

[Timothy Nikkel (:tnikkel)]

The unbalanced update view batches would cause the painting problems here.

Comment 19

[Bill Gianopoulos [:WG9s]]

(In reply to comment #12)
> I get the same assertions, and the content window goes blank in the m-c rev
> just before 130078 landed, so I think 130078 is just amplifying the existing
> bug.

Hmm. That does NOT match my experience under Linux.  The M-C rev just before 130078 landed is 4722b491cd0d.  I do not see the issue relating to tabbing from the username field to the password field using that build.

The only rev that I see the content window go blank in, is the one after that, witch is ffacf623a9df, which contains just the first of the three check-ins for bug 130078.

Comment 20

[Timothy Nikkel (:tnikkel)]

I doubled check, using rev 01fa971e62ee, the content window stops updating completely. The textbox doesn't change color, the window didn't go blank (if I said that I was mistaken) but the content window stops updating at all, try scrolling, or anything else that should change what is drawn. I see nothing happening.

I bisected the bad behaviour on Windows and it regressed on nightlies when bug 534785 landed.

Comment 21

[Timothy Nikkel (:tnikkel)]

Bug 240933 seems to fix most of the problems here for me on Linux.

Comment 22

[(no longer active)]

Bug 586662 will fix the assertions here.

Comment 23

[(no longer active)]

I tested this on Linux, and I got the black password field once (the first time).  That is a fall out of bug 130078.  I don't think there's more to do here for me.  Timothy, want to take this?

Comment 24

[Timothy Nikkel (:tnikkel)]

Ok, I think this is fixed now, but I will make sure there is not another issue we are covering up.

Comment 25

[Timothy Nikkel (:tnikkel)]

Bill, could you try a 2010-08-27 nightly (before 130078 landed), try the STR in comment 0, and then see if the content area stops updating (by mousing over links, clicking on things, selecting things, scrolling, etc)? And check if the chrome area still is updating? And then try the same thing a 2010-08-28 nightly. I'm trying to determine if you are seeing the same thing as me, or something different.

Comment 26

[(no longer active)]

I just landed bug 586662, FWIW.  It will be in tonight's nightly.