Closed Bug 366443 Opened 18 years ago Closed 18 years ago

Component::GetExtents() returns screen coordinates when ATK_XY_WINDOW passed in

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: parente, Assigned: aaronlev)

References

()

Details

Attachments

(3 files)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061218 Minefield/3.0a1 Background According to the AT-SPI IDL doc, the coordType parameter to getOffsetAtPoint behaves as follows: "if 1, they [the x,y values] are relative to the toplevel window containing this Text object." 1) Open the attached test page. 2) Resize it so the paragraph soft wraps across a few visual lines. 3) Use Component::getExtents(1) to get the window-relative x,y,w,h for the paragraph. 4) Use Text::getTextAtOffset(x, y, 1) to get the offset of the character in the upper left corner of the paragraph. Result: -1 is returned. 5) Use Text::getTextAtOffset(x+3, y+3, 1) to move in a few pixels to make sure the character isn't being missed because it's on the border. Result: -1 is returned. 6) Use Text::getTextAtOffset(0, 0, 1) in case the method expects coords relative to the Text box boundary (contrary to the AT-SPI IDL statement). Result: -1 is returned. Guessing some random x,y values I can get it to return some offset into the text, but the basis for the numbers that actually work is unknown. This is a problem for screen readers that need to determine whether part of an item is obscured on the screen by the edge of the HTML pane.
Firefox returns screen coordinates for Component::getExtents(1) when window coordinates are requested. Component::getExtents(0) returns the correct values when screen coordinates are requested
Peter, could the problem actually be with Component::getExtents(1)? It sounds like that's what Scott Haeger is saying.
Summary: Text::getOffsetAtPoint has different basis → Component::GetExtents() returns screen coordinates when ATK_XY_WINDOW passed in
Attached patch Needs testingSplinter Review
Aaron, yes. The problem is with Component::getExtents(1).
Attachment #251525 - Flags: review?(ginn.chen) → review+
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: