Handling Unexpected Color Depth Bugs in Online Payment Systems

In our current project, we're creating a payment page for handling online payments. I finished all the tasks, tested a successful payment scenario, and was waiting for the testing to start. The initial tests went well, but then an interesting bug was discovered.

Here's a bit of context: When making a payment, you might be redirected to a 3DS page, where you'll need to enter a code from an SMS or confirm the payment in a mobile app — something we're all familiar with, I believe. For the 3DS page, browser data must be sent, and one of the parameters is the color depth (colorDepth). According to the 3D Secure specification, the color depth can be 1, 4, 8, 15, 16, 24, 32, or 48.

Now, back to the tricky issue. The tester reported that if you open two versions of the page on a separate monitor and a laptop and proceed with the payment, an error occurs with colorDepth = 30, which is not a valid value. If you open the page on just one screen, everything works fine. This issue only happens in Chrome; if it were Safari, I would understand 😁. When I connected an external monitor, the issue didn’t occur for me, but when I disconnected the external monitor, I managed to catch the error.

🤔 What to do? This situation seems quite strange. As I started working on the task, I found an interesting article where the author described my problem (link). It turns out that new MacBook monitors have a color depth of 30, which is a real value but not valid according to the CSSOM and 3DS specifications. An important point is that this only happens on Chromium engines, while in Safari and Firefox, everything works fine (colorDepth = 24). I also want to note that there’s an open bug for this issue in the Chrome bug tracker that has been there for several years.

Inspired by the author of the article I mentioned earlier, I created a proxy to fix the problem. This proxy handles the colorDepth value but only returns valid values for this parameter. You can find it on GitHub.

In my opinion, it's worth updating the specifications to include more permissible values for this parameter. Until that happens, we will use a Proxy.