Summary: | AX: Hit testing not accounting for top content inset. | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Samuel White <samuel_white> | ||||
Component: | Accessibility | Assignee: | Samuel White <samuel_white> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | commit-queue, webkit-bug-importer | ||||
Priority: | P1 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Mac (Intel) | ||||||
OS: | OS X 10.9 | ||||||
Attachments: |
|
Description
Samuel White
2014-05-13 11:02:18 PDT
Created attachment 231396 [details]
Patch.
Any thoughts on testing this one? Not seeing a way to force DRT or TestRunner to HAVE a top content inset.
Attachment 231396 [details] did not pass style-queue:
ERROR: Source/WebKit2/WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm:202: The parameter name "page" adds no information, so it should be removed. [readability/parameter_name] [5]
Total errors found: 1 in 2 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 231396 [details] Patch. View in context: https://bugs.webkit.org/attachment.cgi?id=231396&action=review > Source/WebKit2/WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm:203 > + convertedPoint.move(0, -page->topContentInset()); is there only ever a Y contentInset? or is there also a x content inset we should account for (In reply to comment #4) > (From update of attachment 231396 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=231396&action=review > > > Source/WebKit2/WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm:203 > > + convertedPoint.move(0, -page->topContentInset()); > > is there only ever a Y contentInset? or is there also a x content inset we should account for That's a great question. The bug originated from a y-axis inset issue only and the exposed methods such as "topContentInset" have no matching bottom/left/right equivalents. I think we should focus this bug on just the top inset issue since it's the only manifestation we have thus far. Comment on attachment 231396 [details] Patch. View in context: https://bugs.webkit.org/attachment.cgi?id=231396&action=review >>> Source/WebKit2/WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm:203 >>> + convertedPoint.move(0, -page->topContentInset()); >> >> is there only ever a Y contentInset? or is there also a x content inset we should account for > > That's a great question. The bug originated from a y-axis inset issue only and the exposed methods such as "topContentInset" have no matching bottom/left/right equivalents. > > I think we should focus this bug on just the top inset issue since it's the only manifestation we have thus far. as long as there are no equivalent contentInset parameters, this seems ok (In reply to comment #6) > (From update of attachment 231396 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=231396&action=review > > >>> Source/WebKit2/WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm:203 > >>> + convertedPoint.move(0, -page->topContentInset()); > >> > >> is there only ever a Y contentInset? or is there also a x content inset we should account for > > > > That's a great question. The bug originated from a y-axis inset issue only and the exposed methods such as "topContentInset" have no matching bottom/left/right equivalents. > > > > I think we should focus this bug on just the top inset issue since it's the only manifestation we have thus far. > > as long as there are no equivalent contentInset parameters, this seems ok Thanks. I'll file a bug for the invalid style failure. style failure bug: https://bugs.webkit.org/show_bug.cgi?id=132887 Comment on attachment 231396 [details] Patch. Clearing flags on attachment: 231396 Committed r168745: <http://trac.webkit.org/changeset/168745> All reviewed patches have been landed. Closing bug. |