Firefox: can't read text right after inline element using the mouse #9235
Comments
|
What text unit resolution are you using? I set mine to paragraph. I tested this in chrome and firefox, both seem flaky, and chrome is worse. Interestingly, in Firefox, the point where each line was read (after the link) seemed to match the number of characters before the link. It would be interesting to investigate this a little more to see if this is reproducible, and meaningful. |
|
Also worth testing: The behaviour with windows at different scaling levels. |
|
Hello @feerrenrut, |
|
@DataTriny how is the behavior in NVDA 2020 Beta 1 and Firefox 75? |
|
Hi @Adriani90, using the webpage I provided in the issue description, the behavior is still the same with NVDA 2020.1 beta1. |
|
This bug goes all the way back to April 2009, ebb7dbb. It's also being discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1822340#c16. I'll submit a pull request shortly. |
…ouse chunk. (#14755) Fixes #9235. Summary of the issue: In Firefox, when there is text before and after a link, mousing over the text after the link often doesn't read the text. This applies to other types of inline elements as well; e.g. buttons. Description of user facing changes In Mozilla Firefox, moving the mouse over text after a link, etc. now reliably reports the text. Description of development approach When handling unit_mouseChunk, the code in IA2TextTextInfo.expand first expands to the user configured resolution (line, paragraph, etc.). It then attempts to shrink the range so that it only covers the text between embedded objects before and after the origin, if any. The code previously calculated the final end offset incorrectly. It used oldEnd - self._startOffset as the offset from which to search for an embedded object after the origin. However, self._startOffset had already been moved to the embedded object before the origin, so it was no longer related to the text string. This meant that the search offset was completely bogus and could even result in _endOffset being smaller than _startOffset. Now, we use the same offset for both embedded object searches: our origin relative to the start of the expanded range of text. I've also added comments.
Steps to reproduce:
Actual behavior:
If a paragraph contains an inline element (such as a link, an image, a button, etc...) that is not placed at the start, NVDA will not be able to report the text directly following the element. But, if the paragraph is long enough, then you will be able to read the desired text (providing that you place the cursor away from the element). As you can see from my test case, this offset seems to depend on the amount of text placed before the element.
Expected behavior:
NVDA should be able to read the text that is adjacent to an inline element, without any margin (like in Microsoft Edge or Google Chrome for instance).
System configuration
NVDA installed/portable/running from source:
NVDA is installed.
NVDA version:
NVDA 2018.4.1
Windows version:
Windows 10 Education, version 1809
Name and version of other software in use when reproducing the issue:
Mozilla Firefox 65.0 (x64)
bug.zip
Other questions
Does the issue still occur after restarting your PC?
Yes
Have you tried any other versions of NVDA?
As far back as I can remember, this problem has been there for a very long time.
The text was updated successfully, but these errors were encountered: