Closed Bug 118018 Opened 23 years ago Closed 23 years ago

Active Accessibility: Bounds values too large in some cases

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: dsirnapalli, Assigned: aaronlev)

Details

(Keywords: access)

Attachments

(1 file, 3 obsolete files)

This patch works as well; it's easier too understand but slower
(deleted), patch
dbaron
: review+
hewitt
: superreview+
Details | Diff | Splinter Review
<html> <title> nsIAccessible Interface Test Case </title> <body> <b><center> HTML Elements </center></b> <br> <!-- Test Table --> <table border cols=2 width="50%"> <caption>Test Table</caption> <tr> <td> Row1,Col1</td> <td> Row1,Col2</td> </tr> <tr> <td> Row2,Col1</td> <td> Row2,Col2</td> </tr> <tr> <td> Row3,Col1</td> <td> Row3,Col2</td> </tr> </table> </body> </html> ------------------------------- copy and open the above test case in mfcEmbed or Mozilla. Open mozInspect and click on Show highlight rectangle. Take the focus on to the table cells. The focus is not aligned with the cells as you see in IE.
Dharma, are you saying the yellow rectangle is showing up off by several pixels? I'm seeing that too. I think you'r confusing the term "focus". Focus means the keyboard focus, such as when you tab to a widget. The focus is where keyboard commands are sent to. For example, if you tab to a link it gets a dotted outline. The yellow outline in Inspect doesn't have anything to do with the current focus unless the Inspect tool reports "How found: focus". Usually it's showing the object under the mouse as in "How found: At point (x,y)".
Summary: Active Accessibility: Html Table Cells donot get focus correctly → Active Accessibility: Html Table Cells do not report bounds correctly
Ya, let me correct myself. Html Table cells donot report bounds correctly. Ya, the yellow rectangle when brought over the table cell is showing up off by several pixels.
Status: NEW → ASSIGNED
Keywords: access, fcc508
Priority: -- → P3
Target Milestone: --- → mozilla0.9.8
After further research, the bug only occurs when there is a <caption>
Summary: Active Accessibility: Html Table Cells do not report bounds correctly → Active Accessibility: Table with <caption> reports bounds incorrectly on cells
Also fixes bounds problem with select lists in bug 119278 The way we calculated the bounds errors we leading to x,y values that were too large in some cases. The problem was that we were sometimes adding values twice. In the first part of our calculation, we find the bounding frame for all the frames associated with the content node. Not only were we not doing a good job finding the bounding frame, but we were adding the x,y coordinates of the bounding frame relative to it's parent, before doing so again in part 2 of the calculation. Part 2 is where we move up throw the ancestors until we find a widget, adding to the x,y coodinates by finding where a each frame in that chain is located relative to it's parent. Some corrections in that code were also made, based on Hewitt's GetScreenOrigin code in the DOM Inespector.
Correction, this also fixes bug 112978
Summary: Active Accessibility: Table with <caption> reports bounds incorrectly on cells → Active Accessibility: Bounds values too large in some cases
*** Bug 112978 has been marked as a duplicate of this bug. ***
Whiteboard: seeking r=, sr=
After further testing, I found that I was having trouble getting it to correctly handle select lists and scrolled pages with the same code. This patch works, although before it gets reviewed I need to find out why.
Attachment #64711 - Attachment is obsolete: true
Whiteboard: seeking r=, sr= → trying to figure out why the new patch works
Attachment #64744 - Attachment is obsolete: true
Attachment #64721 - Attachment is obsolete: true
I've decided to obsolete the following patch: http://bugzilla.mozilla.org/attachment.cgi?id=64721&action=view After testing, I could see no speed difference, so I'd rather go with the patch where I understand why it works!
Whiteboard: trying to figure out why the new patch works → seeking r=, sr=
Comment on attachment 64746 [details] [diff] [review] This patch works as well; it's easier too understand but slower How does this handle things that scroll that are within the page (e.g., FRAMEs, IFRAMEs, things with 'overflow: scroll', SELECTs with SIZE > 1)? It looks like this would ignore scrolling offsets for all of these things. Perhaps you would want to QueryInterface the view for nsIScrollableView and call GetScrollPosition? (Would that work?)
David, it seems to work in those cases. I tested it with http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey When I scroll both the page and the seamonkey ports iframe, the bounds are still reported correctly for all of the elements on the page.
Comment on attachment 64746 [details] [diff] [review] This patch works as well; it's easier too understand but slower I don't really understand it, but whatever. r=dbaron
Attachment #64746 - Flags: review+
Comment on attachment 64746 [details] [diff] [review] This patch works as well; it's easier too understand but slower sr=hewitt
Attachment #64746 - Flags: superreview+
-> checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: seeking r=, sr=
Verified it in mozilla build, Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7+) Gecko/20020115 Works fine, Marking it as verified.
Status: RESOLVED → VERIFIED
QA Contact: doronr → dsirnapalli
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: