Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firefox browse mode adds a non-existing space when the closing tag is standing in a new line #9294

Open
DrSooom opened this Issue Feb 19, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@DrSooom
Copy link

DrSooom commented Feb 19, 2019

HTML code snippets:

  1. <div>Text 1
    </div>
  2. <div>Text 2</div>

Actual behaviour:

  1. Parsed text in browse mode: "Text 1 " (There is a space after the digit "1".)
    Parsed text in focus mode: "Text 1"
  2. Parsed text in browse mode: "Text 2"
    Parsed text in focus mode: "Text 2"

Expected behaviour:

  1. Parsed text in browse mode: "Text 1" (There is no longer a space after the digit "1".)
    Parsed text in focus mode: "Text 1"
  2. Parsed text in browse mode: "Text 2"
    Parsed text in focus mode: "Text 2"

Notes:

  • This behaviour is extremely annoying when copying text via the browse mode.
  • Writing the closing tag in the same line, where the text ends, looks quite strange in the source code in some cases. Sadly this is the only workaround to solve this issue yet, but it isn't suitable (less overview in the source code).
  • Switch to focus mode and copy the whole content to the clipboard to see the result of the parsed text in focus mode.
  • This issue doesn't occur with Google Chrome 72.0.3626.109.

System configuration:

NVDA installed/portable:

Both

NVDA version:

2018.1 (and earlier), 2018.4 (also tested)

Windows version:

Win7x64 (tested) – and maybe until Win10-1903

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

Firefox 56.0.2 and 65.0.1

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA?

Same result with NVDA 2018.1. This issue occurs for many years.
CC: @michaelDCurran, @jcsteh and @MarcoZehe

@jcsteh

This comment has been minimized.

Copy link
Contributor

jcsteh commented Feb 19, 2019

TL;DR: Totally understand the concern here, but I'm not sure how to solve this in Firefox without breaking things.

Whenever there is a new line in HTML, except for the <pre> tag, this gets translated to a space in the rendered output. For example, this:

<div>test
test</div>

gets rendered as "test test". The same is true for a new line at the end. It seems, however, that Firefox truncates the space at the end when copying to the clipboard. Regardless, we know it's still in the rendered output because if you make it contenteditable, you can cursor to the space. In other words, this behaviour isn't accessibility specific.

Interestingly, Chrome seems to truncate the space even for contenteditable. That happens even for a space character in the source (as opposed to a new line character).

I don't think we could safely make this change specifically in Firefox accessibility without breaking the contenteditable case. It would need to be made more generally in Firefox (affecting contenteditable as well), but that raises the question of what the web specs actually say.

@jcsteh jcsteh added the Firefox label Feb 19, 2019

@DrSooom

This comment has been minimized.

Copy link
Author

DrSooom commented Feb 19, 2019

Spaces and tabs from the beginning of a line are fully ignored by Firefox and Chrome. (Internet Explorer 11 would be a completely other topic.) Adding <!----> directly after the last character (very important: without a space in front of the "<") seems to solve this issue as well. Good to know – after so many years. (Why the heck I didn't figure that out earlier?! Because this is an acceptable workaround for me – and I'm now able to structure the HTML code as it should.)

So as far as I figured it out right now, Firefox adds a space for every line break, as long as there isn't a HTML tag at the end of the line, but it doesn't look for a HTLM tag "directly" after the line break character too. Firefox in browse mode shows "Text 27 Text 28 Text 29" for closing-span-nospace-comment-newline-opening-span and Chrome "Text 27Text 28Text 29". Same result with Text 30 to Text 32 with a space between the closing span tag and the HTML comment.

Here is a test html file with lots of different examples and their rendering results (browse and focus mode), which you can use for testing. Maybe it helps others to understand how things are rendered in Firefox and Chrome – and also in IE11. I know the differences between <div> and <span>, but I wanted to list the <span> tag here too, because the different results here are quite interesting.

PS: And now I have headache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.