Closed Bug 387347 Opened 14 years ago Closed 14 years ago

Text with "float" style inaccessible effective 2007070605 build

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: jdiggs, Assigned: ginnchen+exoracle)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(4 files, 1 obsolete file)

Attached file test case
Steps to reproduce:

1. Open the attached test case
2. Use Accerciser to examine the children of the document frame

Prior to the 2007070605 build, you will find three children:  The first and third paragraphs have ROLE_PARAGRAPH; the second has ROLE_TEXT.  Beginning with the 2007070605 build, the second paragraph is completely absent from the hierarchy.
Attached file test case 2
Another test case which shows that the problem may lie with the 'position' attribute.  This test case shows that removing 'position:absolute' will also destroy the hierarchy.  The original broken case can be found here http://www.mozilla.org/access/dhtml/class/tabpanel
Thanks for reporting this!

I met this problem with Mozilla project page a few days ago.
Severity: normal → critical
The regression is gone if I back out following piece. It's in bug 377783

accessible/src/base/nsAccessibilityService.cpp

@@ -1367,10 +1384,14 @@ NS_IMETHODIMP nsAccessibilityService::Ge
         }
       }
     }
 
     if (tryFrame) {
+      if (frame->GetRect().IsEmpty()) {
+        *aIsHidden = PR_TRUE;
+        return NS_OK;
+      }
       frame->GetAccessible(getter_AddRefs(newAcc)); // Try using frame to do it
     }
   }
 
   if (!newAcc) {
Attached patch patch (obsolete) — Splinter Review
GetRect doesn't reliable for nsPlaceholderFrame 

Can we back out this hunk?
Assignee: aaronleventhal → ginn.chen
Status: NEW → ASSIGNED
Attachment #271644 - Flags: review?(aaronleventhal)
If we just simply back out this, invisible <caption>s in html table will be wrongly created.
Then should we check empty Rect in nsTableCaptionFrame::GetAccessible?
I think we already checked that in nsTableCaptionFrame::GetAccessible.
Comment on attachment 271644 [details] [diff] [review]
patch

As Evan says, we should just do the check for captions now.

But, we need to do it so that *aIsHidden is set to TRUE, because that also prevents the children from getting accessibles created (the whole subtree is skipped when *aIsHidden = PR_TRUE -- it's an out param).
Comment on attachment 271644 [details] [diff] [review]
patch

Would this work?

if (frame->GetRect().IsEmpty() && !placeholderframe) {
  *aIsHidden = PR_TRUE; return NS_OK;
}
Attachment #271644 - Flags: review?(aaronleventhal) → review-
Attached patch patch v2Splinter Review
Attachment #271644 - Attachment is obsolete: true
Attachment #272454 - Flags: review?(aaronleventhal)
Attachment #272454 - Flags: review?(aaronleventhal) → review+
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
The patch didn't solve
411.com and
http://www.sfgate.com/cgi-bin/article.cgi?f=/chronicle/archive/2007/07/29/SP13R95O71.DTL

frame is nsBlockFrame
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Let's do a blacklist rather than whitelist, ok?
Attachment #275749 - Flags: review?(aaronleventhal)
Attachment #275749 - Flags: review?(aaronleventhal) → review+
Please add a comment why we do this for table caption frame, something like:

// Do not create accessible object subtrees for non-rendered table captions. This could not be done in nsTableCaptionFrame::GetAccessible() because the descendants of the table caption would still be created. By setting *aIsHidden = PR_TRUE we ensure that no descendant accessibles are created
Attachment #275749 - Flags: approval1.9?
Attachment #275749 - Flags: approval1.9? → approval1.9+
Checked in with added comment.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
I believe this fixed bug 390670 as well.
You need to log in before you can comment on or make changes to this bug.