Closed Bug 210209 Opened 21 years ago Closed 14 years ago

conflict of "find as you type" feature with "audiofile" package - any keyboard event locks up mozilla

Categories

(SeaMonkey :: Find In Page, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: jfsworld, Unassigned)

References

Details

(Keywords: hang, helpwanted)

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.1; Linux)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313

as per subject. Keyboard events include typing in the url box, and even using 
keyboard shortcuts 

Reproducible: Always

Steps to Reproduce:
1. install audiofile 
2. run mozilla with the "find as you type" feature enabled 
3. do any sort of keyboard input 
Actual Results:  
lock up. Mozilla stops responding. 

Expected Results:  
carry on as per normal. 

* this bug applies to Firebird 0.6 (applies to the precompiled package downloaded 
from mozilla.org; I have not tried compiling things myself to test it, but it should be the 
same) as well! The only solution here (since there is no disabling "find as you type") is 
to remove audiofile, which effectively disables my sound in kde... 
 
more info and user comments may also be found at this discussion - 
http://forums.mozillazine.org/viewtopic.php?t=11874
might be a dupe of bug 198345
Keywords: hang
Almost certainly, the problem is that audiofile is opening and locking the sound
device.  So when we initialize esd (a different program that does much what
audiofile does, as I understand it) inside nsSound (for the typeahead find
beeps), esd blocks on the locked sound device (since it too wants to open it). 
Which means Mozilla blocks on esd.  Which means life sucks.

Over to Aaronl; this is the third or fourth way I've now seen that initializing
esd can trigger a hang.  We need to be a little smarter about initing nsSound,
like doing it on a separate thread or something.  Or we need to fix nsSound to
not suck.
Assignee: saari → aaronl
Status: UNCONFIRMED → NEW
Component: Event Handling → Keyboard: Find as you Type
Ever confirmed: true
QA Contact: desale → sairuh
Bug 110385 is about making sound asynchronous on Linux. Would that probably fix it?

Anyway, you can also change find as you type to not emit a sound at all.

See Preferences -> Advanced -> Keyboard Navigation -> Play a sound when typed
text is not found.

Marking helpwanted -- someone who knows something about linux sound should take it.
Blocks: atfmeta
Keywords: helpwanted
> See Preferences -> Advanced -> Keyboard Navigation -> Play a sound when typed
> text is not found.

Actually, Mozilla locks up when creating a profile (since you have to type in
the profile location/name), so you can't even get to this screen if you're
having this problem....
*** Bug 213286 has been marked as a duplicate of this bug. ***
It is iptables or /etc/hosts
Take a look at the gentoo forum
http://forums.gentoo.org/viewtopic.php?t=129496

I did on my PC a very stupid mistake. I wrote 128.0.0.1 instead 127.0.0.1 in
/etc/hosts. Now is everything okay!
It is not a mozilla bug!
Nelvin
(In reply to comment #6)
> It is iptables or /etc/hosts
> Take a look at the gentoo forum
> http://forums.gentoo.org/viewtopic.php?t=129496

The bug referred to in this discussion is clearly a very different bug.  This
bug (210209) locks up Mozilla permenently and completely, requiring a restart. 
The bug in the discussion causes a 5-10 second delay.

I think it very likely at this point that the problem here (210209) is "find as
you type" (and possibly other sound-using features) clashing with the sound
handling.  

Another report: I have experienced this problem with several versions of Mozilla
(1.3 through Firefox) on new hardware for which sound is not set up (no kernel
support). Turning off "find as you type" fixes the problem for now.

Depends on: 110385
Product: Core → SeaMonkey
Assignee: aaronleventhal → nobody
QA Contact: bugzilla → keyboard.fayt
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.