Using the Mac build from https://treeherder.mozilla.org/#/jobs?repo=try&revision=91dc4f334fc5 (This does NOT reproduce on mozilla-central because bug 1082598 has not landed yet.) gfx/skia/skia/src/gpu/GrClipMaskManager.cpp:406: failed assertion "result"

I was not able to reproduce this on Linux. We should check after the Skia update if this is OS X specific.

Jesse: does this still reproduce?

I can reproduce it on OS X. The comment around the assertion is "If createAlphaClipMask fails it means useSWOnlyPath has a bug"

I still can't get this one to reproduce here, so it is somehow localized to OS X and not just SkiaGL. Mason, do you want to take a look into this one since it should be easy for you to pinpoint?

So after investigation with Mason, we found this bug is a result of the SkiaGL backend creating clip masks using a GL_ALPHA8 render target. The problem is the FBO spec is somewhat "nebulous" on this, or at least confusing, and while the spec says ALPHA8 should be color-renderable in compatibility contexts, OS X is still reporting framebuffer incompleteness when trying to use them (there is potentially room for this in the "implementation-dependent" get-out-of-jail-free clause). So it could be Skia is wrong to assume this, or that the OS X implementation of legacy compatibility contexts is not quite right. In any case, we have a workaround in that Skia will use GL_RED8 instead of GL_ALPHA8 so long as we report GL_ARB_texture_rg in the extension string. This patch detects the GL_ARB_texture_rg extension and also adds a feature entry for it, since an implementation may only report it via GL version and not via extension (as OS X does). This should pretty much always be present if the context if 3.0+ or GL_ARB_framebuffer_object is present on OS X. With this, Skia uses GL_RED8 for the clip mask and all is well.

Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f895173ce18e