Introduction (and Bugzilla News)
Posted by Maciej Stachowiak on Wednesday, June 29th, 2005 at 10:46 pmHi everyone, I’m one of the other people that Hyatt mentioned would be posting here. My name is Maciej Stachowiak and some of my of areas of specialty in WebKit-land include JavaScript, DOM, performance and security.
I don’t have anything interesting to report on my recent work just yet, but I wanted to tell you about some new documents on the WebKit site about dealing with bugs in bugzilla. You should check these out if you are filing bugs or working on fixes. (And if you are doing either of these things, then you are totally our hero. Users of Safari and other WebKit-based apps will cast flowers before your feet everywhere you go. But I digress.)
Safari/WebKit team member Vicki Murley posted this document on bug priorities, so you can set them right when filing or screening bugs. And fellow Safarian John Sullivan wrote up this guide to the life cycle of a bug. Joost de Valk (AlthA on #webkit) helped with both of these documents and can answer your questions about them.
If you would have been filing and/or fixing lots bugs and would like the ability to confirm or edit, just ask: Darin, Hyatt and I can all grant you the powers.
June 29th, 2005 at 10:57 pm
In my humble opinion, everyone should read thesse documents before they get canconfirm and editbugs rights in Bugzilla :).
June 30th, 2005 at 1:25 am
Hehe, we also need clear documentation on how to make webkit test cases
June 30th, 2005 at 4:02 am
This seems like volunteering? Let’s write one!
June 30th, 2005 at 6:43 pm
Hey Maciej, still hangout in #kitchenstadium?
July 1st, 2005 at 9:51 am
WebKit now gold standard for open source bug reporting
Big holler out to Maciej Stachowiak, a new contributor on the revamped Surfin’ Safari blog:
http://webkit.opendarwin.org/blog/?p=5
They’ve really set a high standard for active engagement in, and education about, the bug process:
http://webkit.o...
July 6th, 2005 at 3:06 pm
Oliver, does this page help?
http://webkit.opendarwin.org/quality/testwriting.html
July 9th, 2005 at 9:52 am
I saw this yesterday on Zeldman’s A list Apart: “If you’re using Safari 1.3 or 2.0, the subnavigation in our sidebar starts in the wrong place, and the diamond markers preceding each list item are superimposed over the crack between columns. Dave Hyatt, Apple’s Safari chief, fixed the bug the same day we reported it. Updated versions of Safari 1.3/2, free of said bug, will become available very soon.” Is there a method we can use to report DOM issues that are causing the behavior of our products to change from one Safari version and OS to another? And to get souch good response time? We’d like to play by the rules but are confused as to how bugs and issues are both reported and prioritized.
Thanks
Al Sparber
July 9th, 2005 at 10:15 am
And here is a test case: http://www.projectseven.com/csslab/testing/safari/alignbad.htm
On the first page (alignbad.htm), operate the menu. The first pass through all the levels, alignment of the sub-menus vis a vis the parent, is perfect. That is, it is offset both vertically and horizontally. The second pass through the levels, results in the sub-menus at the third level being misaligned relative to their parents. On page 2 (aligngood.htm) the alignment remains perfect. Embedded in that page are the CSS fixes, so just view source and look for the commented rules.
This anomaly did not occur when we developed and tested this product. Testing was done on Jaguar and early versions of Panther. Jaguar is still perfect, while Panther Safari has been updated somewhere along the line with a change that causes this problem. We have no idea what Tiger versions are doing.
Do you have a reason for this anomaly (all other browsers are fine and have been all along)?
Al Sparber
July 9th, 2005 at 2:21 pm
Hi Al,
One good way to report bugs of this sort is http://bugzilla.opendarwin.org . This way you can track progress on your issue and everyone can see the bug report and fix it. It sounds like you have steps to reproduce, so it should be easy to file a good bug report. Once you have that, you can encourage people to work on it. Blog comments are generally not a good way to report bugs. We don’t put them into any kind of tracking system so they can esaily get lost.