A month ago, the Maproom directors spotted that one of our demo maps was inexplicably showing hundreds of rays emanating from a point in the Atlantic Ocean off the northwest coast of Ireland.
We found odd bugs on several other maps – maps that had worked perfectly for years in all major browsers were displaying peculiar artefacts at different zoom levels. The artefacts were observed only in Chrome, not Safari, Edge or Firefox.
The Chrome browser console was logging the error: “GL_INVALID_OPERATION: glDrawElements: Vertex buffer is not big enough for the draw call.”
The first instinct of most developers is to assume that we had broken something ourselves. However, after checking recent deployments, testing different datasets, reviewing JavaScript changes and trying to reproduce the issue across multiple environments, nothing pointed to a fault in our Dynamic Mapping Suite. We could see the artefacts occurring in the Mapbox bases too, but it wasn’t Mapbox at fault either. The culprit for the messed-up maps was much further down the stack: to be precise, the most recent update of Chrome: version 148.0.7778.168 and its handling of Apple’s Metal API for ANGLE. In other ways, it messed up the way in which an Apple Mac reads and renders complex graphics.
Not just our maps
The problem wasn’t limited to Maproom.
Developers across the geospatial sector reported similar issues. Esri, for example, documented a Chromium defect that caused rendering failures and WebGL errors in applications built with the ArcGIS Maps SDK, affecting map display and performance until a browser fix was released.
Whenever a browser vendor ships a regression affecting graphics acceleration or WebGL, mapping applications tend to be among the first casualties because they push browser rendering systems far harder than typical websites.
The history of the complex technical issue is logged here: https://issues.chromium.org/issues/513487198.
The challenge of diagnosing browser bugs
One of the hardest aspects of web development is that your application ultimately runs inside software you don’t control.
When a browser update introduces a regression, developers often spend hours – or even days – investigating their own code before discovering that the fault lies elsewhere.
That’s exactly what happened here. Because the bug only appeared under certain conditions and configurations, it was easy to assume the problem was related to specific datasets, graphics drivers, operating system updates, or recent application changes. Only after enough reports accumulated across multiple mapping platforms did a broader pattern emerge.
The experience was a reminder that modern web mapping relies on a remarkably complex chain of technologies:
- Browser rendering engines
- Graphics drivers
- WebGL implementations
- Operating system graphics frameworks
- JavaScript mapping libraries
A fault in any one of those layers can bring an otherwise healthy application to a halt.
The good news
We found a temporary workaround during the period of disruption, which was to reduce the number of map layers from loading at low zoom levels. This was not a perfect fix, as there were still faint, almost ghostly line artefacts showing, but the sheer visual disruption was minimised.
The Chromium team itself investigated the issue within a few days of us and other GIS developers reporting it, and the bug has now been fixed. Users running current versions of Chrome (as of Chrome version 149 released in the first week of June 2026) should no longer encounter the problem.
For anyone who experienced broken maps on their Mac computers during the affected period (about three weeks) – apologies for the inconvenience – the solution is to update to Chrome’s latest version.