User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7 When you access two HTTP authenticated URLs (with frames?) 'at the same time' (see below) and only partially authenticate with one URL (the 'first' you visit), but fully authenticate with another and then cancel the second instance first site's authentication, Firefox/Mozilla crashes out. A good example is phpMyAdmin, which has two such frames, if you try it with two different installations of phpMyAdmin at the same time it should happen. Reproducible: Always Steps to Reproduce: No special setup steps. I think both authenticated URL's A & B have to use frames to require them to authenticate twice, but... 1. Go to authenticated URL A. 2. Enter user+pass 1st time. 2. Leave 2nd user+pass box up. 3. Get into address bar somehow (CTRL+L, etc?) 4. Go to authenticated URL B. 5. Authenticate properly with URL B twice. 6. Cancel the second authentication window from URL A. Actual Results: Firefox, or Mozilla Browser both die completely at the same point. Expected Results: Not crashing out, just anything other that that really. This happens even in firefox 'safe mode', and also in plain 'Mozilla', and happens with various different authenticated URLs. I don't have the time or motivation to update to the very latest version of both Firefox and Mozilla etc. on an important master workstation, or to try it out yet again on a windows based platform, but I thought I should file the bug anyway, rather than just ignore it.
Well do you have any Talkback ID for the crash? Also you can try the current version of Firefox or SeaMonkey without problems and risk by creating a test profile with the -profilemanager flag.
Tried this on Windows XP with the latest version of firefox (as at a week or so ago), and could not replicate the bug, as you can't access the address bar with any of the methods that work on linux under windows. Hence I can't get a TalkBack ID for it (that only works under windows too?). I will try and find time to download and build the latest version under Linux, and get back to you.
Hiya, Slack day today somehow, so I managed to get the latest version of Firefox installed (Mozilla Firefox 188.8.131.52, Copyright (c) 1998 - 2006 mozilla.org), and it automatically had the Talkback agent on it. I'm now cursing Fedora Core for being out of date on Firefox versions... Anyways, Talkback ID's for this problem are as follows. There are two because I was trying to skip through the process quickly and missed the ID the first time, so tried again... TB16569108E TB16569058G Over to you folks now, so good luck with it. K.
You can't see the bug on windows because of bug 100180. Here an example: http://wargers.org/mozilla/framesauth.htm
dumping in http
Assignee: general → nobody
Component: General → Networking: HTTP
Product: Mozilla Application Suite → Core
QA Contact: general → networking.http
Version: unspecified → 1.8 Branch
can you reproduce using FF 3.5 beta? http://www.mozilla.com/en-US/firefox/all-beta.html
Whiteboard: closeme 2009-07-07
Honestly, after three years (since the response before last of "dumping in http"), I've forgotten the URLs that originally triggered this, but I will try and work backwards from my original report to replicate this. I suspect it was my admin system that did it, which I have in a multi-url 'home page' setting. Failing that, I can find at least two phpMyAdmin instances at work to give it a go. Evidently this update shows that I am still here, willing to try it again, and haven't disappeared, however, which may be of value.
Urgh. Reading the first paragraph of my original bug report made my brain hurt. I tried replicating this, but I can only remember one URL that uses two separate frames, both of which require authentication, I am missing a second one to fully validate this. In the case of a 2-auth-frames URL A, and a 1-auth-page URL B, where I'd log in correctly to URL A's first request, cancel URL B's request, and either cancel or log in correctly to URL A's second request, I cannot replicate the crash bug. It's nearly the same, but not quite. I will try and remember the second URL I used, or if someone has a test site that I could use in combination with my one known 2-frames-with-auth-on-both site, I could try accurately.
Kev: I will resolve the bug as WORKSFORME for the moment. If you do reproduce it, just comment about the results with the crash results, and we will reopen the bug. (I would gladly offer my phpMyAdmin installs, but they are all behind a firewall.)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.