Closed Bug 397266 Opened 17 years ago Closed 17 years ago

Crash on multitab dialog pages when JAWS is running.

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: MarcoZ, Assigned: aaronlev)

References

Details

(Keywords: access, crash, regression)

Attachments

(2 files)

call stack copied from VS 2005
12.33 KB, text/plain
Details
Refcounting fix -- this will probably fix a lot of other bugs as well as this
1.94 KB, patch
surkov
: review+
mconnor
: approvalM9+
mconnor
: approval1.9+
Details | Diff | Splinter Review 
Steps to reproduce:
1. Start JAWS, then Minefield.
2. Go to Tools/Options...
3. Press RIGHT ARROW until you get to the "Advanced" item.
4. Press TAB. You'll land on the "General" tab control.
5. Press TAB again. You'll land on the first control within the Accessibility groupbox.
6. Press SHIFT+TAB.

Result: Crash like this: http://crash-stats.mozilla.com/report/index/f6bc7542-69f7-11dc-a16c-001a4bd43e5c?date=2007-09-23-17

Reproducible: Always

This also happens in Thunderbird and Sunbird, but only on those dialog pages that have multiple tabs.
Blocks: fox3access
This is fixed on the Jaws end in Jaws 9.
Is this something we should also fix on the Mozilla end?

Tim, if there's a crash on our side it's always something we need to fix.
Keywords: regression
Tim, BTW how do you know JAWS fixed something in JAWS 9 for this bug?
Able to reproduce with Jaws 8.0.1163.
Unable to reproduce with Jaws 9.0.335.

