Closed Bug 771913 Opened 12 years ago Closed 12 years ago

firefox crashes in response to typing

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Version:
14 Branch
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox14 - ---

People

(Reporter: maxh, Unassigned)

Details

(Keywords: crash, platform-parity, regression)

Attachments

(1 file)

Stack trace from Console
73.46 KB, text/plain
Details 
User Agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.4; U; Edition Next; en) Presto/2.10.289 Version/12.00



Actual results:

In latest beta, any text entry (whether in a text box or not) causes Firefox to crash. OS is Mac OS 10.7.4. Error reported is uncaught exception 'NSAccessibilityException'.
Hardware: x86 → x86_64
Can you provide the crash ID (bp-...) from about:crashes if it's a real crash (Firefox closes unexpectedly)?
Does it happen in Safe Mode (http://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode)?
The Mozilla crash reporter does not appear, only the Apple crash reporter. This does not make an entry in the about:crashes log.
The problem does occur in Safe Mode.

    
    

    
  
Did it happen in the previous Beta, i.e. 14.0b10?
Severity: normal → critical
Keywords: crash

    
    

    
  
Nope. I restarted Firefox to update and could no longer do anything due to crashes. (I've downgraded to the stable version for now.)

    
    

    
  
The regression range should be:
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=e4445f905091&tochange=48842c93fcb2
Status: UNCONFIRMED → NEW

          tracking-firefox14:
          --- → ?
Component: Untriaged → General
Ever confirmed: true

    
  
Keywords: regression

    
    

    
  
From the attached crash data:

*** Terminating app due to uncaught exception 'NSAccessibilityException', reason: '"AXValue" attribute unsupported by: <ToolbarWindow: 0x10ace2530>'
Component: General → Disability Access APIs
Keywords: pp
Product: Firefox → Core

    
    

    
  
And here's the most fun fact about this:
1. There were no accessibility-related changes in the regression range posted.
2. Accessibility is not, repeat: NOT, built on 14! Not even on 15! So we're either dealing with a corrupt stack, or this is a custom build that has accessibility on, or something else really funky is going on. But I know for a fact that we never allowed accessibility to be turned on for 14.

    
    

    
  
It does.

    
    

    
  
Max, I notice that the SpeechSynthesis and SpeechRecognition frameworks are present in your log from comment #4.  Do you use either of these from Firefox?  (If so, this might explain why you seem to be seeing an accessibility crash in a build without accessibility support.)

The Firefox-specific symbols from your stack in comment #4 are corrupt (because the beta you've been testing with has its symbols stripped).  I was going to recommend you test with the latest "profiling" nightly (which doesn't have its symbols stripped) ... but when I looked I couldn't find any.  I'll keep looking and report back later.

    
    

    
  
I've not used either of those, certainly not with this version.

    
    

    
  
Marco, is accessibility built in current trunk nightlies (on the 16 branch)?

    
    

    
  
(Following up comment #12)

> The Firefox-specific symbols from your stack in comment #4 are
> corrupt (because the beta you've been testing with has its symbols
> stripped).  I was going to recommend you test with the latest
> "profiling" nightly (which doesn't have its symbols stripped)
> ... but when I looked I couldn't find any.  I'll keep looking and
> report back later.

Actually even the "regular" trunk nightlies no longer have their
symbols stripped.

So Max, please test with the following build (which is today's
mozilla-central (aka trunk) nightly):

ftp://ftp.mozilla.org/pub/firefox/nightly/2012-07-09-03-51-18-mozilla-central/firefox-16.0a1.en-US.mac.dmg

    
    

    
  
(In reply to Steven Michaud from comment #14)
> Marco, is accessibility built in current trunk nightlies (on the 16 branch)?

Yes, but it is triggered only if VoiceOver asks for it, not if other consumers do it, UNLESS you flip a hidden pref that always forces it on regardless of VoiceOver preference.

    
    

    
  
It does indeed appear to work.

    
    

    
  
(In reply to comment #17)

> It does indeed appear to work.

I was actually hoping it'd crash, so we'd get a non-corrupt stack.

Are you using VoiceOver?  Or *anything* else that alters/filters your
input, isn't a plugin and isn't an extension?

(In reply to comment #16)

> (In reply to Steven Michaud from comment #14)
>> Marco, is accessibility built in current trunk nightlies (on the 16
>> branch)?
>>
>> Yes, but it is triggered only if VoiceOver asks for it, not if
>> other consumers do it, UNLESS you flip a hidden pref that always
>> forces it on regardless of VoiceOver preference.

Just a guess, but it may be this that stops elasmo from crashing in
today's trunk nightly.

What's the hidden pref?

    
    

    
  
(Following up comment #18)

> Are you using VoiceOver?  Or *anything* else that alters/filters your
> input, isn't a plugin and isn't an extension?

I should rephrase this:

Are you using VoiceOver?  Or *anything* else that alters/filters your input or output that isn't an extension?

    
    

    
  
VoiceOver is definitely disabled. I'm not aware of anything else that would alter I/O, either. The zoom feature is enabled but has not been used.

    
    

    
  
The zoom feature does not appear to be the cause of the crash; I disabled it entirely but this did not eliminate the crashes.

    
    

    
  
elasmo -> Max

Elasmo's in a different bug :-(

    
    

    
  
(In reply to Steven Michaud from comment #18)
> What's the hidden pref?

accessibility.force_disabled. 1 means always disabled, 0 means allow VoiceOver, -1 means allow all.

    
    

    
  
I just tried running FF 14.0b11 on OS X 10.7.4, and not surprisingly can't reproduce this bug.

Max, please give us specific examples of text boxes on specific pages where entering text triggers these crashes.

Is it any text at all?  Specific text?  Do the crashes happen on the first letter?  On key down or key up?

What keyboard layout are you using?  By any chance are you using any non-English-language settings?

    
    

    
  
> accessibility.force_disabled. 1 means always disabled, 0 means allow VoiceOver,
> -1 means allow all.

Max, please try changing this setting in today's mozilla-central nightly, to see if any of the possible values trigger your crashes.

To change the setting go to about:config.  You'll need to restart Firefox each time you change the setting.

    
    

    
  
There isn't a specific textbox (I even tested it without focus on a textbox), nor specific text (the first time it happened I was typing a URL, after it happened twice I didn't bother with anything specific). There is time to press a few keys, but it's almost certainly typing-related; when left alone no crash occurs.

I'm on a modified U.S. International keyboard layout. Several non-English languages are enabled, but English is the first in the list.

accessibility.force_disabled being set to -1, 0, or 1 does not seem to have an effect.

    
    

    
  
> I'm on a modified U.S. International keyboard layout. Several non-English
> languages are enabled, but English is the first in the list.

What, exactly, does this mean?

Which keyboard layouts are enabled (with which settings)?

Are you using any keyboard layouts that aren't from Apple?  Or which were installed separately (that didn't just come with the OS)?

By any chance is your physical keyboard not from Apple?

    
    

    
  
Just tried the "US Extended" keyboard layout (on OS X 10.7.4 with FF 14.0b11), and had no problems.

    
    

    
  
I tried disabling all keyboard layouts except the default U. S. layout; this did not prevent crashing. The physical keyboard is Apple.

    
    

    
  
I'm out of ideas :-(

I'm thankful you don't crash with current trunk code ... but don't know why.

    
    

    
  
I don't think we should track this until we figure out how to reproduce it, or at least until we find that it's widespread.

Right now I suspect very few people see these crashes.

    
    

    
  
Two last, rather desperate suggestions:

Have you rebooted your computer since these crashes started happening?

If not please try it.

Also try creating a new account in System Preferences : Users and Groups, and see if these crashes happen using that account.

    
    

    
  
Restarting did not do anything, but switching accounts did.

    
    

    
  
So this bug is caused or triggered by something you installed in your "regular" account.

Please try to figure out what that might be.  And if you find out, please report it here.

For the time being I'll mark this bug WORKSFORME.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: