Google sheets cell height often doubles in size unexpectedly

VERIFIED FIXED

Status

Tech Evangelism
Desktop
VERIFIED FIXED
a year ago
11 months ago

People

(Reporter: birtles, Unassigned)

Tracking

({regression})

Trunk
regression

Firefox Tracking Flags

(platform-rel +, firefox52 fixed, firefox53 fixed, firefox54 fixed)

Details

(Whiteboard: [platform-rel-Google][platform-rel-GoogleSuite][platform-rel-GoogleSheets][sitewait])

Attachments

(1 attachment)

Comment hidden (empty)
(Reporter)

Comment 1

a year ago
(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.
(Reporter)

Comment 2

a year ago
Created attachment 8819702 [details]
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.)
(Reporter)

Comment 3

a year ago
I just managed to reproduce this using Firefox 51 so I suspect this is a change on the Google Sheets side.
Keywords: regression
(Reporter)

Comment 4

a year ago
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.
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.
Component: DOM: Events → Desktop
Flags: needinfo?(twisniewski)
Product: Core → Tech Evangelism
(Reporter)

Comment 6

a year ago
Just Firefox. I tried to reproduce with Chrome but could not.
> 
> 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.
This happens to me too on release; an additional newline appears to be added to the cell.
(Reporter)

Comment 9

a year ago
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.
(Reporter)

Comment 10

a year ago
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

a year ago
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.
Flags: needinfo?(twisniewski)

Comment 12

a year ago
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?
> 
> 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...
(Reporter)

Comment 14

a year ago
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

a year ago
(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).
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.
Flags: needinfo?(miket)
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.
Flags: needinfo?(miket)
Perhaps :ssaviano can route Comment 18 STR to the right Sheets folks...
platform-rel: --- → +
Flags: needinfo?(ssaviano)
Whiteboard: [platform-rel-Google][platform-rel-GoogleSuite][platform-rel-GoogleSheets]
Note: I'm still looking at this, it'd be nice to some more info to pass along to Google. Should have something soon.
platform-rel: + → ---

Comment 21

a year ago
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.
Flags: needinfo?(ssaviano)
(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
...
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">
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.
Whiteboard: [platform-rel-Google][platform-rel-GoogleSuite][platform-rel-GoogleSheets] → [platform-rel-Google][platform-rel-GoogleSuite][platform-rel-GoogleSheets][sitewait]
mike - should this be fix-optional for 53, or are we expecting to get a fix and uplift?
Flags: needinfo?(miket)
We should fix-optional it, IMO, because the fix is probably on Google's side (until we hear back otherwise -- see Comment #21).
Flags: needinfo?(miket)
status-firefox53: affected → fix-optional

Comment 27

a year ago
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

11 months ago
Fix on Sheets landed in prod late last week.
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → FIXED
Thanks Steven! Verified as FIXED.
Status: RESOLVED → VERIFIED
status-firefox52: --- → fixed
status-firefox53: fix-optional → fixed
status-firefox54: --- → fixed
You need to log in before you can comment on or make changes to this bug.