Unable to reproduce with 8.0.2317U
Since I can't reproduce this, a regression range would be very helpful.
(In reply to comment #6)
> Since I can't reproduce this, a regression range would be very helpful.

This started happening on 2007-09-19 trunk builds. This is the day after the big number of accessibility fixes got in.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-09-18+00%3A00&maxdate=2007-09-19+08%3A00&cvsroot=%2Fcvsroot
I just noticed the following, while testing something completely different: In the Page Setup dialog, I also get the crash, but only if I traverse the TAB controls once. So:
1. Open the Page Setup dialog in Firefox or Thunderbird.
2. You land on the Orientation radiogroup, with the first radio button being selected.
3. Now, tab around the dialog to the OK button, and shift tab back to the radio group.
4. Press ESCAPE.

Result: No crash.

5. Open the dialog again.
6. Tab around the dialog full circle. This includes the TAB controls.
7. Hit ESCAPE.

Result: Crash.
This shows a call stack from the Thunderbird crash after leavin the Page Setup dialog (see previous comment for steps). I reproduced this five times, and always land on the same line.
Thanks Marco. This shows that it's another cache corruption bug. Surkov just fixed a similar one on 9/28. Have you updated your build since then?
(In reply to comment #10)
> Thanks Marco. This shows that it's another cache corruption bug. Surkov just
> fixed a similar one on 9/28. Have you updated your build since then?

Yes, the stack trace was done on Sunday morning 9/30 with the latest source.
Surkov, can you reproduce the crash?
Assignee: aaronleventhal → surkov.alexander
I can't repro with either sets of steps.
(In reply to comment #13)
> I can't repro with either sets of steps.
> 

I'm too with version 8.0.2173
Surkov, we found out that it crashes only if you have the JAWS Braille Viewer running alongside JAWS. You can find it in your JAWS folder in your start menu.
Darn, I can't reproduce this anymore again. I wanted to test the latest patch in bug 398021 against it.
Another way to crash Minefield reliably for me is the following:
1. Open Minefield. If it doesn't go to the start page by default, open any page.
2. Press Control+T to open a new tab.
3. Enter www.google.com (or any page of your liking) into the Location field.
4. After the page loads, press Control+L to go back to the location bar.
5. Press TAB twice to get to the tab strip.

Result: After a few seconds, Minefield vanishes. It completely unloads from memory, does not give a Crash Reporter window or a "Just-In-Time-Debugger" message, it simply goes away.

Note this is with JAWS 8.0 and Braille on Windows. JAWS and Braille Viewer should be sufficient if you don't have a braille display at hand.

One more indication that something is going wrong sometimes happens, before an actual crash:
1. Open Tools/Options, select Advanced.
2. In my case, the Encryption tab is now selected. Tab once to get onto the tabs.
3. Tab again. Focus lands in the "Protocols" group, on the "SSL 3.0" checkbox.
4. Shift+Tab back to the tabs.

Result: If it doesn't crash, the "Encryption" tab's label is now suddenly called "Protocols". In essence, it receives the caption of the groupbox I was just in.

Once this happens, I'm guaranteed to crash on the next keypress.
Because this only happens with Braille I suspect it's a regression from bug 395081 -- it changes AccessibleObjectFromPoint() which only seems to be called by JAWS when Braille is used. I see a refcounting error that would affect XUL tabs, HTML areas and other things.
Marco, can you check to see if this fixes the problem?
Assignee: surkov.alexander → aaronleventhal
Status: NEW → ASSIGNED
Attachment #286050 - Flags: review?(surkov.alexander)
Comment on attachment 286050 [details] [diff] [review]
Refcounting fix -- this will probably fix a lot of other bugs as well as this

r=me, please add NS_ENSURE_ARG_POINTER
Attachment #286050 - Flags: review?(surkov.alexander) → review+
Attachment #286050 - Flags: approval1.9?
Tested with both Firefox and Thunderbird, and can confirm that all instances of crashes are gone! Highly recommend getting this into m9 if possible, since this will bite each and every user of JAWS (and possibly other screen readers) with braille around the world.
Comment on attachment 286050 [details] [diff] [review]
Refcounting fix -- this will probably fix a lot of other bugs as well as this

This is causing more crashes than just in XUL tabs. We have other accessibles that would be affected as well. And, on Linux, Orca uses this method even when Braille is not active. ZoomText may use it as well.
Attachment #286050 - Flags: approvalM9?
Comment on attachment 286050 [details] [diff] [review]
Refcounting fix -- this will probably fix a lot of other bugs as well as this

a=endgame drivers for checkin to M9
Attachment #286050 - Flags: approvalM9?
Attachment #286050 - Flags: approvalM9+
Attachment #286050 - Flags: approval1.9?
Attachment #286050 - Flags: approval1.9+
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
I can still get a crash with Window-eyes if I:
1. Activate the options dialog, starting on the main tab.
2. Arrow over to the content tab.
3. Tab through the resulting page.
Exactly when it crashes is a bit inconsistent, but I get a crash 100% of the time.


Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007103103 Minefield/3.0a9pre

(In reply to comment #25)
> I can still get a crash with Window-eyes if I:
> 1. Activate the options dialog, starting on the main tab.
> 2. Arrow over to the content tab.
> 3. Tab through the resulting page.
> Exactly when it crashes is a bit inconsistent, but I get a crash 100% of the
> time.

I cannot reproduce this. And since the Content item does not have multiple tabs, this sounds like a different issue to me. Tim, can you check if this also happens with the 2007-09-18 build? The day after this was the day this particular bug was introduced.
I cannot reporduce this with the 09-18 build.
Note that the content tab isn't the only tab that crashes--it's simply the one that's easiest to reproduce.  Here's a crash url:
http://crash-stats.mozilla.com/report/index/dbb7aa4f-87f7-11dc-9290-001a4bd43e5c?date=2007-10-31-21
Tim, can you reproduce it with the 9/19 build?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
No I can't.  Using 09-19-04.    Perhaps this is a different issue.

Note that I had someone install a clean copy of Minefield 10-31-03 on their system with WE 6.1 and they were able to reproduce it.

This appears to have regressed starting with 10-27-05.  Maybe  the original fix for this bug broke this?
Tim, can you file a new bug and repaste the crash report link into that one?
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
This works for me using the latest trunk and beta 1 RC3.  
Verifying...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: