Reporting Browser Bugs

While grid has been in development for over five years, there have been very few web developers actually building and experimenting with it. This means that there may well be cases where unexpected things happen – in particular when grid interacts with other parts of CSS. This is where you come in, if you find an issue now it might be fixed before grid ships. The web community will salute you.

So, how does a regular person go about reporting a browser bug? The first thing you need to know is whether you have a bug.

Is it a bug … or am I being an idiot?

I know CSS pretty well, but the majority of things I suspect to be a browser bug turn out to be a problem situated between my keyboard and my chair. The first skill to learn is how to troubleshoot an issue until you can isolate exactly what behaviour is ‘buggy’. The ability to reduce and isolate problems is one of the best things you can learn as a web developer. It doesn’t matter which language you are working in, or what software is being buggy. Being able to isolate issues means you can fix them in your own code, work around them and hopefully report them to a third party software vendor.

Create a reduced test case

When you create a reduced test case, what you are doing is removing anything that isn’t relevant to the issue. This will help you figure out if what you have is indeed a bug – and also give you a really simple test case of the problem to share later.

Obvious things to remove would be any JavaScript that doesn’t trigger the issue, and surrounding page elements. It is also a worthwhile practice to remove any items in the example that don’t seem to relate to the bug. Often while doing this you will learn something about the problem at hand.

I could write a lot more on this part of the process – however I don’t need to as Lea Verou wrote an excellent and still relevant piece a few years ago for Smashing Magazine. Take a look at her article Help the community! Report Browser Bugs!

As an example, I was testing out the interaction of absolutely positioned elements and CSS Grid Layout. I started to see some odd behaviour in that sometimes absolutely positioned items seemed to be becoming narrower in Chrome, rather than stretching to the area width. By removing other elements from my example that were holding the column wider, I could see that while the first column behaved as I would expect, the second absolutely positioned element was shrinking to the width of the longest word. This meant it was shrinking to min-content width.

Test in Nightly versions of browsers

It may be you have a bug that has already been fixed, and you will be able to see the fix if you download and use the newer experimental release of that browser. I had a look at my shrinking issue in Firefox Nightlies and didn’t see the behaviour. I also checked Chrome Canary to see if this had changed in the latest build, but the problem was still apparent there.

Check the specification

In my example I have two browser implementations doing something different. So which browser has the bug? The spec is the place to find out.

I searched in the spec for information about absolutely positioned elements, and found the section about absolutely positioned items with a grid container as a containing block. This was the situation I had, as my grid container is set to position: relative making it the containing block for my positioned items. Looking at this section and the example it seemed that I should expect my positioned item to use the space available to it in the area, not shrink down to the minimum amount of space it could take based on the content.

If you can’t work out from the spec which browser is getting it wrong, that’s ok. Sometimes, especially with new specifications, it may be that the behaviour isn’t very well defined. In that case the browser implementors and the spec editors will need to work out which behaviour to run with, and make sure the spec makes that clear.

Looks like a bug

Your investigations may have identified something that looks buggy in one or more browsers, the next step is to go have a look at the bugs for that browser and see if the issue is already reported.

• Chrome
• Firefox
• Safari
• Edge

There is is also a search that helps you locate bugs from all browsers at once, useful if you are seeing some odd behaviour and don’t know which browser is displaying your example incorrectly.

By working through the issue you hopefully have figured out some good keywords to search on. The spec you are seeing the behaviour in is a good start, plus anything that describes the issue. For me I had:

• css grid
• min-content
• absolute positioning or ‘abspos’

I searched using these terms in the Chromium issue tracker and after reading a few issues found – Positioned items using min-content even when there are enough available space. Bingo! That’s what I’m seeing. So, in this case I don’t need to log a bug, instead I added a comment with a link to my test case as an additional example.

Logging a bug

If you have found something that looks like a bug, and can’t find mention of it, then log the bug with the browser or browsers in which you see the issue. Once again, I’ll not reproduce the great advice in Lea’s article, but be sure to spend a some time writing a descriptive title and short summary of the issue. The clear title of the bug logged against the issue I was experiencing enabled me to locate it in the tracker based on my keyword search.

Include your reduced test case in order that the implementors can reproduce it. Link to the section of the specification if you have identified where the correct implementation is documented, and mention if you believe you have seen the correct behaviour in another browser. Your report should be as short as possible while being clear as to the problem at hand.

Be nice.

It should go without saying that when reporting issues you should be polite. Browser engineers are regular developers like you or I. We don’t like it when our boss or client yells at us because something isn’t working, the same is true for people working on browsers. No-one wants bugs in any software. By working alongside the people who implement new things into our browsers we will find fewer things to cause us problems in the future.

Identifying and working through bugs is a brilliant way to level up your CSS skills. You don’t just help browser vendors and the rest of us – but you’ll get better at CSS for doing this too. If you think you have found something with the Grid implementations in particular and want another set of eyes on it post it over at my CSS Grid AMA. I’ll be happy to take a look.