2.18 KB, text/plain
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.
WFM using 2001062104 Win2k. Maybe a Mac only bug?
Wfm with 2001062204 / Win98SE.
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.
Component: Security: Crypto → Client Library
Product: Browser → PSM
Target Milestone: --- → 2.0
Version: other → 2.0
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
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.
reassigning to pchen for mac work
Assignee: morse → pchen
nav triage team: need to investigate, marking p1 and nsbeta1+, also setting target milestone to mozilla0.9.3
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: mozilla0.9.2 → mozilla0.9.3
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.
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
Hmm, works for me too mac branch build 2001062809
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.
Does it fail to login on a branch build also?
Keywords: nsbeta1 → nsbeta1+, nsBranch
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 http://www.epsonphoto.ne.jp/ and you login using ID=mio and PW=mio . Both the URL for this bug and this URL work with NS4.7.
See also bug 88060.
Hmm, I just tried my branch mozilla mac build from today, and I don't have any problems logging onto http://www.epsonphoto.ne.jp/. Hirata, how about moving your cookies.txt file out of your profile and see if you still have problems logging in.
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.
Sorry Paul, still unable to reproduce with branch build 2001070903 :-(
Please ignore my comment about www.epsonphoto.ne.jp 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 nsBranch
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 https://selfpage.dion.ne.jp/cgi-bin/cust/daa_menu.cgi 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
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
This is now WFM in 2001080608 trunk build. Are other login failure bugs working now, too?
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.