Closed Bug 656089 Opened 10 years ago Closed 10 years ago

Windows magnifier tool doesn't focus correctly when there is a text editing at firefox 4

Categories

(Core :: Disability Access APIs, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla6

People

(Reporter: fredy, Assigned: jimm)

References

(Blocks 1 open bug)

Details

(Keywords: regression, reproducible)

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

The magnifier tool helps people with vision problems to magnify the screen and it is vital to focus properly. This doesn't happen when the magnifier option "Follow text editing" is on and there is text editing at firefox 4.

Reproducible: Always

Steps to Reproduce:
1. Open magnifier tool from Start menu-> Programs -> Accessories ->  Accessibility -> Magnifier.
2. Change the height of magnifier window so it can be viewed only one line.
3. Be sure that the option "Follow text editing" at the magnifiers settings is enabled (ticked).
4. Open firefox and click at URL address field at the navigation toolbar.
5. Start typing at the url field.
6. The magnifier window focus is now under this field and not at the field.

Actual Results:  
The focus at firefox 4 when there is text editing is under the text that it should be focused on.

Expected Results:  
The focus at firefox 4 when there is text editing to be at the text that is being edited.

If the "Follow text editing" is not selected (enabled/ticked) then the problem doesn't exist.

This problem occur not only at firefox user interface but also at web pages where you can edit text (like text form fields).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Alice, I'm not 100% sure this is a dupe.

Alfredos-Panagiotis, thanks for filing. Can you try changing this in your about:config settings:
gfx.direct2d.disabled true

I'm curious if this has to do with the caret not automatically following our direct write calls.
(In reply to comment #2)
> Alice, I'm not 100% sure this is a dupe.
> 
> Alfredos-Panagiotis, thanks for filing. Can you try changing this in your
> about:config settings:
> gfx.direct2d.disabled true
> 
> I'm curious if this has to do with the caret not automatically following our
> direct write calls.

Either true or false the bug still exists. :(
Summary: Windows magnifier tool doesn't focus correctly when there is a text editing in firefox 4 → Windows magnifier tool doesn't focus correctly when there is a text editing at firefox 4
Alice it sounds to me the same or a too similar bug. I have tried safe mode that it is suggested at that other bug and I have not seen any difference.
Confirmed with disabled auto hide MenuBar on
http://hg.mozilla.org/mozilla-central/rev/e0f6db50231f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110510 Firefox/6.0a1 ID:20110510030615

If Enable App Button(i.e enabled auto hide MenuBar), it works properly.
Regression window(cached m-c nightly):
Works:
http://hg.mozilla.org/mozilla-central/rev/522df66198cf
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100624 Minefield/3.7a6pre ID:20100624185700
Fails:
http://hg.mozilla.org/mozilla-central/rev/51bd519736c4
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100624 Minefield/3.7a6pre ID:20100624221810
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=522df66198cf&tochange=51bd519736c4
Blocks: 513162, 555081
Keywords: regression
Duplicate of this bug: 648863
Hmm, maybe I've not done this right, but it seems to be working for me on Win7. I have "fallow the text insertion point" checked in the magnifier options. When I click on the address bar and type, the magnifier window fallows the cursor. Attaching a screen shot...
Attached image mag pic (obsolete) —
(In reply to comment #8)
> Hmm, maybe I've not done this right, but it seems to be working for me on
> Win7. I have "fallow the text insertion point" checked in the magnifier
> options. When I click on the address bar and type, the magnifier window
> fallows the cursor. Attaching a screen shot...

bleh: fallows -> follows. brain short circuit.
At windows XP is what Alice said that if you hide the menu bar and have the firefox orange button (App Button) everything works fine but if you have the menu bar then the bug shows up.
(In reply to comment #8)
> Hmm, maybe I've not done this right, but it seems to be working for me on
> Win7. I have "fallow the text insertion point" checked in the magnifier
> options. When I click on the address bar and type, the magnifier window
> fallows the cursor. Attaching a screen shot...

You should _Disable_ Auto Hide MenuBar. 
i.e, Check MenuBar in View > Toolbars > Check MenuBar
(In reply to comment #12)
> (In reply to comment #8)
> > Hmm, maybe I've not done this right, but it seems to be working for me on
> > Win7. I have "fallow the text insertion point" checked in the magnifier
> > options. When I click on the address bar and type, the magnifier window
> > fallows the cursor. Attaching a screen shot...
> 
> You should _Disable_ Auto Hide MenuBar. 
> i.e, Check MenuBar in View > Toolbars > Check MenuBar

Ok, thanks Alice, I can reproduce.
Hmm, not sure what the magnifier is doing here. The sdk accessibility inspector doesn't have any trouble matching up the bounding rect of text edits, so it doesn't appear to be an accessibility api problem.
(In reply to comment #14)
> Hmm, not sure what the magnifier is doing here. The sdk accessibility
> inspector doesn't have any trouble matching up the bounding rect of text
> edits, so it doesn't appear to be an accessibility api problem.

Although, magnifier does appear to be using accessibility apis for it's information.
As mentioned already on Bug 648863 (I'd say it's exactly the same problem, I was not very clear in explaining) it helps to hide the menu bar in order to type, but the magnified part jumps somewhere else when pressing the arrow keys (most times).
Hmm, height and width values returned by accLocation are correct. Not sure what's going on here.
(In reply to comment #17)
> Hmm, height and width values returned by accLocation are correct. Not sure
> what's going on here.

X and Y positions on this call are correct as well, and the caret position we set via nsAccessibleWrap::UpdateSystemCaret() is also correct. So far it's a mystery.
In addition, this problem occurs with caret browsing mode too.
No longer blocks: 555081
Attached patch fix v.1 (obsolete) — Splinter Review
Assignee: nobody → jmathies
Attachment #531439 - Attachment is obsolete: true
Attached patch fix v.1Splinter Review
This broke when we removed child widgets from the view. GetNearestWidget includes any chrome on the widget. In the past content widgets didn't have chrome, but now the top level widget does, so we have to subtract that off from WidgetToScreenOffset which calculates the content offset.

I could also simplify this by adding a new widget method for the window offset, or use GetScreenBounds. This patch makes the fewest changes though.
Attachment #534062 - Attachment is obsolete: true
Attachment #534066 - Flags: review?
Attachment #534066 - Flags: review? → review?(bolterbugz)
I missed a parenthesis in that comments, it should be:

// ((content screen origin) - (content offset in the widget)) = widget origin on the screen
Comment on attachment 534066 [details] [diff] [review]
fix v.1

Jim, david's going to be on vacation on Monday (Canadian holiday), so if we want to get this into Firefox 6 still, you might want to change the review request to either me or surkov. I looked at the patch, and this definitely looks like the right fix to me.
Status: NEW → ASSIGNED
Version: unspecified → Trunk
Comment on attachment 534066 [details] [diff] [review]
fix v.1

all yours then!
Attachment #534066 - Flags: review?(bolterbugz) → review?(marco.zehe)
Comment on attachment 534066 [details] [diff] [review]
fix v.1

r=me, thanks for the patch!
Attachment #534066 - Flags: review?(marco.zehe) → review+
http://hg.mozilla.org/mozilla-central/rev/6346ef40d7ab
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee: jmathies → nobody
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Target Milestone: --- → mozilla6
any change to get mochitest for this?
Flags: in-testsuite?
Assignee: nobody → jmathies
(In reply to comment #27)
> any change to get mochitest for this?

Might be possible but tricky I think since it relies on results are based on the desktop position of the browser window.
Duplicate of this bug: 670342
First, I am new here and not a developer, so sorry if I don't follow protical. 

It states that this issues is resolved, but I am still having issues with Microsoft Magnifier focusing on the caret in Firefox 4+. It will follow text editing well when the cursor is at the end of a section of text, but has issues when the cursor is anywhere else within the text. It TRIES to focus on the cursor, but is above the text by several lines. This occurs when you are as little as one character back from the end of the paragraph. Also, when trying to browse using the caret I experience the same issue. The magnifier focuses several lines above the caret. Any help would be appreciated. Thanks.
(In reply to kdubfreak from comment #30)
> First, I am new here and not a developer, so sorry if I don't follow
> protical. 
> 
> It states that this issues is resolved, but I am still having issues with
> Microsoft Magnifier focusing on the caret in Firefox 4+. It will follow text
> editing well when the cursor is at the end of a section of text, but has
> issues when the cursor is anywhere else within the text. It TRIES to focus
> on the cursor, but is above the text by several lines. This occurs when you
> are as little as one character back from the end of the paragraph. Also,
> when trying to browse using the caret I experience the same issue. The
> magnifier focuses several lines above the caret. Any help would be
> appreciated. Thanks.

What version of Firefox are you using? The fix here went out with Fx 6, which was released around 2011-08-16.
I am using Firefox 9 and experience the problem with Windows XP at work and Windows 7 at home.
(In reply to kdubfreak from comment #32)
> I am using Firefox 9 and experience the problem with Windows XP at work and
> Windows 7 at home.

Can you file a new bug please with steps to reproduce, and please cc me (:jimm).
(In reply to Jim Mathies [:jimm] from comment #33)
> (In reply to kdubfreak from comment #32)
> > I am using Firefox 9 and experience the problem with Windows XP at work and
> > Windows 7 at home.
> 
> Can you file a new bug please with steps to reproduce, and please cc me
> (:jimm).

Sure, it's my first time doing so, and I'll need to read up on the procedures and whatnot. Heading offline now. Will do so tomorrow and cc you.
Blocks: 722178
You need to log in before you can comment on or make changes to this bug.