1623499 - Backspacing through formulas in google sheets often doesn't delete things

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Dave Townsend [:mossop]]

I have no idea what is causing this.

STR:

Open https://sheets.new

1. In the first cell enter the formula =MIN(B1, B2, B3) and press enter.
2. Go back to the cell, click in the entry box at the end of the formula and press backspace until you get to the start of the input.

Expected:

At this point the formula box should be empty.

Actual:

Randomly some characters delete re-appear to the right of the cursor. So at the end I am sometimes left with =MIN(B1, B2, B3 or =IN(B1, B2B3 for example.

Comment 1

[Peter Magyari (Desktop QA)]

Hi Dave,

I've managed to reproduce this issue on Windows 10 and MacOS 10.15 on Firefox 74.0 and Firefox 76.0a1.
I'm setting a component in order to get the development team involved in reviewing this issue.

Thank you for reporting!

Comment 2

[Alphan Chen [:alchen]]

(In reply to Dave Townsend [:mossop] (he/him) from comment #0)

2. Go back to the cell, click in the entry box at the end of the formula and press backspace until you get to the start of the input.

Actual:

Randomly some characters delete re-appear to the right of the cursor. So at the end I am sometimes left with =MIN(B1, B2, B3 or =IN(B1, B2B3 for example.

I can reproduce the issue on Linux and MacOS.
From my experience, I cannot reproduce it with a long press.
You need to press backspace multiple times with intervals.

Comment 3

[Markus Jaritz [:markus] (UX)]

I now get a similar behavior every time I want to edit any formula.
It makes using sheets with formulas in Firefox nearly impossible.
This could be a reason for people to leave for Chrome if we can't fix.
Not sure about the size of our user base that would edit formulas,
but this seems to deserve a higher priority then 3.

Comment 4

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Hi Masayuki, can you help us figure out the root cause? Thank you!

Comment 5

[Andrew Overholt [:overholt]]

I can reproduce this on builds from as far back as mid-2019 which makes me think it's something that's changed on GSuite's side. I was trying with a simple sheet: https://docs.google.com/spreadsheets/d/1aTdVPWFxjowsi4WQ7-wST-_7r4pSL1j8EJ53kT54B1w/edit#gid=0

Steven, can you think of anything that would have changed recently in Sheets code to cause this?

(In reply to Dave Townsend [:mossop] (he/him) from comment #0)

STR:

Open https://sheets.new

1. In the first cell enter the formula =MIN(B1, B2, B3) and press enter.
2. Go back to the cell, click in the entry box at the end of the formula and press backspace until you get to the start of the input.

Expected:

At this point the formula box should be empty.

Actual:

Randomly some characters delete re-appear to the right of the cursor. So at the end I am sometimes left with =MIN(B1, B2, B3 or =IN(B1, B2B3 for example.

Comment 6

[Andrew Overholt [:overholt]]

(FWIW I see a bunch of "Empty string passed to getElementById(). 4167379105-waffle_js_prod_core.js:1165:146" in the console but suspect that's unrelated.)

Comment 7

[Steven Saviano]

Hmm, not sure. I'll ask the team to bisect a few builds to see if anything recent in the past few months.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Still not sure what occurs or does not occur between reproduced case vs. expected case, though. When typing Backspace, Spreadsheet sets innerHTML a couple of times after we handle Backspace key press and sets selection...

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The removed character by Backspace is restored by setting innerHTML so that this must be a bug of Google Spreadsheet because setting innerHTML is not from mutation observer nor event listener. I guess they do failed to get modified text after input events.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

FYI: There are some warnings in debug build when I test this, but I confirmed that they are not related because these warning are ignored.

Comment 11

[Markus Jaritz [:markus] (UX)]

This odd behavior does not only happen with backspace, but also "*" or "+" are interpreted as moving the cursor to the right instead of typing the character. Sometimes also happens for other characters. (I use a German keyboard layout - not sure if that is related.)
I also noticed that both behaviors only happen in the formula field on top of the table, not when double-clicking a cell and editing the formula directly in the cell.

Comment 12

[Andrew Overholt [:overholt]]

Comment 9 and comment 11 here might be of interest, Steven. Just FYI (no info "needed").

Comment 13

[Thomas Wisniewski [:twisniewski]]

I found that by disabling all keydown listeners that the page is adding, backspacing over the formula works fine, and I can press enter to confirm my edits, but not escape to cancel them. So I dug into the keydown listeners. They're all evidently added with addEventListener via this utility function in this script:

b = vEa ? function (c) {
  return a.call(b.src, b.listener, c)
}

By adding some logging into that function to see just the keydown handlers being added, I see this list: Mnb(a), COa(a), Lnb(a), f4b(a), O(a), and ncb(a).

The only one of those which seems to involve key-handling directly is Mnb, and indeed it's the only one where if I turn it into a no-op, I get the behavior where backspace works fine, but esc does not. This is Mnb, the keydown handler:

m.Mnb = function(a) {
    (yf || vf) && (17 == this.ey && !a.ctrlKey || 18 == this.ey && !a.altKey || Bf && 91 == this.ey && !a.metaKey) && this.xp();
    -1 == this.ey && (a.ctrlKey && 17 != a.keyCode ? this.ey = 17 : a.altKey && 18 != a.keyCode ? this.ey = 18 : a.metaKey && 91 != a.keyCode && (this.ey = 91));
    mab && !P9a(a.keyCode, this.ey, a.shiftKey, a.ctrlKey, a.altKey, a.metaKey) ? this.handleEvent(a) : (this.jH = Q9a(a.keyCode),
    nab && (this.csa = a.altKey))
}

Poking around, it looks as though nothing in that function itself is causing the issue, but it also calls this handleEvent function (deminified a bit):

m.handleEvent = function(a) {
    var b = a.le()
      , c = b.altKey;
    if (uf && "keypress" == a.type) {
        var d = this.jH;
        var e = 13 != d && 27 != d ? b.keyCode : 0
    } else
        (yf || vf) && "keypress" == a.type ? (
          d = this.jH,
          e = 0 <= b.charCode && 63232 > b.charCode && py(d) ? b.charCode : 0
        ) : tf && !yf ? (
          d = this.jH,
          e = py(d) ? b.keyCode : 0
        ) : (
          "keypress" == a.type ? (
              nab && (c = this.csa),
              b.keyCode == b.charCode ? 32 > b.keyCode ? (d = b.keyCode,
            e = 0) : (d = this.jH,
            e = b.charCode) : (d = b.keyCode || this.jH,
            e = b.charCode || 0)
          ) : ( 
            d = b.keyCode || this.jH,
            e = b.charCode || 0 
          ),
          Bf && 63 == e && 224 == d && (d = 191)
        );
    var f = d = Q9a(d);
    d ? 63232 <= d && d in kab ? f = kab[d] : 25 == d && a.shiftKey && (f = 9) : b.keyIdentifier && b.keyIdentifier in lab && (f = lab[b.keyIdentifier]);
    xf && mab && "keypress" == a.type && !P9a(f, this.ey, a.shiftKey, a.ctrlKey, c, a.metaKey) || (
      a = f == this.ey,
      this.ey = f,
      b = new oab(f,e,a,b),
      b.altKey = c,
      this.dispatchEvent(b)
    )
};

It turns out that while Mnb calls handleEvent for keydown events, another function is calling handleEvent for keypress.

So this seems like a conflict between their keydown/keypress handling, but I'm not sure where to drill deeper. I know we've changed our key-handling behavior a lot lately (including charCode/keyCode), but adding *.google.com to the prefs dom.keyboardevent.keypress.hack.dispatch_non_printable_keys.addl and dom.keyboardevent.keypress.hack.dispatch_non_printable_keys.addl doesn't help, nor does spoofing to a Chrome UA.

Comment 14

[Steven Saviano]

An engineer on Sheets is investigating this. Will report back once we have more info.

Comment 15

[Steven Saviano]

A fix was submitted internally. It will be rolling out shortly. I will report back when it is at 100%. Thanks again for the report!

Comment 16

[Steven Saviano]

This issue should be resolved for all users as of a few weeks ago. Leaving to Mozilla to verify.

Comment 17

[Mike Taylor [:miketaylr]]

Dave, can you verify the fix?

Comment 18

[Dave Townsend [:mossop]]

Yes this looks like it is working properly now.