Firefox: The location of the NVDAObject in some pages is different from the actual location.

[hwf1324]

Steps to reproduce:

For example, some of the pop-up menus in GitHub.

Or this page: https://www.nvidia.com/en-us/drivers/details/232672/

1. Open the page above
2. tab to "Download" button
3. Use the ‘Moves the mouse pointer to the current navigator object’ command to move the mouse.

Actual behavior:

The NVDAObject corresponding to the element is different from the actual position of the element.

Clicking the left mouse button did not activate the download button.

This destroys the mouse tracking.

Expected behavior:

The NVDAObject is in the same position as its corresponding element.

Mouse over the download button

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

install

NVDA version:

alpha-34252,4de8af78（2025.1.0.34252）

Windows version:

Windows 11 22H2 (10.0.22621)

Name and version of other software in use when reproducing the issue:

Firefox 131.0.2

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

Yes

If NVDA add-ons are disabled, is your problem still occurring?

Yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Yes

[hwf1324]

CC: @jcsteh

[jcsteh]

Could you please provide more detailed steps to reproduce? For example, what elements on the Nvidia page did you specifically test with and how did you test them?

[hwf1324]

I confirmed it through Visual highlighter.

However, you can tab to the ‘Download’ button, then move the mouse over the navigation object and click, and find that the download button is not activated.

[Adriani90]

Do you tab to the object while in browse mode? Or are you in focus mode? How do you move the mouse exactly, do you use the keyboard command for that? Or do you just move it phisically onto the visual rectangle from the visual highlighter

[hwf1324]

Do you tab to the object while in browse mode? Or are you in focus mode? How do you move the mouse exactly, do you use the keyboard command for that? Or do you just move it phisically onto the visual rectangle from the visual highlighter

This has nothing to do with browse mode or focus mode. The behaviour is the same.

Use the ‘Moves the mouse pointer to the current navigator object’ command to move the mouse.

[CyrilleB79]

That's an issue I had very frequently in GithUb when trying to activate the "Show options" menu, visually a button with three dots, which appears above all messages in an issue or PR:

• Trying to select an item, e.g. "Quote reply" with Enter was failing with a logged error
• Trying to activate the navigator object (e.g. "Copy link") with NVDA+numpadEnter activated another item, e.g. "Copy link".

I am a Windows Magnifier user, but when the issue was occurring, I have tried to disable the Magnifier, with no change.

Though, trying to provide an STR this morning, I was not able to reproduce anymore!

[CyrilleB79]

@hwf1324 I guess the Firefox version is rather 131 than 113 (as mine), isn't it? Could you fix it?

[hwf1324]

I guess the Firefox version is rather 131 than 113 (as mine), isn't it? Could you fix it?

Thanks for catching that typo, I've fixed it.

[CyrilleB79]

Though, trying to provide an STR this morning, I was not able to reproduce anymore!

OK. Tonight I am able to reproduce whenever wanted. Here is a log, with add-ons disabled, where I am trying to activate the "Quote reply" menu item in this same GitHub issue, without success: nvda.log The Magnifier was also closed for this trial.

Note that to include the quotation in this message, I have finally been able to select "Quote reply" activating the menu item above, i.e. "Copy link".

[Adriani90]

Mouse movements are currently not logged. How would you catch that? I guess it is important to find out where exactly the mouse cursor lands in these cases when routing it to the navigator.

[CyrilleB79]

It's not a problem with mouse routing in the first place. Actually, it's that object positions in Firefox seem to have a vertical offset with respect to their real position. This offset position then causes the following issues:

• issue when trying to route the mouse to object
• issue with the focus highlighter, the highlight being shifted vertically

[hwf1324]

This issue seems to have been fixed in Firefox 134.0.2.

[CyrilleB79]

I can still see the issue with the same FF version ('134.0.2') in GitHub's pop-up menus (to copy the URL of a comment or quote it). The visual highlighter is vertically shifted. And trying to validate the selected entry, either with Enter key or routing the mouse to nav object and clicking it validates the wrong entry in the menu.

Though, it does not occur 100% of the times, but quite frequently; I have not yet identified when the position behaves OK or not.

Reopening.

@jcsteh has a specific fix been merged in FF 134 for this?

[jcsteh]

Not specifically, no, but there are a lot of fixes going on in that area of the code at the moment and it's difficult to pin point all the various cases each fix will or won't address. So, it's definitely worth re-testing as new versions are released.

[jcsteh]

