Crash on multitab dialog pages when JAWS is running.

RESOLVED FIXED

Status

()

Core
Disability Access APIs
--
critical
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: MarcoZ, Assigned: Aaron Leventhal)

Tracking

({access, crash, regression})

Trunk
x86
Windows XP
access, crash, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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.
(Assignee)

Updated

11 years ago
Blocks: 396346

Comment 1

11 years ago
This is fixed on the Jaws end in Jaws 9.
Is this something we should also fix on the Mozilla end?
(Assignee)

Comment 2

11 years ago
Tim, if there's a crash on our side it's always something we need to fix.
Keywords: regression
(Assignee)

Comment 3

11 years ago
Tim, BTW how do you know JAWS fixed something in JAWS 9 for this bug?

Comment 4

11 years ago
Able to reproduce with Jaws 8.0.1163.
Unable to reproduce with Jaws 9.0.335.
(Assignee)

Comment 5

11 years ago
Unable to reproduce with 8.0.2317U
(Assignee)

Comment 6

11 years ago
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.
Created attachment 282886 [details]
call stack copied from VS 2005

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.
(Assignee)

Comment 10

11 years ago
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.
(Assignee)

Comment 12

11 years ago
Surkov, can you reproduce the crash?
Assignee: aaronleventhal → surkov.alexander
(Assignee)

Comment 13

11 years ago
I can't repro with either sets of steps.

Comment 14

11 years ago
(In reply to comment #13)
> I can't repro with either sets of steps.
> 

I'm too with version 8.0.2173
(Assignee)

Comment 15

11 years ago
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.
(Assignee)

Comment 16

11 years ago
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.
(Assignee)

Comment 19

11 years ago
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.
(Assignee)

Comment 20

11 years ago
Created attachment 286050 [details] [diff] [review]
Refcounting fix -- this will probably fix a lot of other bugs as well as this

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 21

11 years ago
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+
(Assignee)

Updated

11 years ago
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.
(Assignee)

Comment 23

11 years ago
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+
(Assignee)

Updated

11 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED

Comment 25

11 years ago
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.

Comment 27

11 years ago
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
(Assignee)

Comment 28

11 years ago
Tim, can you reproduce it with the 9/19 build?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 29

11 years ago
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.

Comment 30

11 years ago
This appears to have regressed starting with 10-27-05.  Maybe  the original fix for this bug broke this?
(Assignee)

Comment 31

11 years ago
Tim, can you file a new bug and repaste the crash report link into that one? 
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED

Comment 32

11 years ago
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.