Bug 168964 – [GTK] Completely garbled display in GMail

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Alberto Garcia]

Created attachment 302926 [details]
GMail screenshot

I started noticing this only a couple of days ago:

When I log in to GMail and try to use the Hangouts chat the display becomes garbled, and moving the cursor around only makes it worse. Menus stop appearing when you click on them and the UI becomes unusable.

I'm attaching a screenshot of the left bar.

The interesting thing is that this doesn't seem to be triggered by a WebKit update, and I actually reported bug 168769 using the same version of WebKitGTK+ (2.14.5).

I did however update many other packages on my system. I tried reverting the kernel, the X server and the video driver to the previous version but that didn't help. This problem seems to happens only with WebKitGTK+. Firefox or Chromium can open GMail just fine.

Another user reported to have a similar problem with WebKitGTK+ 2.15.90 and the hangouts.google.com website. I just tried that site with version 2.14.5 and it also breaks for me.

In case it's relevant I have an Intel HD Graphics video card (8086:0166).

[Carlos Garcia Campos]

hmm, this is similar to the issue Tomas had with duck duck go that ended up being a problem with the build options. The fact that it happens both forcing AC mode and disabling AC mode makes me think this has nothing to do with graphics drivers.

[Tomas Popela]

(In reply to comment #1)
> hmm, this is similar to the issue Tomas had with duck duck go that ended up
> being a problem with the build options.

I don't think this is related to the issue that I had. From that screenshot I can see that most of the GMail's UI is rendered corectly. For me I got only text and some links. The cause for me was that I used cmake's RelWithDebInfo build target and it was not passing some compiler flags. But it was fine with Release and Debug.

[Andres Gomez Garcia]

Can we increase the importance of this bug?

[Adrian Perez]

I cannot reproduce this in my system (details about versions below), and
while talking IRL with Andrés Gómez (who can still experience the issue)
the only differences we seem to have are:

 * Intel GPU:
    - Me:     Intel Skylake (gen9)
    - Andrés: Intel Sandybridge (gen6, gt2)

 * xf86-video-intel:
    - Me:     2.99.917+777+g6babcf15-1 (Arch Linux testing)
    - Andrés: 2.99.917+git20161206 (Debian Testing)

 * Xorg.conf options:
    - We are both using the defaults picked by the driver (SNA acceleration
      method, DRI2+DRI3 enabled).
    - Additionally, I have: Option "TearFree" "true"

Here goes the list of components I used for testing:

 - WebKitGTK+ trunk (r219194) + MiniBrowser (works)
 - WebKitGTK+ 2.17.4 + Epiphany 3.25.3 (works, too)
 - xf86-video-intel 2.99.917+777+g6babcf15-1 (Arch Linux package)
 - Mesa 17.1.4 (Arch Linux package)
 - libdrm 2.4.81 (Arch Linux package)
 - Linux 4.11.5 (“linux-pf“ package from AUR)

[Miguel Gomez]

Does this happen using WEBKIT_DISABLE_COMPOSITING_MODE=1 ?

[Andres Gomez Garcia]

Still reproducible with 2.17.4, using MiniBrowser, with and without plugins enabled.

$ glxinfo
...
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.1.4 (git-5a24aa8c55)
...

$ dpkg -l | grep video-intel
...
ii  xserver-xorg-video-intel                                         2:2.99.917+git20161206-1             amd64        X.Org X server -- Intel i8xx, i9xx display driver
...

$ journalctl -b
...
intel(0): SNA initialized with Sandybridge (gen6, gt2) backend
intel(0): direct rendering: DRI2 DRI3 enabled
...

$ uname -a
Linux xxxx 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2 (2017-06-12) x86_64 GNU/Linux


drm 2.4.81 (master)

[Andres Gomez Garcia]

(In reply to Miguel Gomez from comment #5)
> Does this happen using WEBKIT_DISABLE_COMPOSITING_MODE=1 ?

Yes. The corruption is somehow different.

Without the envvar, the active areas of the webpage (checkboxes, buttons, etc.) get copied stuff on top (like avatars).

With the envvar, the active areas get just the background color and only every now and then are properly redrawn.

[Adrian Perez]

(In reply to Adrian Perez from comment #4)
 
>  * xf86-video-intel:
>     - Me:     2.99.917+777+g6babcf15-1 (Arch Linux testing)
>     - Andrés: 2.99.917+git20161206 (Debian Testing)

I have located the Git commit IDs for those packaged versions of
xf86-video-intel:

 - Arch Linux: 6babcf15dd605ef40de53f5c34f95b7fd195edbe
   https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=6babcf15dd605ef40de53f5c34f95b7fd195edbe
   (This is the same as “master” as of 2017.07.06)

 - Debian: baec802b21387d04aebb10ac29e719a1800c5aa0
   https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=baec802b21387d04aebb10ac29e719a1800c5aa0

There's literally hundreds of commit in between both commits, and quickly
skimming over the commit logs there's many small fixes which potentially
can be related to rendering artifacts, some of them for specific for the
Sandybridge (gen6) GPUs, like the one Andrés Gómez has.

I think it could be worth it to get someone with a Sandybridge GPU and
a recent build of xf86-video-intel to check whether they get the rendering
artifacts.

Another option could be that the people who are experiencing the issue
try with a Wayland session, and if that way they don't experience the
glitches, we would know that xf86-video-intel is the culprit.

[Alicia Boya García]

Can't reproduce with the following setup:

* NVIDIA GeForce GT 630
* nvidia drivers 381.22
* Epiphany 3.24.2 (powered by WebKitGTK+ 2.16.5)
* Arch Linux x86_64

[Miguel Gomez]

(In reply to Andres Gomez Garcia from comment #7)
> (In reply to Miguel Gomez from comment #5)
> > Does this happen using WEBKIT_DISABLE_COMPOSITING_MODE=1 ?
> 
> Yes. The corruption is somehow different.
> 
> Without the envvar, the active areas of the webpage (checkboxes, buttons,
> etc.) get copied stuff on top (like avatars).
> 
> With the envvar, the active areas get just the background color and only
> every now and then are properly redrawn.

Then we know the problem is not related to OpenGL. As Adrián mentions, it has to be something in X.
It would be great if you could run the browser inside a Wayland sesion, as Adrián mentions. You can also try to do it inside a Weston instance on X, but I guess a problem in X would affect that rendering as well.

[Michael Catanzaro]

Also, Andres, please uninstall xf86-video-intel and see if it still happens with that gone.

[Charlie Turner]

Can't reproduce with the following setup

$ glxinfo
...
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.0.5
...

$ rpm -q xorg-x11-drv-intel
xorg-x11-drv-intel-2.99.917-26.20160929.fc25.x86_64

$ journalctl -b
...
[drm] Initialized i915 1.6.0 20170123 for 0000:00:02.0 on minor 0
...

$ lspci -vvv
...
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
	Subsystem: Gigabyte Technology Co., Ltd Device d000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 28
	Region 0: Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at f000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915
...

$ uname -a
Linux xxx 4.11.7-200.fc25.x86_64 #1 SMP Mon Jun 26 15:58:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Webkit (r219207) + MiniBrowser.

[Sergio Villar Senin]

Berto are you seeing the same type of garbled display in http://www.ondacero.es/directo/eventos/ just below the main banner on the left?

It's supposed to be a placeholder for multimedia player controls but I just see a corrupted rendering. I'm attaching a screenshot to demonstrate the issue soon.

[Andres Gomez Garcia]

(In reply to Miguel Gomez from comment #10)

...

> Then we know the problem is not related to OpenGL. As Adrián mentions, it
> has to be something in X.

Not sure how you get to that conclusion, but you are the expert O:)

> It would be great if you could run the browser inside a Wayland sesion, as
> Adrián mentions. You can also try to do it inside a Weston instance on X,
> but I guess a problem in X would affect that rendering as well.

In a pure GNOME on Wayland session, I've been able to reproduce the same behavior with the Debian system packages for testing:

mesa: 13.0.6-1+b2
drm: 2.4.74-1
WKGTK: 2.16.3
Ephy: 3.22.7
libwayland-server0: 1.12.0-1
libweston-1-0: 1.12.0-3          

Linux xxxx 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2 (2017-06-12) x86_64 GNU/Linux

[Andres Gomez Garcia]

Also:

$ lspci -v 

...

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA con
troller])
        Subsystem: Lenovo 2nd Generation Core Processor Family Integrated Graphics Controller
        Flags: bus master, fast devsel, latency 0, IRQ 36
        Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 5000 [size=64]
        [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: i915
        Kernel modules: i915

[Andres Gomez Garcia]

(In reply to Michael Catanzaro from comment #11)
> Also, Andres, please uninstall xf86-video-intel and see if it still happens
> with that gone.

Without video-intel and using modesetting, same result. Also, using:

Mesa 17.1.4
drm 2.4.81 (master)

[Andres Gomez Garcia]

Also reproducible with MiniBrowser and passing to Mesa 17.1.4 the LIBGL_ALWAYS_SOFTWARE=1 variable; hence, using the llvmpipe driver, not the Intel one.

[Andres Gomez Garcia]

(In reply to Alberto Garcia from comment #0)
...
> In case it's relevant I have an Intel HD Graphics video card (8086:0166).

That's an Ivy Bridge card:
http://www.thinkwiki.org/wiki/Intel_HD_Graphics

[Alberto Garcia]

(In reply to Sergio Villar Senin from comment #13)
> Berto are you seeing the same type of garbled display in
> http://www.ondacero.es/directo/eventos/ just below the main banner
> on the left?

No, that page works fine.

[Alberto Garcia]

I can also reproduce this with Flatpak, using the WebKitGTK+ version shipped with the latest GNOME 3.22 runtime:

$ flatpak run --devel --command=/usr/libexec/webkit2gtk-4.0/MiniBrowser <app>

org.gnome.Platform/x86_64/3.22           gnome d44159b609a6 - 681,1 MB  system
org.gnome.Sdk/x86_64/3.22                gnome 7ec9b226b95c - 1,5 GB    system

[Adrian Perez]

*** Bug 174938 has been marked as a duplicate of this bug. ***

[Alberto Garcia]

I actually managed to reproduce this problem using QEMU and a Debian jessie VM.

This happens even if I emulate a Cirrus Logic GD 5446 video card from 1996.

webkitgtk 2.16.5-1~bpo8+1
xorg-video-cirrus 1:1.5.2-2+b1
mesa 10.3.2-1+deb8u1
libdrm 2.4.58-2
Linux 3.16.7

[Sergio Villar Senin]

Created attachment 316808 [details]
Another example of garbled display

I think I've just reproduced it here. In my case outside GMail while viewing the CSS Grid Layout specs.

I'm using Debian's 2.16.5 version of webkitgtk

[Alberto Garcia]

(In reply to Sergio Villar Senin from comment #23)
> I think I've just reproduced it here.

Yeah, I have the same problem with https://drafts.csswg.org/css-grid/

[Alberto Garcia]

(In reply to Alberto Garcia from comment #22)
> I actually managed to reproduce this problem using QEMU and a Debian jessie
> VM.
> 
> This happens even if I emulate a Cirrus Logic GD 5446 video card from 1996.
> 
> webkitgtk 2.16.5-1~bpo8+1
> xorg-video-cirrus 1:1.5.2-2+b1
> mesa 10.3.2-1+deb8u1
> libdrm 2.4.58-2
> Linux 3.16.7

Btw, I downgraded webkitgtk to 2.6.2 in this setup and GMail is still doing weird things.

[Adrian Perez]

(In reply to Alberto Garcia from comment #22)
> I actually managed to reproduce this problem using QEMU and a Debian jessie
> VM.

This makes me think that WebKitGTK+ is triggering a non-accelerated (fallback?)
code path in Mesa, which is used both by the swrast/llvmpipe and also by the
Intel driver in older generations of GPUs — newer Intel chips would implement
the same feature in hardware and that would explain why they don't seem to be
affected. That would mean that WebKit is doing something it shouldn't but GPUs
accept anyway, or that there is a buggy software fallback in Mesa.

Does this hypothesis make sense?

[Sergio Villar Senin]

I think this issue is more serious than just a couple of sites not working. I'm getting garbled displays very often, like 10 times a day. Sometimes the contents of some tabs are mixed with the contents of some others that were previously closed.

Some other times navigating to another webpage does not refresh the previous render. Hit testing works because the cursor changes but the previous page is still shown.

:(

[Adrian Perez]

(In reply to Sergio Villar Senin from comment #27)
> I think this issue is more serious than just a couple of sites not working.
> I'm getting garbled displays very often, like 10 times a day. Sometimes the
> contents of some tabs are mixed with the contents of some others that were
> previously closed.
> 
> Some other times navigating to another webpage does not refresh the previous
> render. Hit testing works because the cursor changes but the previous page
> is still shown.
> 
> :(

Could you add a comment with the kind of GPU you have, and the versions of
the related packages (Mesa, libdrm, video driver, etc)? So far the issue
seems to be reproducible only with Intel Sandybridge GPUs, and with Mesa's
software rendering. The more we can confirm that the issue affects only
certain hardware/software combinations, it can make it easier to try and
debug the issue. Thanks!

[Sergio Villar Senin]

(In reply to Adrian Perez from comment #28)
> (In reply to Sergio Villar Senin from comment #27)
> > I think this issue is more serious than just a couple of sites not working.
> > I'm getting garbled displays very often, like 10 times a day. Sometimes the
> > contents of some tabs are mixed with the contents of some others that were
> > previously closed.
> > 
> > Some other times navigating to another webpage does not refresh the previous
> > render. Hit testing works because the cursor changes but the previous page
> > is still shown.
> > 
> > :(
> 
> Could you add a comment with the kind of GPU you have, and the versions of
> the related packages (Mesa, libdrm, video driver, etc)? So far the issue
> seems to be reproducible only with Intel Sandybridge GPUs, and with Mesa's
> software rendering. The more we can confirm that the issue affects only
> certain hardware/software combinations, it can make it easier to try and
> debug the issue. Thanks!

It's happening also with Kaby Lake

libwebkit2gtk-4.0-37 2.16.6-1 
mesa 13.0.6-1+b2
libdrm-intel1 2.4.81-2
Linux 4.11.0-1-amd64

$ glxinfo
...
direct rendering: Yes
...
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics P630 (Kaby Lake GT2)  (0x591d)

[Michael Catanzaro]

(In reply to Sergio Villar Senin from comment #27)
> I think this issue is more serious than just a couple of sites not working.
> I'm getting garbled displays very often, like 10 times a day. Sometimes the
> contents of some tabs are mixed with the contents of some others that were
> previously closed.

That sounds like bug #174632

[Alberto Garcia]

This problem is still happening in 2.18.0

[Adrian Perez]

Still working for me in 2.18.0

[Alberto Garcia]

I just rebuilt 2.14.0 for my current system (Debian 9) and the bug is still there.

I'd swear that when I was using 2.14.0 back in the day I wasn't having this problem. I'll try with an older WebKit version just in case.

[Alberto Garcia]

I just tried with an older computer, also running Debian, here I can NOT reproduce the problem. Everything seems to work fine.

libwebkit2gtk-4.0-37 2.16.3-2~bpo8+1
mesa 10.3.2-1+deb8u1
libdrm-intel1 2.4.58-2
Linux 3.16.43-2+deb8u3

$ glxinfo
...
direct rendering: Yes
...
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 965GM x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 10.3.2

[Alicia Boya García]

Do we have concrete steps to reproduce the problem in affected platforms with
100% confidence?

If that's the case we could run a small survey to figure out the exact
configurations where it fails.

[Alberto Garcia]

(In reply to Alicia Boya García from comment #35)
> Do we have concrete steps to reproduce the problem in affected platforms with
> 100% confidence?
> 
> If that's the case we could run a small survey to figure out the exact
> configurations where it fails.

When you log in to GMail there are three buttons on the lower left side,
the one in the middle is used to open Hangout chats. If you click on that
one you get a small window with the most recent conversations. Then you can
open individual conversations from there.

Doing that is a very easy way to reproduce the problem, but often it's enough
if you just open GMail and try to read an e-mail, or resize the browser window.

The hangouts web app at https://hangouts.google.com/ has the same problem.

[Alberto Garcia]

Looking at the version numbers shown here so far I'd say that we never
introduced any regression in WebKitGTK+, but it was a change in mesa or
some other library that triggered the problem.

The question is of course why in the affected systems the problem doesn't
show up with other browsers.

One other odd thing is that I can reproduce the problem in a VM
running the same Debian version as this computer (see comment #22).

[Alicia Boya García]

Maybe we should put our results into a table.

I could not reproduce the issue with my new computer either:

OpenGL renderer string: Gallium 0.4 on AMD POLARIS11 (DRM 3.15.0 / 4.12.11-300.fc26.x86_64, LLVM 4.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.7
Running epiphany 3.24.3 on Wayland

[Alicia Boya García]

Neither I could reproduce it on my laptop:

OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.7
Running epiphany 3.24.3 on X11

[Salil]

The display is still garbled for gmail for me.

OpenGL renderer string: NV106
OpenGL core profile version string: 4.3 (Core Profile) Mesa 17.2.0
OpenGL version string: 3.0 Mesa 17.2.0
OpenGL shading language version string: 1.30

epiphany-browser version: 3.25.92 on X11

[Carlos Garcia Campos]

Note that it also happens with AC disabled, so the opengl/mesa version shouldn't matter.

[Beau Adkins]

Not sure if this helps, but I experienced an issue with GMail display getting all messed up in the 2.14 series. I tracked it down to the emoji's in the hangouts interface. Gmail will work fine UNLESS you cause one of the hangouts emojis to be visible on the screen.

Does that help reproduce it reliably?

[Salil]

I don't have any hangout or tasks window open, just plain mail interface window. And the page is messed up still.

[Salil]

Sorry, I mistook your comment to mean a separate hangout popup. You are right. The problem seems related to the hangout icons displayed, because these icons get replicated all over the place along the mouse pointer trajectory.

[Beau Adkins]

Ok, yeah the bug I saw only showed up if there was a hangout emoji visible on the screen anywhere.

Here is a bug report I put in for it: https://bugs.webkit.org/show_bug.cgi?id=171459 . The interesting part is this:

"Further testing reveals this to be completely related to the display of emojis. If there is supposed to be an emoji visible in the chat window, the entire page display gets messed up in strange ways. Seems to be related to Google's recent change to change the PNG that holds all the emojis from a grid to a single column. The png is now something like 28px X 33000px. I believe this is too tall for WebKit to handle correctly, but I can't figure out why."

I worked around it by creating a WebKitUserScript to detect this page, and alter its CSS rules to revert back to an older style which uses a more squared PNG.

[Michael Catanzaro]

*** Bug 171459 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

(In reply to Beau Adkins from comment #45)
> The png is now something like 28px X 33000px. I
> believe this is too tall for WebKit to handle correctly, but I can't figure
> out why."

That's very likely the cause, indeed. Thanks for investigating.

[Miguel Gomez]

Created attachment 321310 [details]
Patch

[Miguel Gomez]

(In reply to Beau Adkins from comment #45)
> Ok, yeah the bug I saw only showed up if there was a hangout emoji visible
> on the screen anywhere.
> 
> Here is a bug report I put in for it:
> https://bugs.webkit.org/show_bug.cgi?id=171459 . The interesting part is
> this:
> 
> "Further testing reveals this to be completely related to the display of
> emojis. If there is supposed to be an emoji visible in the chat window, the
> entire page display gets messed up in strange ways. Seems to be related to
> Google's recent change to change the PNG that holds all the emojis from a
> grid to a single column. The png is now something like 28px X 33000px. I
> believe this is too tall for WebKit to handle correctly, but I can't figure
> out why."
> 
> I worked around it by creating a WebKitUserScript to detect this page, and
> alter its CSS rules to revert back to an older style which uses a more
> squared PNG.

I've finally been able to reproduce this issue with this info. Many thanks Beau!! In order yo reproduce it you just need to open a conversation in hangouts that contains emojis.

Indeed, this is caused by using such a large image, as cairo is not able to handle images that big due to a pixman limitation (the limit is 32768 pixels). The patch I've uploaded disables the rendering for images that are bigger than the cairo limit, so the rendering of the rest of the page doesn't break. The problem about this is that emojis won't be visible on hangout conversations, but we don't any other way to fix this for the moment.

[Carlos Garcia Campos]

Comment on attachment 321310 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=321310&action=review

Thanks!

> Source/WebCore/platform/graphics/ImageBackingStore.h:37
> +#define CAIRO_MAX_IMAGE_SIZE 32768

Use a static variable instead.

> Source/WebCore/platform/graphics/ImageBackingStore.h:185
> +#if USE(CAIRO)
> +        // If the image is bigger than the cairo limit it can't be displayed, so we don't event
> +        // try to decode it.
> +        if (size.width() > CAIRO_MAX_IMAGE_SIZE || size.height() > CAIRO_MAX_IMAGE_SIZE)
> +            return true;
> +#endif

Ok, this is much better than screwing the whole page, but it's a workaround in the end. Do you think it would be possible to implement support for decoding and rendering images bigger than the cairo limit? maybe using some kind of tiles or whatever? If it's possible, please file a bug report and add a FIXME here with the bug url

[Miguel Gomez]

> Ok, this is much better than screwing the whole page, but it's a workaround
> in the end. Do you think it would be possible to implement support for
> decoding and rendering images bigger than the cairo limit? maybe using some
> kind of tiles or whatever? If it's possible, please file a bug report and
> add a FIXME here with the bug url

Yes, I guess we could use something like tiled images. We would need to replace the current NativeImagePtr (currently cairo_surface_t) with some new class that would be wrapping several cairo surfaces. Maybe we could even reuse the TiledBackingStore for that.

I've created https://bugs.webkit.org/show_bug.cgi?id=177227 to handle that.

[Alberto Garcia]

I confirm that this solves the problem for me.

Thank you Beau for narrowing down the problem, and Miguel for fixing
it!!

                                    (
                       (
               )                    )             (
                       )           (o)    )
               (      (o)    )     ,|,            )
              (o)     ,|,          |~\    (      (o)
              ,|,     |~\    (     \ |   (o)     ,|,
              \~|     \ |   (o)    |`\   ,|,     |~\
              |`\     |`\@@@,|,@@@@\ |@@@\~|     \ |
              \ | o@@@\ |@@@\~|@@@@|`\@@@|`\@@@o |`\
             o|`\@@@@@|`\@@@|`\@@@@\ |@@@\ |@@@@@\ |o
           o@@\ |@@@@@\ |@@@\ |@@@@@@@@@@|`\@@@@@|`\@@o
          @@@@|`\@@@@@@@@@@@|`\@@@@@@@@@@\ |@@@@@\ |@@@@
          p@@@@@@@@@@@@@@@@@\ |@@@@@@@@@@|`\@@@@@@@@@@@q
          @@o@@@@@@@@@@@@@@@|`\@@@@@@@@@@@@@@@@@@@@@@o@@
          @:@@@o@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@o@@::@
          ::@@::@@o@@@@@@@@@@@@@@@@@@@@@@@@@@@@o@@:@@::@
          ::@@::@@@@::oo@@@@oo@@@@@ooo@@@@@o:::@@@::::::
          %::::::@::::::@@@@:::@@@:::::@@@@:::::@@:::::%
          %%::::::::::::@@::::::@:::::::@@::::::::::::%%
          ::%%%::::::::::@::::::::::::::@::::::::::%%%::
        .#::%::%%%%%%:::::::::::::::::::::::::%%%%%::%::#.
      .###::::::%%:::%:%%%%%%%%%%%%%%%%%%%%%:%:::%%:::::###.
    .#####::::::%:::::%%::::::%%%%:::::%%::::%::::::::::#####.
   .######`:::::::::::%:::::::%:::::::::%::::%:::::::::'######.
   .#########``::::::::::::::::::::::::::::::::::::''#########.
   `.#############```::::::::::::::::::::::::'''#############.'
    `.######################################################.'
      ` .###########,._.,,,. #######<_\##################. '
         ` .#######,;:      `,/____,__`\_____,_________,_____
            `  .###;;;`.   _,;>-,------,,--------,----------'
                `  `,;' ~~~ ,'\######_/'#######  .  '
                    ''~`''''    -  .'/;  -    '

[Miguel Gomez]

Created attachment 321312 [details]
Patch

[Adrian Perez]

If this issue is related to the size of an image provided by
GMail/Hangouts, why are things working fine for me? Shouldn't
big images trigger there issue in every system where Pixman is
used, including mine?

[Beau Adkins]

Glad to hear I was able to help. This bug was severely impacting a customer of hours a few months back so I was throwing everything I had at it.

My resolution was to fix it at the application level. Its a super specific hack just to get emojis on hangouts working, but if you guys are interested, here are the details. You could use it to put in a workaround for this specific issue until you fix the cairo problem.

If we detect the page loaded is "hangouts.google.*", we walk the CSS rules to replace "-webkit-min-device-pixel-ratio: 1.5" with "-webkit-min-device-pixel-ratio: 1.0". That rule change causes hangouts to fallback to the grid style image, which works fine.

[WebKit Commit Bot]

Comment on attachment 321312 [details]
Patch

Clearing flags on attachment: 321312

Committed r222264: <http://trac.webkit.org/changeset/222264>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Adrian Perez]

(In reply to Beau Adkins from comment #55)
 
> If we detect the page loaded is "hangouts.google.*", we walk the CSS rules
> to replace "-webkit-min-device-pixel-ratio: 1.5" with
> "-webkit-min-device-pixel-ratio: 1.0". That rule change causes hangouts to
> fallback to the grid style image, which works fine.

Ah, that explains why it has been working fine for me: I have a HiDPI
screen, which having 2x scaling makes it have “device-pixel-ratio: 2.0”,
which matches the minimum of 1.5!

Wow.