Closed
Bug 333579
Opened 19 years ago
Closed 19 years ago
Firefox crash with Window-Eyes and DHTML/AJAX
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mdfft, Assigned: aaronlev)
References
(Blocks 1 open bug, )
Details
(Keywords: access, fixed1.8.1)
Attachments
(1 file)
|
4.45 KB,
patch
|
pilgrim
:
review+
neil
:
superreview+
dbaron
:
approval1.8.1+
|
Details | Diff | Splinter Review |
Env: WE 5.5b
FF gecko 20060406
The URL is http://www.datashelf.us/ticTacToe.html
Problem: If you play the game tictactoe with Window-Eyes 5.5 and then exit Firefox, Firefox will crash during the exit. I've sent a talkbacks relating to
this crash. While the game is playing it works great, but when you're done the problem occurs.
Steps to recreate: Start WE, start FF and load URL http://www.datashelf.us/ticTacToe.html.
Play game a few times and exit FF, you will notice that FF will crash. before exiting properly.
| Assignee | ||
Updated•19 years ago
|
Blocks: fox2access
| Assignee | ||
Updated•19 years ago
|
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
| Reporter | ||
Comment 1•19 years ago
|
||
The talkback incident ID is 17444683
Updated•19 years ago
|
Status: NEW → ASSIGNED
| Assignee | ||
Comment 2•19 years ago
|
||
Bill, I'm unable to get this to crash with Firefox 2 alphas. We've been checking in some crash and leak fixes, and might have already fixed it.
WFM
| Assignee | ||
Updated•19 years ago
|
No longer blocks: fox2access
| Assignee | ||
Comment 3•19 years ago
|
||
Talkback 17848815
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=17848815
Bill, are you in browse mode on or off when you are doing this?
| Reporter | ||
Comment 4•19 years ago
|
||
Update, I was in browse mode on when I saw this problem.
| Assignee | ||
Comment 5•19 years ago
|
||
Possibly related: bug 337167
Comment 6•19 years ago
|
||
Mark, I'm betting you meant to assign this to yourself, rather than to nobody@?
Assignee: nobody → pilgrim
Status: ASSIGNED → NEW
QA Contact: disability.access → accessibility-apis
Updated•19 years ago
|
Assignee: pilgrim → nobody
| Assignee | ||
Updated•19 years ago
|
Assignee: nobody → aaronleventhal
Blocks: fox2access
| Assignee | ||
Comment 7•19 years ago
|
||
Attachment #228812 -
Flags: review?(pilgrim)
Updated•19 years ago
|
Attachment #228812 -
Flags: review?(pilgrim) → review+
| Assignee | ||
Updated•19 years ago
|
Attachment #228812 -
Flags: superreview?(neil)
Comment 8•19 years ago
|
||
Comment on attachment 228812 [details] [diff] [review]
Two fixes for image map a11y: 1) Don't walk into maps so that areas don't show twice in a11y tree, 2) Don't refer to |this| in area constructor, Init() from outside as other accessibles do
>+ // Don't walk into maps, they take up no space.
>+ // The nsHTMLAreaAccessible's they contain are attached as
>+ // children of the appropriate nsHTMLImageAccessible.
So does this make the area frame check further on redundant?
> nsHTMLAreaAccessible::nsHTMLAreaAccessible(nsIDOMNode *aDomNode, nsIAccessible *aParent, nsIWeakReference* aShell):
> nsLinkableAccessible(aDomNode, aShell)
> {
>- Init(); // Make sure we're in cache
>- mParent = aParent;
> }
It took me some time to find another Init, and it turned up in nsHTMLTableHeadAccessible's constructor. Then I found one in nsXULTreeitemAccessible. Are these both wrong too? Are these different because they are creaated on demand, rather than via GetAccessible?
| Assignee | ||
Comment 9•19 years ago
|
||
(In reply to comment #8)
> (From update of attachment 228812 [details] [diff] [review] [edit])
> >+ // Don't walk into maps, they take up no space.
> >+ // The nsHTMLAreaAccessible's they contain are attached as
> >+ // children of the appropriate nsHTMLImageAccessible.
> So does this make the area frame check further on redundant?
Not redundant, because this method is called when a focus event goes to an <area> and will return the accessible from the cache for that.
> It took me some time to find another Init, and it turned up in
> nsHTMLTableHeadAccessible's constructor. Then I found one in
> nsXULTreeitemAccessible. Are these both wrong too?
Thanks. Yes, these are wrong because we should never refer to |this| in a constructor. Do you need a new patch with those removed or can I just fix them on checkin?
Comment 10•19 years ago
|
||
Comment on attachment 228812 [details] [diff] [review]
Two fixes for image map a11y: 1) Don't walk into maps so that areas don't show twice in a11y tree, 2) Don't refer to |this| in area constructor, Init() from outside as other accessibles do
I guess those other Init()s really belong in a separate bug.
Attachment #228812 -
Flags: superreview?(neil) → superreview+
| Assignee | ||
Updated•19 years ago
|
Flags: blocking1.8.1?
| Assignee | ||
Updated•19 years ago
|
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
| Assignee | ||
Updated•19 years ago
|
Attachment #228812 -
Flags: approval1.8.1?
Comment on attachment 228812 [details] [diff] [review]
Two fixes for image map a11y: 1) Don't walk into maps so that areas don't show twice in a11y tree, 2) Don't refer to |this| in area constructor, Init() from outside as other accessibles do
a=dbaron on behalf of drivers. Please check in to MOZILLA_1_8_BRANCH and marked fixed1.8.1 when you have done so.
Attachment #228812 -
Flags: approval1.8.1? → approval1.8.1+
Updated•19 years ago
|
Flags: blocking1.8.1? → blocking1.8.1+
| Assignee | ||
Updated•19 years ago
|
Keywords: fixed1.8.1
You need to log in
before you can comment on or make changes to this bug.
Description
•