1307002 - Narrate word tracking flicks back to previous words / off to the left

Status: VERIFIED FIXED

(Toolkit :: Reader Mode, defect)

Description

[:Gijs (he/him)]

(In reply to ItielMaN from bug 1279842 comment #35)
> Though a new issue arised- on some sentences, the orange underline thingy
> may go to the left (instead to the right) for a split second and then will
> continue to the rest of the sentence.
> It can be seen here, when firefox reads "Type about:config in Firefox's
> address bar and hit enter":
> http://www.ghacks.net/2015/02/07/mozilla-starts-to-push-reader-mode-to-
> desktop-firefox/
> After "Type" is read, the underline goes to the left and goes back to the
> right.

I actually think I see this in general, though the animation makes it tricky to see, and  it's definitely more noticeable when "Type" is read in the sentence ItielMaN highlighted.

If you increase the transition time to, say, 5 seconds, the cause of this becomes more obvious: the highlighter is transitioning the 'left' property, but because it's translated based on its width, and the width does not transition, the highlighter sometimes "janks" out to the left, thus underlining previous words.

Mike or Eitan, is this something we can fix, maybe by transitioning the width as well, or not using the negative translate?

Comment 1

[Itiel]

Still an issue on latest Nightly builds.

Comment 2

[:Gijs (he/him)]

Ni Eitan for comment #0.

Comment 3

[Eitan Isaacson [:eeejay]]

What platform do you see this on?

Comment 4

[Itiel]

(In reply to Eitan Isaacson [:eeejay] from comment #3)
> What platform do you see this on?

I'm running Windows 10 x86.
Somehow, in latest Nightlies the issue is not apparent as before (I think?), but you can clearly see it when the Narrator reads "Find reader.parse-on-load.enabled" in the same page I've provided before (see comment 0).

Comment 5

[Eitan Isaacson [:eeejay]]

Yes. We recently changed how word ranges are defined. So the results might vary now. Thanks for the pointer on how to reproduce. I'll get to it now..

Comment 6

[Eitan Isaacson [:eeejay]]

OK, I looked into it further. Gijs's prognosis is correct. I'll submit a patch that transitions the width as well.

Just FYI, this jank should be less common now anyway since bug 1321862 landed. We used to determine the word length with some regex. This would raise the case that synth would break up the "word" into words, but our regex would not. So a succesion of boundary events can have the same end offset but different start offsets. This is what caused the jank.

Comment 7

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1307002 - Transition width of narrate word highlight.

Review commit: https://reviewboard.mozilla.org/r/101234/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/101234/

Comment 8

[:Gijs (he/him)]

Comment on attachment 8822283 [details]
Bug 1307002 - Transition width of narrate word highlight.

https://reviewboard.mozilla.org/r/101234/#review102442

Nice, thanks!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3b5eab628d4b
Transition width of narrate word highlight. r=Gijs

Comment 10

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/3b5eab628d4b

Comment 11

[Itiel]

I can confirm this is fixed in latest Nightly.

Comment 12

[Camelia Badau [:cbadau], Desktop Test Engineering]

Verified fixed on Windows 7 x64, Windows 10 x64 and Mac OS X 10.12 using Firefox 53 Beta 2 (buildID: 20170313154936).