Crash when accessing multiple HTTP Authenticated URLs at the same time.

RESOLVED WORKSFORME

Status

()

Core
Networking: HTTP
--
critical
RESOLVED WORKSFORME
12 years ago
8 years ago

People

(Reporter: Kev Green, Unassigned)

Tracking

({crash})

1.8 Branch
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: closeme 2009-07-07, URL)

(Reporter)

Description

12 years ago
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.

Comment 1

12 years ago
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.
(Reporter)

Comment 2

12 years ago
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.
(Reporter)

Comment 3

12 years ago
Hiya,

Slack day today somehow, so I managed to get the latest version of Firefox installed (Mozilla Firefox 1.5.0.1, 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

Comment 5

12 years ago
dumping in http
Assignee: general → nobody
Component: General → Networking: HTTP
Keywords: crash
Product: Mozilla Application Suite → Core
QA Contact: general → networking.http
Version: unspecified → 1.8 Branch

Comment 6

9 years ago
can you reproduce using FF 3.5 beta?
  http://www.mozilla.com/en-US/firefox/all-beta.html
Whiteboard: closeme 2009-07-07
(Reporter)

Comment 7

9 years ago
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.
(Reporter)

Comment 8

9 years ago
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: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.