1324317 - Google sheets cell height often doubles in size unexpectedly

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect)

Comment 1

[Brian Birtles (:birtles)]

(Oops, sorry, I accidentally hit enter while typing the bug title.)

I haven't been able to determine an STR for this bug probably anyone using Google Sheets in Nightly recently has noticed that on certain occasions, after inputting something into a cell then changing cell, the cell height suddenly doubles.

I'm not sure yet whether or not this is a change on the Sheets side or Gecko side that has caused this. I'm on Windows 10 but others on Mac have experienced the same issue.

Comment 2

[Brian Birtles (:birtles)]

Attachment: Video demonstrating bug

Here is a video taken with today's nightly.

I notice the bug occurs more frequently on complex spreadsheets (where it seems to have nearly a 50% likelihood of occuring). It also seems to occur more frequently when the browser screen is full-size? (I tried to create a recording with a reduced-size browser window and it never occured.)

Comment 3

[Brian Birtles (:birtles)]

I just managed to reproduce this using Firefox 51 so I suspect this is a change on the Google Sheets side.

Comment 4

[Brian Birtles (:birtles)]

Not sure what component to put this in. Given that this is affecting at least Firefox Beta I'm surprised we haven't had more reports of this. Perhaps it only affects sheets with Japanese input? (Something to do with attempting to measure glyph heights?)

I wonder if Karl or Dees knows someone we can reach out to in Google to ask what recent changes might have caused this? I've noticed it for about the last two weeks so that gives a rough timeframe for when the change occurred.

Comment 5

[Karl Dubost💡 :karlcow]

Thanks Brian!
Before contacting, I think we need to understand why it is happening.
Maybe Thomas can help with the diagnosis. 

Brian does it happen also in Chrome or just on Firefox?


I'm moving this to Tech Evangelism: Desktop for now. And we can move back to Core if we find out it is something in the DOM.

Comment 6

[Brian Birtles (:birtles)]

Just Firefox. I tried to reproduce with Chrome but could not.

Comment 7

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

> 
> I wonder if Karl or Dees knows someone we can reach out to in Google to ask
> what recent changes might have caused this? 

Yes, we do via a shared DL. Once the diagnosis is complete - and if we still need to reach out, TE has this channel available.

Comment 8

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

This happens to me too on release; an additional newline appears to be added to the cell.

Comment 9

[Brian Birtles (:birtles)]

Hmm, maybe this is bug 1205573. That bug talks about adding a newline but what I'm seeing appears to be just the cell height changing, i.e. I can't simply go back and delete a newline to fix the problem.

Comment 10

[Brian Birtles (:birtles)]

Trying the various STR in bug 1205573, none of them reproduce this bug for me so I think this is a separate bug.

Comment 11

[Thomas Wisniewski]

Sorry for the delay here. I can consistently reproduce this with these steps:

1) add text to any cell
2) hit the right arrow key to move to the next cell
3) type text into the cell, then use backspace to delete all of the text
4) hit the left arrow key to move back to the first cell
5) that first cell suddenly doubles in height.

I'll try to investigate what's going on.

Comment 12

[Thomas Wisniewski [:twisniewski]]

Unfortunately, I tried stepping through in the debugger to find the code responsible, but I can't pinpoint where the height of the cell is altered. It seems to happen after the key events are handled, so finding where the problem is may boil down to searching for a needle in a haystack.

Also, when I try stepping through in the debugger, I get different results from my STR. The active cell does not change, and instead the one that you try moving from in step 5 (now empty) remains active and grows in height.

On top of that, I've also noticed a bunch of other things:
- the text itself is rendered in a canvas tag, making it all the more difficult to figure out what's going on.
- loading a spreadsheet with these "glitches" shows them both in Chrome and Firefox, so they are almost definitely phantom line break characters.
- it's also possible to highlight the cell and press the delete key to clear these phantom line breaks.
- when ctrl-enter is used to intentionally add a line break, which is then removed, one must complete the edit by pressing the enter key for the cell to shrink back down. Clicking on another cell to complete the edit will cause it to remain too tall, which happens in Chrome as Firefox (and is also saved to the spreadsheet).
- the height of the rows still shows as "21 pixels" for rows with these phantom line breaks, and altering their heights with the mouse or the "resize" context menu option does not shrink them.

At this point, it seems to me that it would be most fruitful to just contact Google with this info, rather than hunting through the minified code and hoping to get lucky. Maybe someone else has some ideas?

Comment 13

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

> 
> At this point, it seems to me that it would be most fruitful to just contact
> Google with this info, rather than hunting through the minified code and
> hoping to get lucky. Maybe someone else has some ideas?

We now have a dedicated DL here. I'll make sure to add the Webcompat team...

Comment 14

[Brian Birtles (:birtles)]

As per comment 9, this may be different to bug 1205573. When I have seen this there is no newline to delete. Furthermore, I have been unable to reproduce it in Chrome. Next time it reproduces I will double-check that there is no newline to delete.

