this secure URL fails logging in.




18 years ago
18 years ago


(Reporter: tarahim, Assigned: paulkchen)


Mac System 9.x

Firefox Tracking Flags

(Not tracked)


(Whiteboard: hard to reproduce, URL)


(1 attachment)



18 years ago
2001062116 trunnk.
Goto URL.
You get the security warning and you click OK.
The result:crash.
This crash occurrs regardless of TLS setting in Pref|Security|SSL.

Comment 1

18 years ago
Created attachment 39801 [details]
stack trace of the crash accessing this secure site

Comment 2

18 years ago
WFM using 2001062104 Win2k. Maybe a Mac only bug?
Keywords: crash

Comment 3

18 years ago
Wfm with 2001062204 / Win98SE.

Comment 4

18 years ago
Well, in 2001062209 trunk, crash does not occur. However, the URL which is a
page with login form, does not work. Sending form bring you back to the same
login dialog.
This despite Cookie is enabled. Seems like a regression of some bug I saw in May.
FYI, this login works with 2001060709 build.
Summary: crash accessing this secure URL → crash accessing this secure URL and failure of logging in if no crash.

Comment 5

18 years ago
-> PSM
Component: Security: Crypto → Client Library
Product: Browser → PSM
Target Milestone: --- → 2.0
Version: other → 2.0

Comment 6

18 years ago
The stack trace is from the wallet code. Re-assgning.
Assignee: ddrinan → morse
Component: Client Library → Password Manager
Product: PSM → Browser
QA Contact: junruh → tpreston
Target Milestone: 2.0 → mozilla0.9.2
Version: 2.0 → other

Comment 7

18 years ago
reporter, I'm very confused.  You said that this is a login form.  That's not 
what I get at all.  I get a page with lots of japanese characters (which of 
course I can't read) but having no fields to fill in.  And the source of that 
page does not contain any <input> tags or <submit> tags.  So this can't possibly 
be a login form.  

Comment 8

18 years ago
reassigning to pchen for mac work
Assignee: morse → pchen

Comment 9

18 years ago
nav triage team:

need to investigate, marking p1 and nsbeta1+, also setting target milestone to
Keywords: nsbeta1+
Priority: -- → P1
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 10

18 years ago
Running 2001062809 0.9.2 commercial mac build, I can't reproduce this crash. I
go to the URL, click OK on the security warning dialog, and the page loads fine.
This is on a US English MacOS 9.1 system. I'll go and try and trunk mozilla build.

Comment 11

18 years ago
Ok, just ran 2001062808 trunk mac mozilla build, and it doesn't crash either
(same system as before). I'm really tempted to mark this worksforme unless
there's something else I'm missing. Adding "hard to reproduce" in status whiteboard.
Whiteboard: hard to reproduce

Comment 12

18 years ago
Hmm, works for me too mac branch build 2001062809

Comment 13

18 years ago
In 2001062914 trunk, it does not crash, but logging in is impossible.
Pressing LOGIN returns to the same page with "you have requested insecure
document" warning as well as "low grade encryption" warning.

Downgrading the severity and removing keywords.
Severity: critical → major
Keywords: crash, nsbeta1+
Summary: crash accessing this secure URL and failure of logging in if no crash. → this secure URL fails logging in.
Keywords: nsbeta1
Does it fail to login on a branch build also? 
Keywords: nsbeta1 → nsbeta1+, nsBranch

Comment 15

18 years ago
I am wondering if this problem has anything to do with cookies.
I have expxerienced in another non-secure site where I could not log in and the
server kept responding that the session was expired.
The URL is and you login using ID=mio and PW=mio .
Both the URL for this bug and this URL work with NS4.7.

Comment 16

18 years ago
See also bug 88060.

Comment 17

18 years ago
Hmm, I just tried my branch mozilla mac build from today, and I don't have any
problems logging onto

Hirata, how about moving your cookies.txt file out of your profile and see if
you still have problems logging in.

Comment 18

18 years ago
Same thing. No difference.
I am wondering if there is any problem with time stamping.
The failure of both URL seem to involve timing.
The first one calcultes time consumed in ISP account.
The second one returns time out error.

Comment 19

18 years ago
Sorry Paul, still unable to reproduce with branch build 2001070903 :-(

Comment 20

18 years ago
Please ignore my comment about
That turned out to be my mistake about accepting cookies.
However, the secure URL is still returning to the same login page even after I
have cleared all the cookies sites and set to accept all cookies.
in light of Paul's and Terri's comments on hard to reproduce on branch, removing 
Keywords: nsBranch

Comment 22

18 years ago
I strongly suspect that this is a cookies problem. Login at the URL always
returns to the same page, and in other pages that can be reached by login at
the server returns an error that states that could be translated to "Page
request was from wrong page".
There are some cookies bug that may be related:
bug 88968, bug 91206, bug 91238 seem to describe something similar.
Component: Password Manager → Form Submission

Comment 23

18 years ago
nav triage team:

Moving out to mozilla0.9.4, needs more investigation
Target Milestone: mozilla0.9.3 → mozilla0.9.4
nav triage team:  moving to 0.9.5.
Severity: major → normal
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 25

18 years ago
This is now WFM in 2001080608 trunk build.
Are other login failure bugs working now, too?
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 26

18 years ago
Seems like a dupe of bug 89995
Depends on: 89995
You need to log in before you can comment on or make changes to this bug.