Closed Bug 1570736 Opened 4 months ago Closed Last month

Webrender completely broken on Mac (10.14, Intel HD Graphics 4000)


(Core :: Graphics: WebRender, defect, P3)

70 Branch



Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- unaffected
firefox70 --- verified
firefox71 --- fixed
firefox72 --- fixed


(Reporter: robin, Assigned: kvark)


(Blocks 1 open bug, Regression)


(Keywords: regression)


(6 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Installed latest Nightly 2 days ago, restarted Firefox. This on a Macbook Air 11" 2012 on latest 10.14.6. So that means Intel i5 with HD Graphics 4000, with Webrender manually enabled.

Actual results:

Complete font and image breakage. Rendering boxes and general layout components seems to still work. See screenshots.

Expected results:

Normal display. If I turn webrender off (manual editing of prefs.js is easiest) then we’re back to normal; I’m filing this bug from that setup.

Component: Untriaged → Graphics: WebRender
Product: Firefox → Core
Blocks: wr-mac
OS: Unspecified → macOS
Hardware: Unspecified → x86_64
Priority: -- → P3

Attempted to reproduce, but was unable to get the issue to manifest with devices having Intel IRIS pro 1536, Intel IRIS plus 650.
Your issue might be limited to the graphics setup.

@Robin, any chance you could install mozregression and run a check for the regression range?

Flags: needinfo?(robin)

Oof, the corruption you're seeing is a classic example of us messing up the texture cache (basically everything that we cache a rasterization of like images/glyphs gets replaced with random textures). Sadly something that can happen in various different ways. Haven't seen this on any of our macs yet, though. Maybe the supplemental macos update that just came out is involved ( Do you have that one installed yet? (sadly I don't think it shows up as a difference in macos version number)

A regression range would definitely be helpful.

Nope, this is post 10.14.6, pre supplemental update. I’ll run mozregression though and get back to you with a range.

Awesome, thanks!

I also managed to reproduce this locally! Found an old 2012 macbook air in the office and updated it (was running macos 10.10 and firefox 56 🙀).

Ever confirmed: true
Assignee: nobody → dmalyshau

The texture cache is fine. Problem only manifests itself when sampling from it with swizzling states set up. It looks like setting those GL_TEXTURE_SWIZZLE states corrupts the other sampling parameters, likely a driver bug. Only seen on Intel 4000 so far - the same machine running on NVidia is fine (i.e. even replaying the same WR capture).

I've added it to
Currently trying to narrow down the bug in
As a short term solution we could also flip "allow_texture_swizzling = false" in RendererOptions when we detect Intel 4000 series GPU on MacOS.

Managed to reproduce it, at last, in the artificial test app. Basically, setting up the swizzle state on a texture unit breaks the result of textureSize instruction of GLSL, which WebRender relies on. I believe the best course of action is to blacklist swizzling for IvyBridge GPU family on Mac.

Investigation showed that on this platform the texture unit state becomes
corrupted whenever we set the non-identity swizzling (getting garbage from textureSize()).
Given no easy workaround, we disable swizzling for this GPU family on Mac, for now.

Pushed by
Force disable WR swizzling on Intel 4000 on Mac r=aosmond
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Attached image Demo of the broken UI

This patch fixes the original problem, but seems to have introduced interesting colour shifts. This appears to be a ROT13 style problem (can you tell I’m not a graphics person?) as the screenshots of the broken behaviour appear fine in the preview display of the bug upload field.

Robin: yes, this is known and filed separately as Bug 1572843. The fix is going through the review now.

OK, cool, I’ll VERIFY this one as fixed then.


Macbook Air 13 Mid 2011, macbookair 4,2, Intel HD 3000 384 MB.
MacOs High Sierra 10.13.6 (17G8037)

The bug is still there. Just upgraded to firefox 70.

We blocklisted Intel 4000, while your device is HD 3000... Let's follow-up with blocklisting the swizzling code for this as well.

Resolution: FIXED → ---
Pushed by
Blocklist WR swizzling on HD3000 r=jrmuizel
Closed: 4 months agoLast month
Resolution: --- → FIXED
Target Milestone: mozilla70 → mozilla72

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Please nominate this for Beta uplift when you get a chance.

Flags: needinfo?(dmalyshau)

Comment on attachment 9104646 [details]
Blocklist WR swizzling on HD3000

Beta/Release Uplift Approval Request

  • User impact if declined: Intel HD3000 users on macOS would get broken WebRender (although they still have to opt into that)
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): It's just expanding the blocklist, not risky.
  • String changes made/needed:
Flags: needinfo?(dmalyshau)
Attachment #9104646 - Flags: approval-mozilla-beta?
Attachment #9084136 - Flags: approval-mozilla-beta?


I verified and in nightly the bug has gone. So apparently the fix is working.

Comment on attachment 9104646 [details]
Blocklist WR swizzling on HD3000

Low risk, Webrender fix for a subset of our mac user-base by blocklisting a board model, approved for 71 beta 6, thanks.

Attachment #9104646 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9084136 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.