Closed Bug 18877 Opened 25 years ago Closed 25 years ago

Flickering of text control while laying out travelocity login

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: m, Assigned: troy)

References

(
URL
)

Details

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]$
Crashes M11 also.
Assignee: leger → gagan
Component: Browser-General → Necko
QA Contact: leger → tever
Moving to Necko since other travelocity issues are posted there.  Possible
related bugs.
Assignee: gagan → rpotts
Summary: Crasher: Travelocity login → [dogfood] Crasher: Travelocity login
Target Milestone: M12
Rick, can you look at this? Thanks.
Whiteboard: [PDT+]
Putting on PDT+ radar.
Assignee: rpotts → trudelle
Component: Necko → XP Toolkit/Widgets
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.)
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.
Assignee: trudelle → evaughan
Priority: P3 → P1
Whiteboard: [PDT+] → [PDT+] 12/10
Added tentative fix date
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
The box fix I checked in yesterday seems to have fixed this.
URL: http://www.travelocity.com/ → http://www.travelocity.com
Status: RESOLVED → REOPENED
Summary: [dogfood] Crasher: Travelocity login → [dogfood] Travelocity login
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.]
Resolution: FIXED → ---
Celaring resolution.
Assignee: evaughan → vidur
Status: REOPENED → NEW
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.
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.
Assignee: vidur → karnaze
Severity: critical → major
Summary: [dogfood] Travelocity login → Flickering of text control while laying out travelocity login
Whiteboard: [PDT+] 12/10
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.
Target Milestone: M12 → M13
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.
Assignee: karnaze → troy
Re-assigning to Troy, because the flicker is the result of changes to how
view positiong works
*** Bug 20930 has been marked as a duplicate of this bug. ***
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
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Flickering appears to be gone.

verified:
Linux 2000020809
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.