79123 - Mozilla browser ignores all input

Status: RESOLVED WORKSFORME

(SeaMonkey :: Location Bar, defect)

Description

[Dave Buckles]

Here's a strange one for you... I was using Mozilla for browsing, as I have been 
for some time.  I clicked a link, and nothing happened.  This problem was 
actually fairly common in Netscaepe 4.x, so I closed the program (I used the 
Task Manager to ensure that its process was completely dead), then restarted.  
This had no effect.  Mozilla (the browser) refuses to acknowledge any form of 
navigation--hyperlinks in pages (the original bug), typing in the URL bar, 
bookmarks (in the drop-down bookmark list, on the personal navigation bar, or 
the Mozilla button in the top right corner), nothing works.  The browser 
defaults to a blank page, though it does not display "about:blank" in the URL 
bar.  If you press "Refresh" *twice*, "about:blank" is displayed, but not until 
the second reload (the same thing applies to Ctrl-R, or a combination of the 
two--two reloads are necessary).  The status bar displays "Read about:blank" 
without any intervention; that is, when Mozilla starts, it is displayed.  
Incidentally, about:blank is not my home page (Altavista is).  By this time, my 
curiosity was piqued, and I wondered if perhaps Windows wasn't misbehaving; 
therefore, I rebooted the system.  No dice.  Even a second reboot, this one to a 
full shutdown (as opposed to Start | Shut down | Restart), did not fix the 
problem.  I have also tried clearing both my memory and disk caches, to no 
effect.  I have not tried deleting and reinstalling the program; I expect that 
would probably fix it, and I want to be able to try other solutions proposed, so 
that the bug can be determined.  Please feel free to e-mail me with questions or 
suggestions; I will be happy to help in any way possible.
--Dave

Comment 1

[Dave Buckles]

Ahh, yes, I forgot to mention: the build ID on my copy of Mozilla is 
2001032319.
--Dave

Comment 2

[Scott Tran (Wildcard)]

Hmm I assume ur on Windows, here goes try a new profile to see if that helps

Comment 3

[Alec Flett]

can you break this down into a set of reproducable steps? I'm getting lost in
your soliloquy

Comment 4

[Dave Buckles]

I just tried the suggestion of using a new profile.  When I run 'mozilla -
installer' (on the command line, the only way to launch the profile manager, so 
far as I can tell), it just launches a normal Mozilla browser window; it does 
not give me the profile manager.  If somebody can suggest another way to launch 
the profile manager, I'll try it, but if that's the only way, then no, that 
suggestion didn't work.
--Dave

Comment 5

[Alec Flett]

such as mozilla -ProfileManager?

Comment 6

[Dave Buckles]

OK, update time!  I just downloaded Moz 0.9.  It works great, right up until I 
try to use my old profile.  If I create a new profile, everything is fine, but 
if I try to use my old profile, I have the same trouble: navigation of any sort 
is ignored.  Any idea what in a profile could cause this?  If desired, I could 
probably submit a copy of my profile for testing (I'd rather not, privacy and 
all, but if it's absolutely necessary...).  I can't just start over, 
unfortunately--I have e-mail in there I can't afford to lose right now.  
Suggestions?
--Dave

Comment 7

[Dave Buckles]

Found the source of the problem: I was using a proxy configuration script.  I
recently changed from manual proxy configuration to using a proxy script.  When
I returned to the original (manual) configuration, or no proxy, Moz worked just
fine.  I do not know at this time whether the problem is with the configuration
script itself, or whether is it Mozilla's handling of that script.  I'm going to
contact the author of the script and discuss it with him; I'll post a follow-up
as soon as I do.  Even if the problem does turn out to be with the config
script, though, this should probably be looked into--an invalid config script
should throw an error or be ignored, not cause the browser to lock.  NS4 would
warn if the script was invalid.
--Dave

Comment 8

[Dave Buckles]

Final story: I talked to the author of the proxy config script.  Turns out the
problem was with the script.  That begs the question, though: should a bad
script be allowed to crash the entire browser?  I would argue that the browser
should warn of errors, then ignore the script, instead of allowing it to lock
up.  The script can be found at http://ppwebdev.physicalplant.ou.edu/proxyconf.js.

Comment 9

[Arnoud Berendsen]

This is resolved incorrectly

Comment 10

[Arnoud Berendsen]

-> WFM.
Someone please mark this verified.