www.google.com - see bug description

[webcompat-bot]

URL: https://www.google.com/search?q=lego&tbm=isch

Browser / Version: Firefox 66.0 Operating System: Windows 10 Tested Another Browser: Yes

Problem type: Something else Description: Keyboard arrows stop working when browsing through images Steps to Reproduce: Click on the first image result to expand it, then use the right arrow key to browse through a few images. Eventually the right arrow key stops advancing through the images. This does not break in Chrome

Browser Configuration

• None

From webcompat.com with ❤️

[cipriansv]

Thanks for the report, I was indeed able to reproduce the issue. After several right arrow key presses the images stopped advancing.

Tested with: Browser / Version: Firefox Nightly 66.0a1 (2019-01-14), Chrome 71.0.3578.98 Operating System: Windows 10 Pro

[wisniewskit]

Confirmed. But if I take a bit longer between keypresses, it seems to work fine on both browsers. This implies breakage related to network requests not having completed, or some other event having not fired before the user presses a key to see the next image, which throws off their code.

[karlcow]

@wisniewskit this seems to be in limbo. You got the start of an explanation but no next steps. :) Do you want to move it to contactready? Or do you want to dig a bit more?

[wisniewskit]

There are a bunch of wrapped keyup/keydown handlers, as expected. After digging through the minified code and returning early from each handler for key events, I found that this was the one that was involved in changing the images on arrow-presses (it's in a script in the HTML markup itself):

ka = function(a, d) {
    return function(b) {
        var c = d;
        if ("_custom" == c) {
            c = b.detail; 
            if (!c || !c._type) return;
            c = c._type
        }
        /* snip the rest of this really long function */

And ignoring all key events except keydown, the problem still manifested, so it is the keydown handling in particular that's problematic somehow. And so I started the JS debugger on a keydown event here, and kept stepping into code until it hit a script that seemed to be handling the arrow keys (code 39) on keydowns, which this other script.

Then, after adding console traces in that script to find the spot that was handling the arrow-right keypresses, I found it here:

s_.Pk = function (a) {
  if (27 == a.keyCode && this.$.Da)
    this.oP('k', a),
    s_9Be(new s_Gd(a));
  else {
    var b = s_tk() ? 39 : 37,
        c = s_tk() ? 37 : 39;
    a.keyCode != b || a.ctrlKey || a.altKey || a.shiftKey || a.metaKey ? a.keyCode != c || a.ctrlKey || a.altKey || a.shiftKey || a.metaKey || (this.roa('k'), s_9Be(new s_Gd(a)))  : (this.Cna('k'), s_9Be(new s_Gd(a)))
  }
};

Which is calling this function near the end:

s_.roa = function (a) {
  var b = this.Gf();
  this.next();
  var c = this.Gf();
  c != b && s_k5(this, this.Al(c), a, s_SCe(this, 3590))
};

The this.next() is what changes the image to the next one in the search results:

s_m5.prototype.next = function () {
  var a = this.$.$.Gf();
  s_7Ie(this.$.$.Al(a + 1)) || (a += 1);
  return a + 1 < this.$.$.Nm() ? (this.go(a + 1, 1), !0)  : !1
};

Funny enough, I realized at this point in the diagnosis that I couldn't reproduce the bug anymore - I could hold the right arrow-key down, and it switched through images just fine. So the half-dozen console.log statements I've added to the script were causing some kind of delay which un-broke things.

Even more funny, at that point I also realized that after the gallery gets "stuck", I can click on the black background around the image, and the arrow key starts working again, which of changes everything. That implicates a focus issue; that focus is being lost sometimes, so the keydown events aren't targeting the right element anymore. So I backtracked and cleared my console.logs, adding just one to figure out what the event target is for the keydown events (in the event handler that leads up to the next() call):

s_Uic.prototype.Aa = function (a) {
  a = a || window.event;
  console.log(a.target); /* added this */
  var b = a.keyCode;
  9 == b && s_Tic();
  if (!a.altKey && !a.ctrlKey) {
  /* snip for bervity */

As I anticipated, while the right-arrow was working (changing the images), the target was an <a class="irc_mil i3597" jsaction="mousedown:irc.rl;focus:irc.rl">, but when it stopped working, the target suddenly switched to the <body> tag. Likewise, clicking on the background sets the focus back to that anchor tag.

So we now have the root cause of this issue figured out. What's left is to find out why the focus is changing to break the key-handling.

[wisniewskit]

My first hope was that it was just that the script was trying to focus on the anchor, so I asked Tinker Tester to tell me whenever focus or blur were being called on an element. As hoped, it turns out that as we press the keys, calls to focus on the anchor are being done (but no blur calls):

    s_UBe https://www.google.com/xjs/_/js/k=xjs.s.en.GzNe7qocdzg.O/am=BgCwCDMAgPyfAoAKgIBVYIMFIogCGQE/rt=j/d=1/exm=sx,Fkg7bd,HcFEGb,IvlUe,MC8mtf,OF7gzc,RMhBfe,T4BAC,TJw5qb,TbaHGc,Y33vzc,cdos,cr,hsm,iDPoPb,jsa,mvYTse,tg8oTe,uz938c,vWNDde,ws9Tlc,xpltpb,yQ43ff,d,csi/ed=1/dg=2/rs=ACT90oGyHtZyR-LdizJZTcsZd_D8gkFASQ/m=sb_wiz,aa,async,foot,m,mu,qi,sf,str,tnqaT,xz7cCd,qik19b,aam1T,E5jc1c,XjCeUc,SvnKM,qZ1Udb,PygKfe,WSmMic,BuhrE?xjs=s1:1281
    onmessage https://www.google.com/xjs/_/js/k=xjs.s.en.GzNe7qocdzg.O/m=sx,Fkg7bd,HcFEGb,IvlUe,MC8mtf,OF7gzc,RMhBfe,T4BAC,TJw5qb,TbaHGc,Y33vzc,cdos,cr,hsm,iDPoPb,jsa,mvYTse,tg8oTe,uz938c,vWNDde,ws9Tlc,xpltpb,yQ43ff,d,csi/am=BgCwCDMAgPyfAoAKgIBVYIMFIogCGQE/rt=j/d=1/dg=2/rs=ACT90oGyHtZyR-LdizJZTcsZd_D8gkFASQ:238

Just by having Tinker Tester log those calls, the script is un-broken (while the devtools are open). But also commenting out the focus call in the relevant function was un-breaking it as well:

So this was gearing up to be a pain to diagnose. This is the function:

s_UBe = function (a) {
  s_Qe(function () {
    var b = s_44(a.$);
    if (!s_pAe('INPUT') && b.$.fea() && b.Ka) {
      var c = s_bd();
      b.Ka.focus(); // commenting this out fixes it
      window.scrollTo(c.x, c.y)
    }
    !b.$.fea() && s_pAe('INPUT') && document.activeElement.blur()
  })    
},

First I wondered if maybe there was some call to blur that was racing and un-focusing the input just after it was focused by the above function, so I told Tinker Tester to ignore all calls to blur ... which didn't help.

Then I suspected that maybe some other event-handler on the page (focus, blur, focusin, focusout) was being triggered, and causing the issue somehow. But again, having Tinker Tester ignore the handling for those events did not stop the breakage.

Finally, I guessed that maybe the anchors were just being re-created or otherwise ended up not being attached to the document when they were focused, but no: Tinker Tester tells me that no a tags are being added to or removed from the document, and I even had their handler log whether document.body.contains(b.Ka), and that's always true.

So I'm stumped. Why would simply calling focus() on these anchors cause such breakage? It doesn't seem as though it's their scripts, unless I've missed something. No other focus calls are being made during the time aside from the ones in s_UBe above.

My only remaining idea was that maybe this was a regression, but I can still reproduce the issue as far back as Firefox 57, so I'm at a loss here. @DenSchub, can you think of anything that might cause the focused element to change back to the body, if it's not the focused element being removed, or a focus/blur/etc event handler, or even a call to focus/blur?

[wisniewskit]

I wonder if this is related to bz1529856...

[wisniewskit]

Actually, I can't seem to reproduce this anymore today (not even on nightly builds that were failing for me). I wonder if the page changed and fixed something? @cipriansv, does it also work for you now?

[JakubVanek]

I confirm that arrow keys work again on Firefox 65.0 on Xubuntu 18.04.

[cipriansv]

I retested the issue and it is not reproducible anymore,

Tested with: Browser / Version: Firefox Nightly 67.0a1 (2019-03-05) Operating System: Windows 10 Pro

[wisniewskit]

Thanks, then I'll close it for now. Shame that it's not a fix we can verify with mozregression or something.

[lock[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue at https://webcompat.com/issues/new if you are experiencing a similar problem.