trying to validate the selected entry, either with Enter key

Do you mean pressing enter in browse mode? When you press the actions button and the menu appears, NVDA should switch to focus mode. So are you forcing browse mode, moving to the item and pressing enter? I ask because pressing enter should be different to routing the mouse and clicking because enter in browse mode programmatically asks Firefox itself to perform the click, which shouldn't be impacted by screen coordinates. That makes me wonder whether we're dealing with a different issue here. In focus mode, enter is handled by the web page itself, so any failure there is on the GitHub side.

[hwf1324]

For the examples I've provided previously, I'm not currently experiencing any problems with them.

However, I have encountered something similar when viewing the detailed output of a GitHub Actions workflow.

I'm not sure if this is the same issue.

[jcsteh]

@hwf1324, could you provide some steps to reproduce for the issue you encountered with GitHub actions so I can try to diagnose it? Thanks.

[hwf1324]

@jcsteh

1. Open: https://github.com/nvaccess/addon-datastore/actions/runs/13255248404/job/37001279172
2. Expand the job entry in the detailed output area (e.g., Set up job). Use the mouse to view the output.

[jcsteh]

Are you running with Firefox release or Nightly? I can't reproduce any problem here in Firefox Nightly. Note that we've landed several fixes relating to mouse tracking in the last week or two, so it's possible one of these addressed it.

[hwf1324]

I am currently using Firefox 135.0 and I will download Firefox Nightly to test it.

[hwf1324]

Sorry, downloading Firefox Nightly took me a lot of time.

I successfully reproduced this on Firefox Nightly 137.0a1 (2025-02-12) (64-bit).

[CyrilleB79]

@jcsteh and @hwf1324, I realize that I can reproduce the issue only in PRs comments, not in the comments of the issue new interface of GitHub. Could you try in a PR?

To reproduce:

• Enable visual highlighters
• Go to a PR's comment
• In browse mode, go to a button for sub-menu labeled "Show options"; visually, it only contains 3 dots.
• Press Enter; at this point NVDA switches to focus mode
• Press downArrow until you hear "Quote reply"; note that that the visual highlighter is rather located on "Reference in new issue".
• Press Enter; note that the message is not quoted.

You can do this without highlighters, but the highlighters highlight the issue.

And answering to @jcsteh :

trying to validate the selected entry, either with Enter key

Do you mean pressing enter in browse mode? When you press the actions button and the menu appears, NVDA should switch to focus mode.

Yes, NVDA switches to focus mode.

So are you forcing browse mode, moving to the item and pressing enter?

No, I do not force browse mode, NVDA remains in focus mode when I press up/downArrow to select a menu item and when before I press Enter.

In focus mode, enter is handled by the web page itself, so any failure there is on the GitHub side.

But if it's a GitHub matter, why is the visual highlighter shifted vertically?

[hwf1324]

I realize that I can reproduce the issue only in PRs comments, not in the comments of the issue new interface of GitHub. Could you try in a PR?

I can confirm this in Firefox Nightly 137.0a1 (2025-02-13) (64-bit).

[jcsteh]

But if it's a GitHub matter, why is the visual highlighter shifted vertically?

There could be two bugs here. What I can say is that enter failing to work in focus mode is on the GitHub side because Firefox doesn't handle the enter key on such elements. That gets handled by JS provided by the page.

[jcsteh]

I successfully reproduced this on Firefox Nightly 137.0a1 (2025-02-12) (64-bit).

@hwf1324 I might need more specific steps and expected results for your GitHub actions case. For me, if I route the mouse to any text in the expanded "Set up job" section, it all gets read as expected, even with the mouse unit resolution set to word. Is there a specific piece of text that isn't reported correctly or where the coordinates don't align? I'll flag that I'm totally blind, so it's possible the coordinates don't line up visually, but there is definitely a lot of text in that section that is read by mouse tracking for me.

[hwf1324]

@jcsteh

1. Locate and expand "Set up job".
2. Press the down arrow to find "Current runner version: '2.322.0'".

At this point the object is located on the "Runner Image", maybe you can use OCR to determine this.

[jcsteh]

Aha. Thank you. I see it.

[jcsteh]

https://bugzilla.mozilla.org/show_bug.cgi?id=1948185

[Adriani90]

This firefox bug seems fixed in 137 branch. Should we close it? Or is anyone still able to reproduce this issue?

[seanbudd]

Closing as fixed, please let us know if you are still encountering this issue