Comment 15

[Thomas Wisniewski]

(In reply to Brian Birtles (:birtles) from comment #14)
> As per comment 9, this may be different to bug 1205573. When I have seen
> this there is no newline to delete. Furthermore, I have been unable to
> reproduce it in Chrome. Next time it reproduces I will double-check that
> there is no newline to delete.

Sure, it doesn't actually have to be a newline character, but sheets does treat it suspiciously like there is an actual newline character there. As per comment 12, it's easy to make these phantom newlines in Chrome and Firefox, they appear to be saved in the sheet and are shown in both browsers, and you can clear them by clearing the cell (even if you can't see them when you double-click to edit the cell).

Comment 16

[Mike Taylor [:miketaylr]]

ni? self to poke at this, it would be nice if we could give Google some more info before contacting them. But yeah... debugging canvas spreadsheets. Welp.

Comment 17

[Mike Taylor [:miketaylr]]

(note: 100% STR in Comment 11)

Comment 18

[Mike Taylor [:miketaylr]]

Simpler STR:

In a cell in column N, 
1) type "a"
2) hit backspace
3) Move arrow left (or right, doesn't matter) to column N-1.

If you hit Esc before arrowing over, the bug doesn't reproduce.

Comment 19

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

Perhaps :ssaviano can route Comment 18 STR to the right Sheets folks...

Comment 20

[Mike Taylor [:miketaylr]]

Note: I'm still looking at this, it'd be nice to some more info to pass along to Google. Should have something soon.

Comment 21

[Steven Saviano]

Thanks for the info and attempts at a simpler repro. Very much appreciated. Not sure we have another bug filled for this one (need to look over).

For now, I filed the following Google internal issue to track: https://b/34740026

Will report back on progress as a fix is identified and rolled out.

Comment 22

[Mike Taylor [:miketaylr]]

(uh, didn't mean to change platform rel flag...)

OK, so if I duck punch fillText like so:

var origFillText = CanvasRenderingContext2D.prototype.fillText
CanvasRenderingContext2D.prototype.fillText = function (a, b, c) {
  console.error(`fillText("${a", ${b}, ${c})`);
  origFillText.call(this, a, b, c);
}

Whenever I get the cell to grow I get 4 empty strings drawn:

fillText("", 150, 39) 
fillText("", 150, 55) 
fillText("", 244, 76) 
fillText("", 244, 92)

There's a mountain of callstack to dig thru, but I should be able to set nice breakpoints in Chrome DevTools (because Fx Devtools chokes on breakpoints in prettified code) and trigger cell-growing from Firefox, with both browsers on the same doc.

CanvasRenderingContext2D.prototype.fillText debugger eval code:4:3
hmb https://docs.google.com/static/spreadsheets2/client/js/1273945346-ritz_waffle_i18n_core.js:3009:914
Bnb.prototype.render https://docs.google.com/static/spreadsheets2/client/js/1273945346-ritz_waffle_i18n_core.js:3066:439
...

Comment 23

[Mike Taylor [:miketaylr]]

Another interesting fact, that may or may not be related. When you backspace when entering text, the contenteditable div looks like so:

<div spellcheck="false" aria-hidden="false" class="input-box" style="background-color: rgb(255, 255, 255); padding: 1px 2px; font-size: 13px; max-width: 125px; max-height: 293px; display: inline-block; min-width: 94px; min-height: 16px; left: 146px; top: 160px; overflow: hidden;">
  <div class="cell-input editable" tabindex="0" role="combobox" id="waffle-rich-text-editor" style="ime-mode: auto; background-color: rgb(255, 255, 255); font-size: 13px; color: rgb(0, 0, 0); font-weight: 400; font-family: &quot;Arial&quot;; font-style: normal;" dir="ltr" g_editable="true" aria-autocomplete="list" contenteditable="true">
  <span style="font-size:13px;color:#000000;font-weight:400;text-decoration:none;font-family:'Arial';font-style:normal;">
    <br type="_moz">
  </span>
</div>
</div>

Note the <br type="_moz">

Comment 24

[Mike Taylor [:miketaylr]]

Let's go ahead and mark this as sitewait since Google is aware (see comment #21) -- I'm not able to get much farther than Firefox keeps freezing.

Comment 25

[Randell Jesup [:jesup] (needinfo me)]

mike - should this be fix-optional for 53, or are we expecting to get a fix and uplift?

Comment 26

[Mike Taylor [:miketaylr]]

We should fix-optional it, IMO, because the fix is probably on Google's side (until we hear back otherwise -- see Comment #21).

Comment 27

[Steven Saviano]

Yes, we put a fix in on the Google side. It should be rolling out early next week. Will update one fully rolled out.

Comment 28

[Steven Saviano]

Fix on Sheets landed in prod late last week.

Comment 29

[Mike Taylor [:miketaylr]]

Thanks Steven! Verified as FIXED.