Closed Bug 454211 Opened 13 years ago Closed 13 years ago

ISimpleDOMNode functions get_computedStyleForProperties and get_computedStyle functions appear to always return the COM error code 0x80004005 (E_FAIL)

Categories

(Core :: Disability Access APIs, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: MarcoZ, Assigned: surkov)

References

Details

(Keywords: access, verified1.9.0.5, Whiteboard: [needs baking])

Attachments

(2 files, 1 obsolete file)

Report from GWMicro with both Firefox 3.0.1 and 3.0.3pre.
Flags: blocking1.9.0.3?
Keywords: access
It will return E_FAIL on text nodes, on document. Otherwise it should be ok. How can I test this?
previously it worked on text nodes as well (but the current behaviour is from bug 275010, 2006-07-24).
This is a problem for us because our just released version won't be able to reflect the new definition of needing to consult the parent of text.

We use this method to give our users access to the character attributes of text such as point size, character weight, color etc.

I was hoping that the new features of Firefox 3 wouldn't cause loss of functionality to our accessibility code.

If the parent always has the correct information, is it difficult to notice that the call is on the text node case and forward the request to the parent?
Will, of course it's not difficult.  The main thing I concern if the problem is these methods fail on text nodes, no more. That's I was need to know. Thanks.
Assignee: nobody → surkov.alexander
Attached patch patch (obsolete) — Splinter Review
Attachment #339019 - Flags: review?(aaronleventhal)
Attachment #339019 - Flags: review?(marco.zehe)
Comment on attachment 339019 [details] [diff] [review]
patch

>+      // text child of html:span element
>+      acc = acc.firstChild.QueryInterface(nsIAccessNode);

Nit: Please protect against possible exceptions here.
With that, r=me for the test.
Attachment #339019 - Flags: review?(marco.zehe) → review+
Attached patch patch2Splinter Review
with Marco's comment
Attachment #339019 - Attachment is obsolete: true
Attachment #339021 - Flags: review?(aaronleventhal)
Attachment #339019 - Flags: review?(aaronleventhal)
Attachment #339021 - Flags: review?(aaronleventhal) → review+
Comment on attachment 339021 [details] [diff] [review]
patch2

One more thing: Could you replace the hardcoded RGB value you compare against with the computed style as shown in accessible/tests/mochitest/test_textattrs.html?
Ok, I will
Status: NEW → ASSIGNED
Comment on attachment 339021 [details] [diff] [review]
patch2

needed to improve firefox compatibility with screen readers, it's a regression, includes mochitest
Attachment #339021 - Flags: approval1.9.0.3?
Not "blocking" a branch release but we'll look at the patch. This appears to be fixed in mozilla-central, marking FIXED. (for branch we use keywords, or clone bugs).
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: blocking1.9.0.4? → blocking1.9.0.4-
Resolution: --- → FIXED
Whiteboard: [needs baking]
Attachment #339021 - Flags: approval1.9.0.4? → approval1.9.0.5?
Comment on attachment 339021 [details] [diff] [review]
patch2

we need to bring in the 3.0.4 schedule, bumping to next release.

I'm not sure we're going to be comfortable taking accessibility changes on the stable branch when 3.1 is going to be available soon.
Comment on attachment 339021 [details] [diff] [review]
patch2

Approved for 1.9.0.5, a=dveditz for release-drivers
Attachment #339021 - Flags: approval1.9.0.5? → approval1.9.0.5+
Depends on: 463983
Checking in accessible/src/base/nsAccessNode.cpp;
/cvsroot/mozilla/accessible/src/base/nsAccessNode.cpp,v  <--  nsAccessNode.cpp
new revision: 1.81; previous revision: 1.80
done
Checking in accessible/src/base/nsAccessNode.h;
/cvsroot/mozilla/accessible/src/base/nsAccessNode.h,v  <--  nsAccessNode.h
new revision: 1.50; previous revision: 1.49
done
Checking in accessible/src/base/nsAccessibilityUtils.cpp;
/cvsroot/mozilla/accessible/src/base/nsAccessibilityUtils.cpp,v  <--  nsAccessibilityUtils.cpp
new revision: 1.34; previous revision: 1.33
done
Checking in accessible/src/base/nsAccessibilityUtils.h;
/cvsroot/mozilla/accessible/src/base/nsAccessibilityUtils.h,v  <--  nsAccessibilityUtils.h
new revision: 1.27; previous revision: 1.26
done
Checking in accessible/src/html/nsHTMLTableAccessible.cpp;
/cvsroot/mozilla/accessible/src/html/nsHTMLTableAccessible.cpp,v  <--  nsHTMLTableAccessible.cpp
new revision: 1.66; previous revision: 1.65
done
Checking in accessible/src/msaa/nsAccessNodeWrap.cpp;
/cvsroot/mozilla/accessible/src/msaa/nsAccessNodeWrap.cpp,v  <--  nsAccessNodeWrap.cpp
new revision: 1.46; previous revision: 1.45
done
Checking in accessible/tests/mochitest/Makefile.in;
/cvsroot/mozilla/accessible/tests/mochitest/Makefile.in,v  <--  Makefile.in
new revision: 1.24; previous revision: 1.23
done
RCS file: /cvsroot/mozilla/accessible/tests/mochitest/test_nsIAccessNode_utils.html,v
done
Checking in accessible/tests/mochitest/test_nsIAccessNode_utils.html;
/cvsroot/mozilla/accessible/tests/mochitest/test_nsIAccessNode_utils.html,v  <--  test_nsIAccessNode_utils.html
initial revision: 1.1
done
Keywords: fixed1.9.0.5
I had to port nsCoreUtils::GetDomElementFor to nsAccUtils::GetDomElementFor to get this patch to compile under 1.9.0.5. This patch is being attached for informational purposes.
Verified fixed on 1.9.0 branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
You need to log in before you can comment on or make changes to this bug.