A shout out to all the developers out there… I need some advice on how to report software bugs for beta software.
I’m a huge fan of WebKit – the HTML rendering engine of Safari. I’ve been using the nightly builds for some time. Every now and then, WebKit crashes and, in the past, I’ve just relaunched. But the crashes are happening more often and, for a while I thought of going back to Firefox. Its just that Firefox renders so much more slowly than WebKit does and I can’t take that; sure FF3 is good. But you’d be amazed at how much faster WebKit is to Mozilla’s Gecko on my Mac. So instead of “quiting” and going back to Firefox, I want to contribute to the WebKit community and submit crash reports.
But I am no developer. I do work with them – and understand, on a conceptual level, what is helpful when reporting bugs. But, again, I’ve never generated a crash dump or even log file; I don’t know if I can say I know how to or even what the differences between the two are. But I know that I can, somehow, help the development team make WebKit into one of the best browsers for KDE and Aqua interfaces. I just need to know how to do this.
So I ask all you developers out there… how do I go about contributing to the WebKit community and offer real reports and submit bugs that are good enough to be accepted and reviewed? Any thoughts left in the comments would be greatly appreciated. Or, you can email me at this address: soitscometothis [at] soitscometothis.com
Hey there C.G.! Thanks for asking about bug reports. If you’re seeing a lot of crashes, then yes, a bug report would help. Here are some things to think about:
A) If you can find a consistent set of steps to get a crash (visiting a specific site, clicking a particular part of a site, etc) then that makes for the best kind of bug report. In fact, if you crash, you should try to do the same thing you just did to see if you can repeat it. If you can consistently get a particular crash, then you should include steps to reproduce the crash, including the specific URL, and that should be enough if the WebKit team can reproduce it too.
B) If you can’t reproduce it consistently (or even about 50% of the time) with the same set of steps, then those kinds of bugs are tougher. What I recommend is clicking on “Report” when the crash dialog comes up, but don’t report to Apple, instead, copy the crash trace from the window that comes up, and put it in a bug report. You should also include the URL or URLs of sites where this happens, if possible.
If you want extra credit, you can try old builds from the archives at . A good way to proceed is to start with a build several months old, to see if the crashing still occurs. Once you find a good build, start splitting the difference between that and the latest. For instance, if you find that r34000 is good, but r35000 is bad, then your next build to try is halfway in between, r34500 (or whatever is closest). If that one is bad, you split the difference again to 34000 and try 34250. If it is good, then you split the difference to r35000 and try r34750. Basically keep track of what are your known good and bad builds and split halfway in between. Proceeding this way, you should be able to narrow the range to between two specific nightlies, which will help the WebKit team a lot! This isn’t strictly necessary, but again, if you are really excited about helping the WebKit team this is a good thing to do after you file the initial bug report.
More info on reporting bugs to the WebKit project is here: and here .
I hope this helps.
Maciej,
Well, I did it. I joined Bugzilla and I submitted my first crash report. I was able to isolate specific actions that caused a crash and I reported it. Hopefully, I submitted a quality report which can be reviewed and fixed.
Now I get a sense of why people contribute to FOSS… I feel pretty good.
Thanks for the advice!!
Comments on this entry are closed.