SmithBarney login form broken on Minefield

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Fritz, Assigned: tnikkel)

Tracking

({regression})

Trunk
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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
(Reporter)

Comment 1

8 years ago
Created attachment 471103 [details]
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.
Just tested this out on the latest hourly build of Minefield, I can confirm this behavior.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
Version: unspecified → Trunk
(Reporter)

Comment 3

8 years ago
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

8 years ago
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
Fails on Linux as well.

OS -> All
OS: Windows 7 → All
Blocks: 130078
Component: General → Layout: View Rendering
Product: Firefox → Core
QA Contact: general → layout.view-rendering
This is a regression from bug 130078.  Narrowed down using hg bisect.
Keywords: regression
blocking2.0: --- → ?
(Assignee)

Comment 7

8 years ago
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

8 years ago
(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.
(Assignee)

Comment 9

8 years ago
I actually think the assertions might be pointing out the problem here. I'm investigating.
(Reporter)

Comment 10

8 years ago
(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).
(Assignee)

Comment 11

8 years ago
(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.
(Assignee)

Comment 12

8 years ago
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.
(Assignee)

Updated

8 years ago
Duplicate of this bug: 592920

Comment 14

8 years ago
(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

8 years ago
FWIW, I can't reproduce the black field on Mac.
(Assignee)

Comment 16

8 years ago
(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.
(Assignee)

Updated

8 years ago
Depends on: 592920

Comment 17

8 years ago
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!
(Assignee)

Comment 18

8 years ago
The unbalanced update view batches would cause the painting problems here.
(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.
(Assignee)

Comment 20

8 years ago
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.
(Assignee)

Comment 21

8 years ago
Bug 240933 seems to fix most of the problems here for me on Linux.
Assignee: nobody → ehsan
blocking2.0: ? → betaN+

Updated

8 years ago
No longer depends on: 592920

Comment 22

8 years ago
Bug 586662 will fix the assertions here.
Depends on: 586662

Comment 23

8 years ago
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?
(Assignee)

Comment 24

8 years ago
Ok, I think this is fixed now, but I will make sure there is not another issue we are covering up.
Assignee: ehsan → tnikkel
(Assignee)

Comment 25

8 years ago
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

8 years ago
I just landed bug 586662, FWIW.  It will be in tonight's nightly.
(Reporter)

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.