1244792 - Gmail composition textbox "checkerboards" during scrolling

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P3)

Description

[Botond Ballo [:botond]]

STR:

  1. Write a long email in GMail, such that the textbox
     for composing the email overflows vertically.

  2. Scroll the email contents with the mouse wheel.

Expected results:
  During async scroll, areas brought into view by scrolling
  are already rendered.

Actual results:
  During async scroll, areas brought into view by scrolling
  are blank, until a repaint renders them.

This is not checkerboarding in the conventional sense (for example, it doesn't produce reports in about:checkerboard).

Comment 2

[Benoit Girard (:BenWa)]

Attachment: gmailscroll.gif

Here's what I see.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I'm pretty sure this is an issue on the website, but bug 1232491 may help here. As long as it's just a transient thing though I don't know if it's worth spending a lot of time on.

Comment 4

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #3)
> As long as it's just a transient thing though I don't know if it's
> worth spending a lot of time on.

Ehsan reported being thoroughly annoyed by this behaviour.

Do we have an understanding of what is that the website is doing to cause this? Would it help if we reached out the Gmail devs about this?

Comment 5

[Kartikaya Gupta (email:[e-mail])]

So actually I'm not seeing this any more. I tried in OS X Nightly, using (1) the "compose" dialog (which shows up in the bottom-right corner of the gmail window), (2) the "compose" dialog maximized, so that it's centered in the window, (3) a reply box to an existing email. I pasted in 50 paragraphs of lorem ipsum text and scrolled madly up and down on OS X. The only checkerboarding I saw was actual APZ checkerboarding with the pink background (I have the pref set).

Were you seeing this on Linux only?

Comment 6

[Botond Ballo [:botond]]

ni?myself to retest this when I'm in the office tomorrow.

ni?Ehsan to see what OS he was using when he experienced this.

Comment 7

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #6)
> ni?myself to retest this when I'm in the office tomorrow.

I definitely do still see this with latest Linux Nightly.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Which of the compose/reply boxes listed in comment 5 do you see it in? All of them?

Comment 9

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #8)
> Which of the compose/reply boxes listed in comment 5 do you see it in? All
> of them?

Ah - only the reply box. It hasn't even occurred to me to check the compose boxes; my bad.

Comment 10

[(no longer active)]

(In reply to Botond Ballo [:botond] from comment #6)
> ni?Ehsan to see what OS he was using when he experienced this.

OSX latest.

Comment 11

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #3)
> I'm pretty sure this is an issue on the website, but bug 1232491 may help
> here.

I had a look at some display list dumps while this was happening. The text that's scrolled into view but only becomes visible on the next paint - that's already in the display list in the previous paint. So, I don't think this is the sort of issue with the website that bug 1232491 would solve. It may be a different issue with the website, or our issue after all.

Comment 12

[Botond Ballo [:botond]]

Markus and I looked at this in some more detail. What's happening is, the content being scrolled into view (the email text and the border around it) are in the DOM (and the display list etc.), but the portion the site believes to be out of view is covered up by another element (an element with class "aC2"), which is anchored to the bottom of the scrollable area, and whose height is adjusted by script. When content is async-scrolled into view, until the script makes the corresponding height adjustment, the text that's newly scrolled into view is covered up by this element.

This confirms that the issue is with the site.

Comment 13

[Karl Dubost💡 :karlcow]

Adding needsdiagnosis so that Comment #12 is explained in terms of code, URI and suggestions to fix it. 
Once done we can switch to contactready and ni :karlcow so I can go on contacting Google about it.
Also is there a difference with Chrome/Safari and why?

Comment 14

[Kartikaya Gupta (email:[e-mail])]

Note that we (and by that I mean Botond) have already contacted google about this using the mailing list that was set up, and we got a response back from them that they would try to fix it at some point in the near future.

Comment 15

[Karl Dubost💡 :karlcow]

Ah indeed… July 16, 2016. I had missed this.
Message-Id : <CAHzMtdtkLX=5OEq8y5iH2w2-DCijBGX9vJDpAp=[e-mail]>

Switching to sitewait. Thanks kats!

Comment 16

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

Is this re-producing :botond? If so — perhaps worth re-pinging the DL thread as it's been a few months...

Comment 17

[Botond Ballo [:botond]]

(In reply to Desigan Chinniah [:cyberdees] [:dees] [London - GMT] from comment #16)
> Is this re-producing :botond? If so — perhaps worth re-pinging the DL thread
> as it's been a few months...

It does still reproduce. I pinged the thread as suggested.

Comment 18

[Sergiu Logigan [:sergiu]]

I think that with the new GMail design, that was fixed.
:botond can you still reproduce?

We tested on Windows 10 and Nightly 63, but the scrolling was performed perfectly. We used a HTML format e-mail.

Comment 19

[Botond Ballo [:botond]]

I can confirm that the issue no longer reproduces! It seems to have been fixed on GMail's side.