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

RESOLVED FIXED in mozilla19

Status

()

Core
Disability Access APIs
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Jost Eckhardt, Ai Squared, Assigned: surkov)

Tracking

(Blocks: 1 bug)

unspecified
mozilla19
x86_64
Windows 7
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(8 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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

Updated

5 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

5 years ago
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.

Comment 3

5 years ago
(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.
(Assignee)

Comment 4

5 years ago
(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?
(Reporter)

Comment 5

5 years ago
yes 650241 covers it. Please consider all MSAA and IA2 interfaces, in and out coordinates.
(Assignee)

Comment 6

5 years ago
(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)

Comment 7

5 years ago
Created attachment 599667 [details] [diff] [review]
patch1:getChildAt v1
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #599667 - Flags: review?(marco.zehe)

Updated

5 years ago
Attachment #599667 - Flags: review?(marco.zehe) → review+
(Assignee)

Updated

5 years ago
Blocks: 659589
(Assignee)

Comment 8

5 years ago
patch1: getChildAt https://hg.mozilla.org/integration/mozilla-inbound/rev/796d3b448a94
Whiteboard: [don't mark fixed]

Comment 9

5 years ago
https://hg.mozilla.org/mozilla-central/rev/796d3b448a94
Target Milestone: --- → mozilla13
(Assignee)

Comment 10

5 years ago
Created attachment 608656 [details] [diff] [review]
part2:imagemap bounds
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+
(Assignee)

Comment 12

5 years ago
Created attachment 608731 [details] [diff] [review]
part3:XULtree_childAtPoint
Attachment #608731 - Flags: review?(marco.zehe)
(Assignee)

Updated

5 years ago
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+
(Assignee)

Comment 14

5 years ago
(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
(Assignee)

Comment 15

5 years ago
Created attachment 608785 [details] [diff] [review]
part3:XULtree childAtPoint:v2
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+
(Assignee)

Comment 18

5 years ago
(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
https://hg.mozilla.org/mozilla-central/rev/5a0fa83685d7
(Assignee)

Comment 20

5 years ago
Created attachment 671099 [details] [diff] [review]
part4: scrollToPoint and origin conversions
Attachment #671099 - Flags: review?(trev.saunders)
Attachment #671099 - Flags: feedback?(roc)
(Assignee)

Comment 21

5 years ago
Created attachment 671105 [details] [diff] [review]
part5: ISimpleDOMText::GetCharacterExtents
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 #671105 - Flags: feedback?(roc) → feedback+
(Assignee)

Comment 23

5 years ago
Created attachment 671322 [details] [diff] [review]
part6: getOffsetAtPoint
Attachment #671322 - Flags: review?(trev.saunders)
(Assignee)

Comment 24

5 years ago
(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)?
(Assignee)

Comment 25

5 years ago
Created attachment 671379 [details] [diff] [review]
part7: getRangeExtents
(Assignee)

Updated

5 years ago
Attachment #671379 - Attachment is patch: true
Attachment #671379 - Flags: review?(trev.saunders)
(Assignee)

Comment 26

5 years ago
Created attachment 671461 [details] [diff] [review]
part8: scrollSubstringToPoint
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+
(Assignee)

Comment 30

5 years ago
(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
(Assignee)

Comment 31

5 years ago
(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
(Assignee)

Comment 32

5 years ago
(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
(Assignee)

Comment 33

5 years ago
Comment on attachment 671099 [details] [diff] [review]
part4: scrollToPoint and origin conversions

http://hg.mozilla.org/integration/mozilla-inbound/rev/9394d94ea2b9
(Assignee)

Comment 34

5 years ago
Comment on attachment 671105 [details] [diff] [review]
part5: ISimpleDOMText::GetCharacterExtents

https://hg.mozilla.org/integration/mozilla-inbound/rev/cb0b143de3ae
https://hg.mozilla.org/mozilla-central/rev/9394d94ea2b9
Flags: in-testsuite+
(Assignee)

Comment 36

5 years ago
Comment on attachment 671322 [details] [diff] [review]
part6: getOffsetAtPoint

https://hg.mozilla.org/integration/mozilla-inbound/rev/a48b0c4084ba
(Assignee)

Comment 37

5 years ago
Comment on attachment 671379 [details] [diff] [review]
part7: getRangeExtents

https://hg.mozilla.org/integration/mozilla-inbound/rev/0cdf460897ea
https://hg.mozilla.org/mozilla-central/rev/cb0b143de3ae
https://hg.mozilla.org/mozilla-central/rev/a48b0c4084ba
https://hg.mozilla.org/mozilla-central/rev/0cdf460897ea
(Assignee)

Comment 39

5 years ago
Comment on attachment 671461 [details] [diff] [review]
part8: scrollSubstringToPoint

http://hg.mozilla.org/integration/mozilla-inbound/rev/6a24636cd4a2
(Assignee)

Updated

5 years ago
Whiteboard: [leave open]
https://hg.mozilla.org/mozilla-central/rev/6a24636cd4a2
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.