Closed Bug 432967 Opened 16 years ago Closed 16 years ago

WARNING: NS_ENSURE_TRUE(aContent) failed: file nsAccessibilityUtils.cpp, line 262

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.1a1

People

(Reporter: ginnchen+exoracle, Assigned: ginnchen+exoracle)

References

Details

(Whiteboard: [has-patch,has-review] post1.9)

Attachments

(1 file, 1 obsolete file)

patch
990 bytes, patch
aaronlev
: review+
Details | Diff | Splinter Review 
Stack is,
=>[1] nsAccUtils::HasListener(aContent = (nil), aEventType = CLASS), line 262 in "nsAccessibilityUtils.cpp"
  [2] nsAccessible::GetNumActions(this = 0xef216600, aNumActions = 0x8045c3d ""), line 2670 in "nsAccessible.cpp"
  [3] nsAccessibleWrap::CreateMaiInterfaces(this = 0xef216600), line 426 in "nsAccessibleWrap.cpp"
  [4] nsAccessibleWrap::GetNativeInterface(this = 0xef216600, aOutAccessible = 0x8045c9c), line 379 in "nsAccessibleWrap.cpp"

We should not call nsAccUtils::IsXLink() and nsAccUtils::HasListener() is content is null in nsAccessible::GetNumActions()

mDOMNode is nsHTMLDocument
Attached patch patch (obsolete) — — Splinter Review 
Not a big deal, but less warnings in console would help us on debugging.
Assignee: nobody → ginn.chen
Status: NEW → ASSIGNED
Attachment #320145 - Flags: review?(aaronleventhal)
Attachment #320145 - Flags: review?(aaronleventhal) → review+
Comment on attachment 320145 [details] [diff] [review]
patch

Ginn, actually for nsHTMLDocument I think we want to look at the <body>. So we need something like content=GetRoleContent(domNode);

Sometimes ARIA and other widgets will be implemented inside iframes, so it's not impossible that it would happen.
Ginn, would you like to change the patch to address Aaron's comment?
Attached patch patch — — Splinter Review 
addressing Aaron's comment
Attachment #320145 - Attachment is obsolete: true
Attachment #320501 - Flags: review?(aaronleventhal)
Attachment #320501 - Flags: review?(aaronleventhal) → review+
Marco, could you mark this bug by whiteboard or flags to not get lost it?
Flags: wanted1.9.0.x?
Whiteboard: [has-patch,has-review]
Whiteboard: [has-patch,has-review] → [has-patch,has-review] post1.9
Pushed to mozilla-central in changeset:
http://hg.mozilla.org/mozilla-central/index.cgi/rev/737426984af7.

Leaving open in case we are allowed to take this for 1.9.0.1. Or is this really desirable to want in Firefox 3.0.x, Ginn?
Setting to fixed in accordance with Sam#s post in mozilla.dev.planning. This landed on June 11 (see previous comment).
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a1
Ginn, Aaron: Do you want this in 1.9.0.x or can it wait until 1.9.1?
(In reply to comment #8)
> Ginn, Aaron: Do you want this in 1.9.0.x or can it wait until 1.9.1?
> 

I would guess it can wait until 1.9.1.

Marco?
Agreed. This bug is primarily there to reduce some assertion output, and thus most useful for debugging. Since the heavy-weight development takes place in 1.9.1, I don't see a need to get this into 1.9.0.x.
Let's get this in 1.9.1 then. Thanks guys.
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
Flags: blocking1.9.1?
(In reply to comment #11)
> Let's get this in 1.9.1 then. Thanks guys.
> 

We put the patch on the hg trunk (comment #6), so we can clear the flags I guess?
clearing flags
Flags: wanted1.9.1?
Flags: wanted1.9.0.x-
Flags: blocking1.9.1?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: