Comment 1 by jteh on 2012-05-08 07:15
Do you mean that pressing down/up arrows reads the wrong link? Does it read the item count correctly? Are you certain you're not bumping the mouse (particularly if you're using a notebook)?

It'd be great if you could provide a log at level input/output when this occurs.

Comment 2 by elliott94 (in reply to comment 1) on 2012-05-08 07:24
Replying to jteh:

Do you mean that pressing down/up arrows reads the wrong link? Does it read the item count correctly? Are you certain you're not bumping the mouse (particularly if you're using a notebook)?

Yep - I've tested this both on a notebook and a desktop.

As far as I can remember, the item count was announced correctly. I'll paste a log when the issue occurs again.

Comment 3 by elliott94 on 2012-05-09 21:52
After some more testing, it looks like this may not be an issue specifically to Firefox 12. If the reading of tooltips is enabled, for no apparent reason, NVDA will sometimes announce a chunk of a previous link in the list, followed by the tooltip announcement. I seem to recall seeing this in an earlier version of FF, but I guess that this is still an NVDA issue; I don't see why tooltips should be announced while navigating through the Elements List.

Comment 4 by elliott94 on 2012-08-28 15:21
Any ideas on this? It's becoming increasingly more annoying having to read the current line when this behaviour occurs.
Changes:
Changed title from "Wrong links announced when in Elements List with Firefox 12" to "Links presented as tooltips in Elements List when using Firefox"

Comment 5 by jteh on 2012-08-28 22:50
We're still waiting on a log. :)

Comment 6 by elliott94 on 2012-08-29 10:48
Hi.

This is a sample from my log. This particular example is when browsing through links in the Basic HTML view of Gmail.

Input: kb(laptop):downArrow
IO - speech.speak (11:45:30):
Speaking [('en'), u'NVDA-dev Branch nvda/main: Rev 5381: Support for Asian character Input, including rep... - At http://bzr.nvaccess.org/nvda/main tool tip']
IO - speech.speak (11:45:30):
Speaking [('en'), u'Re: NVDA #2303: Links presented as tooltips in Elements List when using Firefox - #2303: Links presented as tooltips in Elements List when using Firefox 61 of 90 level 0']
IO - inputCore.InputManager.executeGesture (11:45:38):
Input: kb(laptop):downArrow
IO - speech.speak (11:45:38):
Speaking [('en'), u'NVDA-dev Branch nvda/inputMethods: Rev 5295: Updated user guide and changes file to n... - At http://bzr.nvaccess.org/nvda/inputMethods tool tip']
IO - speech.speak (11:45:38):
Speaking [('en'), u'Re: NVDA-dev #2546: Unable to browse Flash content in Firefox with Flash prote... - #2546: Unable to browse Flash content in Firefox with Flash protected mode enabled 62 of 90 level 0'

Didn't manage to reproduce this in Firefox 54.0.1. It could be interesting to know if the tooltips are part of the Elements List or if it is part of the webpage. I expect the latter.

CC @elliott94

I'm still noticing this, but only whilst using Basic HTML from within Gmail. Happy for this to be closed.

@elliott94: Could you give steps to reproduce for GMail? Are you able to reproduce this in other browsers as well?

Of course:

1. Ensure that the reading of tooltips is enabled from within NVDA's Preferences dialog

2. From Firefox, log into a Gmail account and enable the Basic HTML view (this should be an option on the homepage)

3. Open the Elements List, and cursor from the top. When reaching half-way down the page, you should notice that NVDA begins to announce these tooltips before the actual content of the link itself

I haven't yet tested this in other browsers - I can do this.

@elliott94 Many thanks for the update!

@elliott94, can you still reproduce this if you first move your mouse somewhere the Elements List will definitely not touch? For example, you could use object navigation to find the Maximize button and route the mouse there. My suspicion is that when a link is too long to fit in the tree visually, a tool tip gets generated for it automatically by the TreeView control. If the mouse is somewhere within the Elements List, the item under the mouse will keep changing as the tree scrolls, thus continually popping up a tool tip for that item.

P3 because this doesn't occur in most situations and can be worked around by disabling tool tips.

Ah - this appears to be the reason for the announcements. Happy for this to be closed.

Not so fast:

1. Can the tooltips be suppressed?
2. Wild thought, but could the link be split into multiple lines or visually truncated? Truncating will probably not be desirable, although it is confusing that NVDA speaks things that aren't fully visible.

@dkager commented on 19 Jul 2017, 06:24 GMT+12:

1. Can the tooltips be suppressed?

If we did this, sighted users wouldn't be able to access the rest of the item text.

2. Wild thought, but could the link be split into multiple lines or visually truncated?

I think it already is visually truncated, hence the tool tip. I'm not sure you can do multiple lines in a tree view item. Even if we could force this, we'd have to figure out where to place the line breaks, and this would also affect speech and braille.

it is confusing that NVDA speaks things that aren't fully visible.

Yes and no. Semantically, the content is all there; it just doesn't fit on the screen, so the control uses a tool tip to make it visually accessible. The fact that it doesn't fit on this particular screen visually is not semantically relevant.

CC @Qchristensen, @feerrenrut in case they can provide additional input.

This all seems to make sense to me. Another wild idea, could NVDA have an option to automatically move the mouse cursor to a "safe" position so that it can not interfere, I imagine that tool tips from a mouse in an unfortunate position could easily cause problems in other cases too.

@feerrenrut Since this all seems to make sense to you :), could you please succinctly summarize the reported issue versus the issue(s) identified?

I guess this issue is still reproducible. Right? @elliott94

It is, yes - still as described.