Closed
Bug 72437
Opened 24 years ago
Closed 24 years ago
crash when trying to enter my password into bugzilla.mozilla.org
Categories
(Core :: DOM: Editor, defect)
Tracking
()
People
(Reporter: sspitzer, Assigned: kinmoz)
References
Details
(Keywords: crash)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
here's the assertion that came right before the crash:
###!!! ASSERTION: transaction did not execute properly
: '(NS_SUCCEEDED(result))', file nsEditor.cpp, line 459
###!!! Break: at file nsEditor.cpp, line 459
I'll go get a stack trace.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
it doesn't happen all the time, but I've gotten in 4 out of 5 times in a row.
Reporter | ||
Comment 3•24 years ago
|
||
some more info:
it seems to happen when I type in the username / password fields before
autofill gets a chance to finish.
the throbber is still spinning, and the fields are blank, so I go to type
in my username / password. and then I crash.
if I wait patiently, autofill doesn't seem to fill in the fields.
but if I hit stop, autfill fills in the fields.
Comment 4•24 years ago
|
||
*** This bug has been marked as a duplicate of 53956 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 5•24 years ago
|
||
Uhh, morse, this is *not* a duplicate of the "throbber keeps spinning" bug. This
is also a crash.
Reporter | ||
Comment 6•24 years ago
|
||
this does seem related #53956.
but in addtion to not stopping, I sometimes crash when I jump the gun and try to
edit those text fields.
Comment 7•24 years ago
|
||
I suppose Warra's point was that when we fix bug 53956 we will only be masking
this crash but not eliminating it. In other words, the crash in the editor
won't be triggered by early form-filling but there will probably be some other
scenario that will get to the crash. So there probably should be some change
made to the editor to prevent the crash regardless of how you got there.
For that reason I'll reopen this bug report and remove the dup indication.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 9•24 years ago
|
||
Looks like someone else just observed the crash as well. Also on linux. So the
crash part of this bug seems to be unique to linux.
Also it's somewhat hard to reproduce. tpreston, who tried to q/a the
other bug (72326), was unable to reproduce it using the same build as the
reporter
Comment 10•24 years ago
|
||
You must be sure to type password BEFORE load of page is completed...
It crashes also when typing login BEFORE load of page is completed..
Comment 11•24 years ago
|
||
i was able to reproduce this [2001.03.19.11 comm bits on linux]. it is tricky
--i got a crash when i was typing in my username while the throbber was still
going, as others have noted.
link to talkback report:
http://cyclone.mcom.com/reports/SingleIncidentInfo.cfm?dynamicBBID=28085423
over to passwd mgr, per conversation w/terri.
Assignee: kin → morse
Status: REOPENED → NEW
Component: Browser-General → Password Manager
Keywords: crash
QA Contact: doronr → tpreston
Comment 12•24 years ago
|
||
The crash is not in the password manager, it is occuring somewhere in the
editor. Reassigning.
Component: Password Manager → Editor
Comment 13•24 years ago
|
||
And now I'm really reassigning.
Assignee: morse → beppe
QA Contact: tpreston → sujay
Comment 15•24 years ago
|
||
I'm seeing this in Win2000 as well (currently build 2001-0402-04). I have a
stack trace, but it only has the .DLL names.
Comment 16•24 years ago
|
||
*** Bug 74356 has been marked as a duplicate of this bug. ***
Comment 17•24 years ago
|
||
Yes, bug 74356 reports the same problem, but it adds the information that the
crash can be replicated on MS-Windows 98b; perhaps bugs that are marked dupicate
should also have their pertinent info copied into the comments of the "master
bug" to avoid losing attention of maintainers to useful addenda?
BTW, I was able to work around the mess reported in bug 74356, where I had done
a logout of Bugzilla only to see my cookie nuked, by reacquiring a cookie via
Internet Explorer, closing that, opening Mozilla, and, as indicated by sujay,
pressing "stop" to allow the cookie to load, then pressing the "login" button,
without ever trying to enter data in the email address or password text widgets.
The lack of stopping is a more general problem, which I am going to go try to
find, and if I cannot, add as a new bug; it happens when a blank window is the
default startup window for Mozilla, too.
Comment 18•24 years ago
|
||
This is a dup of bug 72186. And I just posted a patch for that bug.
*** This bug has been marked as a duplicate of 72186 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
Comment 20•24 years ago
|
||
Bugzilla has been acting up today. Although I marked this as a dup of bug
72186, that indication never appeared in the other bug. So again marking it as
a dup.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Comment 21•24 years ago
|
||
*** This bug has been marked as a duplicate of 72186 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•