18877 - Flickering of text control while laying out travelocity login

Status: VERIFIED FIXED

(Core :: XUL, defect, P1)

Description

[m]

Overview Description:

Attempts to login to the Travelocity site result in Mozilla crashing.  This is
repeatable.

Steps to Reproduce:

From the main page (www.travelocity.com), choose "Travel Menu" from the "View
More Tools..." pull-down list.

Actual Results:

Mozilla crashes

Expected Results:

Login as with e.g. Netscape 4.7

Build Date & Platform Bug Found:

Nov14 Linux Nightly Build

Additional Builds and Platforms Tested On:

M10 Linux does not crash, but does not successfully login.

Additional Information:

I believe it is attempting to autologin using saved user and password.

[m@m package]$ ./mozilla &
[1] 4409
[m@m package]$ MOZILLA_FIVE_HOME=/home/m/software/mozilla/package
  LD_LIBRARY_PATH=/home/m/software/mozilla/package
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
nNCL: registering deferred (0)
Successfully created instance of session history
Setting content window
browser.startup.page = 1
startpage = www.mozilla.org
got observer service
added observer
Document http://www.mozilla.org/ loaded successfully
Document: Done (18.505 secs)
****** GENERAL DRAG ********
****** GENERAL DRAG ********
FindShortcut: in='http://www.travelocity.com'  out='null'
nsLayoutHistoryState::AddState OOPS!. There was already a state in the hash tabl
e for the key
nsLayoutHistoryState::AddState OOPS!. There was already a state in the hash tabl
e for the key
nsLayoutHistoryState::AddState OOPS!. There was already a state in the hash tabl
e for the key
nsLayoutHistoryState::AddState OOPS!. There was already a state in the hash tabl
e for the key
nsLayoutHistoryState::AddState OOPS!. There was already a state in the hash tabl
e for the key
nsLayoutHistoryState::AddState OOPS!. There was already a state in the hash tabl
e for the key
nsLayoutHistoryState::AddState OOPS!. There was already a state in the hash tabl
e for the key
Error loading URL http://www.travelocity.com/
Document: Done (34.114 secs)
failed to set the page title.
Error loading URL http://dps1.travelocity.com/lognlogin.ctl?textonly=N&SEQ=94269
315727199
Document: Done (19.94 secs)

[1]+  Done                    ./mozilla
[m@m package]$

Comment 1

[m]

Crashes M11 also.

Comment 2

[leger]

Moving to Necko since other travelocity issues are posted there.  Possible
related bugs.

Comment 3

[Warren Harris]

Rick, can you look at this? Thanks.

Comment 4

[leger]

Putting on PDT+ radar.

Comment 5

[Warren Harris]

Ok, I tried to look at this with tonight's latest and greatest build, and the
situation is really hopeless. First, if you just go to the travelocity site, the
layout gyrates while the page is loading so much it will make you sick. Then if
you go to the login page (once you find it) (hint: try to book a flight), you'll
sit there for 2 minutes watching form fields hop all around the screen (and
we're not talking minor "move over until something else lays out," we're talking
full-on video game).

Finally after your bout with nausia subsides, try to click on the form fields
and it's nearly impossible to type any text in! I finally managed to do it by
selecting something else on the page and then tabbing over to the field I wanted
-- clicking on it was hopeless. Then... when you think you're about to see the
damn crash by trying to log on, you'll realize that there's no way to click the
logon button -- nothing happens!!!

I'm going home. (Wait, I am home.) Reassigning to Peter to figure out who can
look at this widget situation.

Oh, did I mention that the main travelocity page doesn't think javascript is
enabled for some reason? (It prints out a message to that effect on the page.)

Comment 6

[Peter Trudelle]

I think most of this is a duplicate of at least three other bugs:
http://bugzilla.mozilla.org/show_bug.cgi?id=20317,
http://bugzilla.mozilla.org/show_bug.cgi?id=19598
http://bugzilla.mozilla.org/show_bug.cgi?id=20148
Since this bug is the only one reporting a crash, I'll leave it open.  If there
are some other unique defects I'm missing in this bug report, then they should
be broken out into separate bug reports, one per defect.
BTW, I still don't see anywhere near the amount of reflow described in any of
these bugs.  I think that the debug builds must be much worse than the opt
builds in this respect.
reassigning to evaughan on a hunch that this only happens with GFX scrollbars.

Comment 7

[Peter Trudelle]

Added tentative fix date

Comment 8

[Eric Vaughan]

The box fix I checked in yesterday seems to have fixed this.

Comment 9

[Prashant Desale]

Actually I don't see crash here and according to reporter we should see crash as
soon as we select Travel Menu. When login page apears then we should see crash.

On the other hand I'm experiencing same thing as Warren Harris did. That
password field keeps on hopping around a lot, and finally when you try to get
hold of it, then you can not see anything else but login text box and password
field. Eveyting else is gray.
I'm not sure whether it needs seperate bug report or not for all other problems
than that crash which I don't see.

For more detailed explanation please read Warren Harris's explanation above.

For time being I'm going to re-open this bug. If you think it should be resolved
and verified, let me know and I'll file another bug for the problems we are
seeing. [Crash is not there for sure.]

Comment 10

[Prashant Desale]

Celaring resolution.

Comment 11

[Eric Vaughan]

This jumping the text password field I believe happens because of the way the
table is incrementally loaded. This does not happen because of gfx scrollbars
because it happens whether they are turned on or off.

This looks like a incremental table loading problem. So its either Chris, or
Vidur.

Comment 12

[vidur (gone)]

The crash was fixed earlier by evaughn. The enter button will only work in a
commercial build - it requires https. I checked in changes that reduce (but not
eliminate) the amount of flashing - we no longer force notifications from the
sink when we deal with badly nested forms. The remaining flashing I believe is
just a result of table layout - there are no notifications that happen till the
end.

Comment 13

[vidur (gone)]

Removing PDT+ designation since this is now very usable. Passing along to Chris
and Rod since now all flickering is a result of (non-incremental) table layout.
Rod, feel free to grab this bug if it's a DUP of the others that you have.

Comment 14

[chris hofmann]

moving this out to m13.  flicker fix would be good for m12 if low risk
but not critical.  there some other https blockers that keep up
from a fully functional travelocity site.

Comment 15

[troy]

Re-assigning to Troy, because the flicker is the result of changes to how
view positiong works

Comment 16

[troy]

*** Bug 20930 has been marked as a duplicate of this bug. ***

Comment 17

[troy]

I don't see text fields bouncing around anymore now that I fixed bug #22497. Now 
we do a better job of calculating where the table will be before we reflow it, 
thereby avoiding moving it twice. The moving twice is what caused widgets to 
flicker

Comment 18

[Tom Everingham]

Flickering appears to be gone.

verified:
Linux 2000020809

Comment 19

[Shayxix]

URL: https://www.click2book.co.uk/flights/flights-to-north-america

Comment 20

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/a087a9a9833d
[fenix] For https://github.com/mozilla-mobile/fenix/issues/18877 - Support updated PromptRequest AC APIs (https://github.com/mozilla-mobile/fenix/pull/19767)