Closed Bug 727942 Opened 13 years ago Closed 12 years ago

Windows app can't read Firefox setting for "zoom level"

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla19

People

(Reporter: jeckhardt, Assigned: surkov)

References

(Blocks 1 open bug)

Details

Attachments

(8 files, 1 obsolete file)

patch1:getChildAt v1
7.70 KB, patch
MarcoZ
: review+
Details | Diff | Splinter Review
part2:imagemap bounds
9.57 KB, patch
MarcoZ
: review+
Details | Diff | Splinter Review
part3:XULtree childAtPoint:v2
19.30 KB, patch
MarcoZ
: review+
Details | Diff | Splinter Review
part4: scrollToPoint and origin conversions
14.89 KB, patch
tbsaunde
: review+
roc
: feedback+
Details | Diff | Splinter Review
part5: ISimpleDOMText::GetCharacterExtents
2.43 KB, patch
tbsaunde
: review+
roc
: feedback+
Details | Diff | Splinter Review
part6: getOffsetAtPoint
6.61 KB, patch
tbsaunde
: review+
Details | Diff | Splinter Review
part7: getRangeExtents
7.11 KB, patch
tbsaunde
: review+
Details | Diff | Splinter Review
part8: scrollSubstringToPoint
11.39 KB, patch
tbsaunde
: review+
Details | Diff | Splinter Review
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0 Build ID: 20120208012847 Steps to reproduce: I'm trying to determine from a Windows app what the zoom level in Firefox is Actual results: I can't find documentation about an available interface Expected results: I need an interface to read the current "zoom level" setting
Filing this in accessibility for initial triage.
Component: Untriaged → Disability Access APIs
Product: Firefox → Core
QA Contact: untriaged → accessibility-apis
Version: 11 Branch → unspecified
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually what I need is to translate between coordinates given by IAccessible2 and coordinates rendered by Firefox. With the IE DOM you can use IHTMLScreen2 and then calculate the offset using logical and device dpi.
(In reply to Jost Eckhardt, Ai Squared from comment #2) > Actually what I need is to translate between coordinates given by > IAccessible2 and coordinates rendered by Firefox. Imo, the coordinates returned from accessibility APIs should always reflect the on-screen rendering. That is, when zoom level changes, the coordinates should change too. This is covered by bug 650241.
(In reply to James Teh [:Jamie] from comment #3) > (In reply to Jost Eckhardt, Ai Squared from comment #2) > > Actually what I need is to translate between coordinates given by > > IAccessible2 and coordinates rendered by Firefox. > Imo, the coordinates returned from accessibility APIs should always reflect > the on-screen rendering. That is, when zoom level changes, the coordinates > should change too. This is covered by bug 650241. Jost, does it cover your problem?
yes 650241 covers it. Please consider all MSAA and IA2 interfaces, in and out coordinates.
(In reply to Jost Eckhardt, Ai Squared from comment #5) > yes 650241 covers it. Please consider all MSAA and IA2 interfaces, in and > out coordinates. right, I see that we have other issues
Depends on: 650241
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #599667 - Flags: review?(marco.zehe)
Attachment #599667 - Flags: review?(marco.zehe) → review+
Blocks: boundsa11y
patch1: getChildAt https://hg.mozilla.org/integration/mozilla-inbound/rev/796d3b448a94
Whiteboard: [don't mark fixed]
Attachment #608656 - Flags: review?(marco.zehe)
Comment on attachment 608656 [details] [diff] [review] part2:imagemap bounds r=me. Thanks for the cleanup and the better use of the APIs available!
Attachment #608656 - Flags: review?(marco.zehe) → review+
Attached patch part3:XULtree_childAtPoint (obsolete) — — Splinter Review
Attachment #608731 - Flags: review?(marco.zehe)
Attachment #608731 - Attachment is patch: true
Comment on attachment 608731 [details] [diff] [review] part3:XULtree_childAtPoint r=me.
Attachment #608731 - Flags: review?(marco.zehe) → review+
Attachment #608731 - Attachment is obsolete: true
Attachment #608785 - Flags: review?(marco.zehe)
(In reply to alexander :surkov from comment #14) > (In reply to alexander :surkov from comment #10) > > Created attachment 608656 [details] [diff] [review] > > part2:imagemap bounds > > https://hg.mozilla.org/integration/mozilla-inbound/rev/a5f39c72791d https://hg.mozilla.org/mozilla-central/rev/a5f39c72791d
Whiteboard: [don't mark fixed] → [leave open]
Target Milestone: mozilla13 → ---
Comment on attachment 608785 [details] [diff] [review] part3:XULtree childAtPoint:v2 r=me
Attachment #608785 - Flags: review?(marco.zehe) → review+
(In reply to alexander :surkov from comment #15) > Created attachment 608785 [details] [diff] [review] > part3:XULtree childAtPoint:v2 https://hg.mozilla.org/integration/mozilla-inbound/rev/5a0fa83685d7
Attachment #671099 - Flags: review?(trev.saunders)
Attachment #671099 - Flags: feedback?(roc)
Attachment #671105 - Flags: review?(trev.saunders)
Attachment #671105 - Flags: feedback?(roc)
Comment on attachment 671099 [details] [diff] [review] part4: scrollToPoint and origin conversions Review of attachment 671099 [details] [diff] [review]: ----------------------------------------------------------------- Looks OK, but do you care about Mac in HiDPI mode? On Mac in HiDPI mode, apps tend to use not device pixels but "Cocoa points", which in HiDPI mode are 2 device pixels each.
Attachment #671099 - Flags: feedback?(roc) → feedback+
Attachment #671322 - Flags: review?(trev.saunders)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #22) > Looks OK, but do you care about Mac in HiDPI mode? On Mac in HiDPI mode, > apps tend to use not device pixels but "Cocoa points", which in HiDPI mode > are 2 device pixels each. I don't know, maybe Hub knows. Are there any conversion function to use or should I just multiply at 2 (in case if need it)?
Attachment #671379 - Attachment is patch: true
Attachment #671379 - Flags: review?(trev.saunders)
Attachment #671461 - Flags: review?(trev.saunders)
Comment on attachment 671099 [details] [diff] [review] part4: scrollToPoint and origin conversions >+ // scrollToPoint relative screen >+ var anchor = getAccessible("bottom1"); >+ var [x, y] = getPos(anchor); >+ var [docX, docY] = getPos(document); >+ >+ anchor.scrollToPoint(COORDTYPE_SCREEN_RELATIVE, docX, docY); >+ testPos(anchor, [x, docY]); I'm not sure I completely understand why this is [x, docY] not docX, docY I don't think I'm a particularly good person to review this stuff, but it seems fine, so r=me assuming the tests are all happy with you
Attachment #671099 - Flags: review?(trev.saunders) → review+
Attachment #671105 - Flags: review?(trev.saunders) → review+
Comment on attachment 671322 [details] [diff] [review] part6: getOffsetAtPoint is the scrolling in part 4, and the zoom() you use in a bunch of these test really sync? If not we need to add stuff to make sure the test waits until the action is complete before running. Otherwise this seems fine.
Attachment #671322 - Flags: review?(trev.saunders) → review+
Comment on attachment 671379 [details] [diff] [review] part7: getRangeExtents I think this patch depends on a file you add in the next patch unless it just got lost completely, so please fold these patches together when you land so we don't have a commit in the tree that doesn't build
Attachment #671379 - Flags: review?(trev.saunders) → review+
Attachment #671461 - Flags: review?(trev.saunders) → review+
(In reply to Trevor Saunders (:tbsaunde) from comment #27) > Comment on attachment 671099 [details] [diff] [review] > part4: scrollToPoint and origin conversions > > >+ // scrollToPoint relative screen > >+ var anchor = getAccessible("bottom1"); > >+ var [x, y] = getPos(anchor); > >+ var [docX, docY] = getPos(document); > >+ > >+ anchor.scrollToPoint(COORDTYPE_SCREEN_RELATIVE, docX, docY); > >+ testPos(anchor, [x, docY]); > > I'm not sure I completely understand why this is [x, docY] not docX, docY there's no horizontal scrollbar so scrolling doesn't happen in horizontal direction and thus x isn't changed
(In reply to Trevor Saunders (:tbsaunde) from comment #28) > Comment on attachment 671322 [details] [diff] [review] > part6: getOffsetAtPoint > > is the scrolling in part 4, and the zoom() you use in a bunch of these test > really sync? If not we need to add stuff to make sure the test waits until > the action is complete before running. yes, they seems to be sync
(In reply to Trevor Saunders (:tbsaunde) from comment #29) > Comment on attachment 671379 [details] [diff] [review] > part7: getRangeExtents > > I think this patch depends on a file you add in the next patch unless it > just got lost completely, so please fold these patches together when you > land so we don't have a commit in the tree that doesn't build I forgot to hg add on new test file
Whiteboard: [leave open]
https://hg.mozilla.org/mozilla-central/rev/6a24636cd4a2
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: