Closed Bug 768319 Opened 14 years ago Closed 14 years ago

crash in XUL@0xe91e0f

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: MarcoZ, Unassigned)

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is report bp-c590715a-6e6b-4eb4-b1bc-9fc1e2120626 . ============================================================= STR: 1. Set your profile to be at a Firefox-15.0a1 level. This is most easily done by installing a 15.0a1 Nightly build. 2. Install a current 16.0a1 nightly. 3. Before launching it, turn on VoiceOver. 4. Launch Nightly. Result: Crash. The XUL that appears at the start of a nightly that is of a higher version than the current profile always causes a crash when VoiceOver is active. I can reliably reproduce this. If I shut VoiceOver off, then launch Nightly and wait for a while, then turn on VoiceOver, I can use the Nightly htat has migrated the profile without problems. Second report: https://crash-stats.mozilla.com/report/index/bp-2883dfb5-f274-4505-9402-17a622120626 This is not new, I've seen it in the past, but only now got Crash Reporter to actually submit a report (previous attempts were with own dev builds without Crash Reporter).
there's not really much to say here until we have a stack with something approximating function names.
This was done with this try-server build: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/hfiguiere@mozilla.com-8779f3162001/ It's from bug 718700, but that bug has nothing to do with this crash. Perhaps that can get the symbols from somewhere, or I can try to reproduce with a regular nightly.
If you get the debug build you should get a better stacktrace. I'll try to reproduce, however, this puzzle me if it is cause by my patches.
No, it is *not* caused by your patches. It's been there before. The try build was just put here for reference which builds these stack traces were made from.
It is something else in our accessibility that's causing this crash when Nightly updates the profile to a new version.
Ah ok. My bad.
Can't reproduce :-(
Are we missing some default configuration for some config we've added?
I don't think. But I tried with a brand new profile on Aurora. And then upgrade to Nightly.
Just to make sure I'm clear. I tried with the Nightly build referenced in comment 2.
(In reply to Hub Figuiere [:hub] from comment #10) > Just to make sure I'm clear. I tried with the Nightly build referenced in > comment 2. Assuming it didn't reproduce I think it would be okay to close works for me. It can always be reopened.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.