Closed Bug 495555 Opened 16 years ago Closed 7 years ago

Crash [@ nsAttrValue::ToString] with aria-labelledby, observes and groupbox

Categories

(Core :: Disability Access APIs, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: martijn.martijn, Unassigned)

Details

(Keywords: crash, regression, testcase, Whiteboard: [bk1])

Crash Data

Attachments

(3 files)

See testcase, which crashes current trunk build after 50ms. The testcase uses enhanced privileges, so you need to download it to your computer locally, probably, to be able to grant it the necessary privileges. It doesn't crash in Firefox 3. I can look for a regression range, if wanted. http://crash-stats.mozilla.com/report/index/d389801c-72bc-464e-a642-13cc12090529?p=1 0 xul.dll nsAttrValue::ToString content/base/src/nsAttrValue.cpp:339 1 xul.dll nsCoreUtils::GetElementsByIDRefsAttr accessible/src/base/nsCoreUtils.cpp:788 2 xul.dll nsCoreUtils::GetRoleContent accessible/src/base/nsCoreUtils.cpp:242
This stack looks very weird, but the line in "1" points at our work on making anonymous content accessible (bug 483573). However, Martijn's testcase uses regular controls, no anonymous content here.
Perhaps the patch from bug 391132 might give a clue on how to fix this.
Attached patch patch 1Splinter Review
Assignee: nobody → david.bolter
Status: NEW → ASSIGNED
Comment on attachment 380823 [details] [diff] [review] patch 1 Alex, I'm not sure if I'm correct in passing through to the 'described by' algorithm when there is no content. Thoughts? (Maybe better just to bail out)
Attachment #380823 - Flags: review?(surkov.alexander)
David, me either I do not understand how nsHTMLTableCellAccessible might be related with XUL-based testcase.
Attached file stack for testcase
I think this bug is much similar with bug 391132. Here we get also stack overflow because of @observe attribute I think.
Attachment #380823 - Flags: review?(surkov.alexander)
Comment on attachment 380823 [details] [diff] [review] patch 1 cancelling review
Woah, yeah... stack overflow. Not sure what bug I was fixing there.
Status: ASSIGNED → NEW
At least one problem here is that we have mutual recursion between: nsXULGroupboxAccessible::GetNameInternal (calling label->GetName(aName)) and nsAccessible::GetName (calling GetNameInternal(aName)). I believe this might be set up by the observes attribute. I'm not sure we need to guard against this edge case, since we can control our XUL to not set up this relationship?
(In reply to comment #9) > I believe this might be set up by the observes attribute. right > I'm not sure we need to guard against this edge case, since we can control our > XUL to not set up this relationship? sory, few additional details for the idea please
I'm not sure where to go with this bug.
Assignee: bolterbugz → nobody
the testcase crashes on nightlies but I don't see a11y involved, the stack is: ntdll.dll!77a1defe() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!77a1e275() ntdll.dll!77a1e0f2() msvcr90d.dll!69caff0e() nspr4.dll!PR_GetThreadPrivate(unsigned int index) Line 232 + 0x5 bytes C xul.dll!AssertActivityIsLegal() Line 168 + 0x15 bytes C++ xul.dll!NS_LogDtor_P(void * aPtr, const char * aType, unsigned int aInstanceSize) Line 1151 + 0x5 bytes C++ xul.dll!nsHashKey::~nsHashKey() Line 145 + 0x10 bytes C++ > xul.dll!nsXBLPrototypeBinding::nsIIDKey::~nsIIDKey() Line 247 + 0x18 bytes C++ 073d5788() we need somebody from content to look at it.
Olli, can you look at crash?
How do I test this on trunk?
(In reply to comment #14) > How do I test this on trunk? I put the testcase into extension (like DOM inspector and run it as chrome://inspector/content/testcasefilename.xul).
Crash Signature: [@ nsAttrValue::ToString]
Crash Signature: [@ nsAttrValue::ToString] → [@ nsAttrValue::ToString(nsAString_internal&)]
Crash Signature: [@ nsAttrValue::ToString(nsAString_internal&)] → [@ nsAttrValue::ToString(nsAString_internal&)] [@ nsAttrValue::ToString ]
I don't see recent sigs. Maybe fixed by Bug 731813 but I didn't dig too deeply.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I don't see a11y on stack of existing crashes, I guess we can close this 6 years old bug, since today's crashes are not related with the original report.
Status: REOPENED → RESOLVED
Closed: 13 years ago7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: