Closed Bug 366064 Opened 19 years ago Closed 15 years ago

Periodic "stalling" of firefox after variable browse time (< 1 hour generally) when Outpost Firewall is on PC

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
2.0 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mrfellers, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Firefox Version: 2.0.0.1 (and 2.0) OS: WinXP SP2 Outpost Firewall Version: 4.0.971.7030 (584) Symptom: Firefox 2.x works correctly for some amount of time (generally less than 1 hour, sometimes as much as 2). After indeterminate time, typing in a new URL or choosing a bookmark results in an "idle" spinning of the activity indicator in top right. Once this occurs, NO open tabs (or additionally opened tabs) work... they all have the "waiting for website" type spinning. Sites NEVER time out. Menues still responds... can open new tabs... close existing tabs... etc. When you close firefox (with close "x" or through "File" menue), you get the normal prompt "You have more than one tab open" kind of message if you do. You exit, and it appears to have closed. However, Firefox.exe process continues to exist in Task Manager under "processes". You have to manually end the process. It uses NO processor time, but the memory footprint remains static. This has been attempted multiple times... using the "in-place upgrade" from 1.5.0.9, as well as un-installing 1.5.0.9, deleting both Mozilla folders in "Documents and Settings", and then installing 2.x. 1.5.x does not exhibit the problem. Outpost firewall is in "prompting mode", where it asks for "Allow" or "Block" on previously un-defined network access of Firefox. I get no prompt immediately before the stall. During troubleshooting, I added a "System" level Outpost firewall rule to allow ALL incoming and outgoing TCP traffic to the loopback adapter address (localhost... 127.0.0.1). This seems to resolve the issue. I find it odd I'm not prompted by Outpost, since I've had mutliple applications that have requested the same access and triggered a popup. Reproducible: Always Steps to Reproduce: 1. Install Firefox 2.0 on machine with Outpost Firewall, having no global "Loopback address" allow rule 2. Browse some in one or more tabs... a good trigger is to leave a tab on cnn.com, since it periodically auto-refreshes. 3. Eventually a stall occurs. Actual Results: Firefox stops loading pages. ALL pages. Expected Results: Continued loading pages, and or triggered an Outpost event (which most apps do). Since all other apps I have used that require loopback access have triggered a "Learning mode" prompt from Outpost, I'm not sure why this one is not. I find it very odd... I'm guessing either some uncommon usage of the address, or just something the vendors didn't think of. I've read reports of similar issues with other firewall products on the Mozillazine forums.
Version: unspecified → 2.0 Branch
I think the essential part of this bug is that Fellers reports that the problem never occurs with Fx 1.5 but always with Fx 2.0. Thus, I'm not so sure this should be written off too quickly as an Outpost bug. I would change the summary if I could. There's more discussion here: http://forums.mozillazine.org/viewtopic.php?p=2683606#2683606 and in the message following it. There are several people who report vaguely similar symptoms, although this is the only one that seemed solid enough for a bug report.
Hmmm. Fx 1.5 and 2.0 should be treated by Outpost as different programs. Are you sure that when the problem occurred the Outpost rules were identical for both programs? In other words, could the 127.0.0.1 already have been allowed for version 1.5 while it may have been blocked somehow (user error or program quirk, for example) for 2.0?
Actually, the way Outpost works is: So long as you install it in the same location as the prior version, the rules carry over and apply. It has what it calls "Component Control", which will warn you the executable (and or .dll's, etc) have changed on the first firing, but the actual rules are not altered. I have been installing this in the same "Default" directory every time, so the rules carry over.
This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME http://www.mozilla.com http://support.mozilla.com/kb/Managing+profiles http://support.mozilla.com/kb/Safe+mode
Turns out this was Outpost blocking certain traffic (silently) on the loopback adapter. Excluding Firefox from any restriction on the loopback address resolves the issue.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
INVALID then
Resolution: FIXED → INVALID
You need to log in before you can comment on or make changes to this bug.