December 2005 - webkit-dev - lists.webkit.org

Bug life cycle
by Joost de Valk 08 Jan '06

08 Jan '06

Hi all, today, while talking on #webkit, i got two questions which both should be answered in the bug life cycle document on the WebKit page as well, in my humble opinion. To be able to do that, i'd like to get some consensus on them. The first one, brought up by Alexey Proskuryakov (ap), is this: when a bug can't be reproduced anymore but has been confirmed at one point in time, what to do with it? My answer for this would be to close it as "WORKSFORME" and not as "FIXED", since you don't know what fixed it. Ideally we would create a new resolution for this, something like "FIXED WITHOUT SOLUTION" or something like that, have you people perhaps got any thoughts on this? The second one: a bug that is fixed goes to verified, and to closed when it's in an Apple release of WebKit. However, as Mitz Pettel pointed out, we have bugs as well which are regressions from previous versions, these will, when fixed, never get into a release. I propose that we close them anyhow, since they should have a keyword which indicates that it was a regression. Everyone agree with the second? Any thoughts on the first? I'd be glad to hear from you all! Kind regards, Joost -- Joost de Valk #: AlthA on #webkit @ irc.freenode.net @: webkit(a)joostdevalk.nl W: http://www.joostdevalk.nl "The only people who find what they are looking for in life are the fault finders." - Foster's Law

4 4

WebKit Welcome Page
by Timothy Hatcher 08 Jan '06

08 Jan '06

One item we have been talking about adding to the nightly builds is a page that loads on launch. This page would thank you for testing WebKit and give you links for certain tasks to help us. This is my concept for the page. Feedback and suggestions to improve this are welcomed. http://colloquy.info/webkit-page.png — Timothy Hatcher

6 5

AJAX Support
by Andrew Eberhard 04 Jan '06

04 Jan '06

Hello, I'm almost certain this topic has been covered before so I'll try to keep my questions brief and will gladly read any resources already devoted to thereto (I just signed up for this mailing list). Basically, I'm an AJAX developer for a large civil engineering company. As User Interface Manager for the corporate intranet, I've regularly tried to enrich the capabilities of our intranet without increasing bandwidth needs and/or client requirements. To date, my efforts have focused primarily on IE (the corporate browser standard), but I am being asked (and honestly want) to support other browsers including FireFox and Safari. It seems to me that there are a couple of things that are missing from Safari. If anyone could speak to either of these (potentially incorrect) observations, please do. 1. Although Safari implements most of the XML Extras in FireFox, as far as I can tell it lacks a critical piece of the AJAX framework: the ability to apply an XSLT transform to an XML document received asynchronously from a server into HTML. I believe Safari supports .innerHTML on most tags (could be wrong), so the transform process seems to be the only missing piece of the puzzle in this regard. 2. There seems to be a number of bugs with contenteditable regions in Safari. Strictly speaking these are not part of the AJAX "platform", but having reliable editable regions would be very useful for online applications. The Writely.com website has some rather vague descriptions of the problems. I feel compelled to say that I am an ardinent Mac user at home. ;-) Thank you! Andrew Eberhard

5 11

I want to help
by Joseph Powers 03 Jan '06

03 Jan '06

Under Projects => JavaScript, you have a request for someone to "Eliminate Smart Pointer Wrappers". If someone would be willing to point me in the right direction, then I'm willing to help. The sample of KJS::ObjectImp looks like it has already been done. The other classes like BooleanObject and ArrayObject still look like they haven't be done (or I'm reading the code wrong). Joe Powers PS: I just signed up to the mailing list.

2 1

run-webkit-tests and color profiles
by Eric Seidel 30 Dec '05

30 Dec '05

Greetings, I wanted to inform you all that I landed a change to DumpRenderTree (run-webkit-tests) this evening that affect any of you who run the layout tests with the --pixel option. This change allows us to render color-matched content in a consistent manner across all machines. http://bugzilla.opendarwin.org/show_bug.cgi?id=6155 If you use the --pixel option, you will notice your system colors changing for a while, as well as this see this warning: WARNING: Temporarily changing your system color profile from "My Custom Profile" to "Generic RGB Profile". This allows the WebKit pixel-based regression tests to have consistent color values across all machines. The colors on your screen will change for the duration of the testing. DumpRenderTree is now smart enough to change your system color profile while it runs, and restore it when it quits. If, in the very unlikely event that DumpRenderTree were to crash, it could leave your system with "Generic RGB Profile" as the system color profile. In that unlikely event, you can restore your custom color profile inside System Preferences : Monitors : Colors. Hopefully we'll find an even slicker solution soon. Happy holidays, -eric

1 0

Crash on www.meridiana.it (reproducible)
by Fabio Invernizzi 29 Dec '05

29 Dec '05

Hi all, go to http://www.meridiana.it (italian flight company) On the left sidebar there are two textfields: the first, named "data partenza" should contain the actual date, the second, named "data rientro", should contain the string "[solo andata]". Click on the second textfield and enter whatever you want (i.e. a number): bum, on my OS X 10.4, standard Safari 416.13 I can reproduce this. Regards, Fabio

2 1

Thoughts on WebKit/WebCore refactoring
by Maciej Stachowiak 29 Dec '05

29 Dec '05

I'm doing work now to refactor WebKit and move more of the code down to WebCore to live in the portable layer. Here's some thoughts I had on the direction for this: * KHTMLPart gets renamed to DocumentController. It no longer makes any attempt to match the original KHTMLPart API. This will be platform-independent controller logic. If WebCore ever runs on KDE again, then a new KHTMLPart would have to be written to provide KDE- specific API glue on top of DocumentController. * Eventually every document may have a DocumentController, even viewless documents created through such means as XMLHttpRequest or the DOM createDocument call. * For a top-level document attached to a view, there will be a PageController class. This is for things that make sense only at the top level in a context where you have a view. * DocumentController will bridge to WebFrame. Either using a two-way bridge as currently, or possibly two classes, WebFrameBridge and DocumentControllerBridge. Or bridging may be so minimal that WebFrameBridge is not needed and instead WebFrame connects to generic callbacks on the DocumentControllerBridge. Alternately, WebFrame might connect directly to the C++ interface on DocumentController. * PageController will bridge to WebView. Otherwise much as above. Anyway, this is the general idea. I think things will gradually moving in this direction, and the loading and frame traversal logic will increasingly live in WebCore. Any comments on the names or other aspects of this design? Regards, Maciej

4 5

KDE JS tests where Firefox disagrees
by Maciej Stachowiak 29 Dec '05

29 Dec '05

I recently incorporated the KDE JS test suite into the WebKit layout tests. As part of the KJS/JSC merger work, we are trying to make JavaScriptCore pass all these. To double-check the tests, I tried them in Firefox and took a look at the spec where there was disagreement. Here are the discrepencies I found: parse.js --------- Firefox fails to parse this. So does Mac IE. What is the evidence that it should parse? math.js ------------ FAIL String()+Math.LOG10E should be 0.43429448190325176. Was 0.4342944819032518 (possibly slight difference in numeric output? can't tell if the spec has an opinion on this) inbuilt_function_tostring.js --------------------------------- FAIL StripSpaces(kjsprint.toString()) should be functionkjsprint() {[nativecode]}. Threw exception ReferenceError: kjsprint is not defined (perhaps we should skip testing this, in Safari it is only defined in debug builds) FAIL StripSpaces(Date.prototype.toGMTString.toString()) should be functiontoGMTString(){[nativecode]}. Was functiontoUTCString() {[nativecode]} (bug in moz? don't think we should change this) function_length.js -------------------- FAIL Array.prototype.slice.length should be 2. Was 0 FAIL Array.prototype.splice.length should be 2. Was 1 FAIL Array.prototype.concat.length should be 1. Was 0 FAIL String.prototype.concat.length should be 1. Was 0 FAIL String.prototype.slice.length should be 2. Was 0 FAIL Number.prototype.toString.length should be 1. Was 0 (Firefox is wrong per the spec in all cases - we should probably file bugs in moz bugzilla) StringObject.js ----------------- FAIL 'abc'[-1] should be undefined. Was 3 (Firefox appears to always give the length of a string as property -1, MacIE does not have this quirk, but it also does not allow numeric indexing of string objects, nor does the spec call for numeric indexing of string objects. If we copy the quirk, we may as well copy it all the way.) exception_propagation.js ----------------------------- fails to parse (MacIE parses it and gets up to checkOperator(">>>","OpURShift");, then bombs; needs further investigation) evil-n.js --------- parses successfully, desipte the -n.js ending FAIL (new Error()).message should be undefined. Was (I think this test is just plain wrong and should be removed) encode_decode_uri.js ------------------------- FAIL checkWithFunctions(encodeURI,decodeURI) should be true. Was false FAIL checkWithFunctions(encodeURIComponent,decodeURIComponent) should be true. Was false (is this test case actually correct? can't tell - it also fails in Mac IE) constructor_length.js ------------------------ FAIL RegExp.length should be 2. Was 1 FAIL Error.length should be 1. Was 3 FAIL EvalError.length should be 1. Was 3 FAIL RangeError.length should be 1. Was 3 FAIL ReferenceError.length should be 1. Was 3 FAIL SyntaxError.length should be 1. Was 3 FAIL TypeError.length should be 1. Was 3 FAIL URIError.length should be 1. Was 3 (in all cases firefox is contrary to the ECMA spec, I think we should maintain this behavior and file bugs against them) RegExp.js ----------- FAIL RegExp.$1 should be . Was 100 FAIL RegExp.$3 should be . Was 200 FAIL RegExp.$5 should be . Was 150 FAIL RegExp.$7 should be . Was 15 (It's weird for failing matches not to overwrite the $ values, but since these are a Firefox extension it seems like a bad idea to be inconsistent on this. JSC matches the firefox behavior. I recommend leaving it that way.) Number.js ------------ FAIL toFixedOrException(2,-1).indexOf('Range') >= 0 should be true. Was false FAIL toFixedOrException(2,21).indexOf('Range') >= 0 should be true. Was false FAIL Number(123.456).toExponential(17) should be 1.23456000000000000e +2. Was 1.23456000000000003e+2 FAIL Number(123.456).toExponential(18) should be 1.234560000000000000e +2. Was 1.234560000000000031e+2 FAIL Number(123.456).toExponential(19) should be 1.2345600000000000000e+2. Was 1.2345600000000000307e+2 FAIL Number(123.456).toExponential(20) should be 1.23456000000000000000e+2. Was 1.23456000000000003070e+2 FAIL try { Number(123.456).toExponential(21) } catch (e) { String (e).indexOf('Range') >= 0; } should be true. Was 1.234560000000000030695e+2 FAIL Number(.000123456).toExponential(16) should be 1.2345600000000000e-4. Was 1.2345600000000001e-4 FAIL Number(.000123456).toExponential(17) should be 1.23456000000000000e-4. Was 1.23456000000000005e-4 FAIL Number(.000123456).toExponential(18) should be 1.234560000000000000e-4. Was 1.234560000000000052e-4 FAIL Number(.000123456).toExponential(19) should be 1.2345600000000000000e-4. Was 1.2345600000000000519e-4 FAIL Number(.000123456).toExponential(20) should be 1.23456000000000000000e-4. Was 1.23456000000000005188e-4 FAIL try { Number(.000123456).toExponential(21) } catch (e) { String (e).indexOf('Range') >= 0; } should be true. Was 1.234560000000000051876e-4 FAIL Number(123.4567890123456789012).toExponential(16) should be 1.2345678901234570e+2. Was 1.2345678901234568e+2 FAIL Number(123.4567890123456789012).toExponential(17) should be 1.23456789012345700e+2. Was 1.23456789012345681e+2 FAIL Number(123.4567890123456789012).toExponential(18) should be 1.234567890123457100e+2. Was 1.234567890123456806e+2 FAIL Number(123.4567890123456789012).toExponential(19) should be 1.2345678901234570000e+2. Was 1.2345678901234568059e+2 FAIL Number(123.4567890123456789012).toExponential(20) should be 1.23456789012345700000e+2. Was 1.23456789012345680590e+2 FAIL try { Number(123.4567890123456789012).toExponential(21) } catch (e) { String(e).indexOf('Range') >= 0; } should be true. Was 1.234567890123456805895e+2 FAIL try { Number(1).toPrecision(22); } catch (e) { String(e).indexOf ('Range') >= 0; } should be true. Was 1.000000000000000000000 FAIL Number(0.0001234567890123456789012345).toPrecision(17) should be 0.00012345678901234568. Was 0.00012345678901234567 FAIL Number(0.0001234567890123456789012345).toPrecision(18) should be 0.000123456789012345680. Was 0.000123456789012345671 FAIL Number(0.0001234567890123456789012345).toPrecision(19) should be 0.0001234567890123456800. Was 0.0001234567890123456713 FAIL Number(0.0001234567890123456789012345).toPrecision(20) should be 0.00012345678901234567000. Was 0.00012345678901234567130 FAIL Number(0.0001234567890123456789012345).toPrecision(21) should be 0.000123456789012345680000. Was 0.000123456789012345671298 FAIL Number(12345.67890123456789012345).toPrecision(17) should be 12345.678901234568. Was 12345.678901234567 FAIL Number(12345.67890123456789012345).toPrecision(18) should be 12345.6789012345660. Was 12345.6789012345671 FAIL Number(12345.67890123456789012345).toPrecision(19) should be 12345.67890123456800. Was 12345.67890123456709 FAIL Number(12345.67890123456789012345).toPrecision(20) should be 12345.678901234565000. Was 12345.678901234567093 FAIL Number(12345.67890123456789012345).toPrecision(21) should be 12345.6789012345670000. Was 12345.6789012345670926 (Firefox does not appear to enforce limitations on toFixed or toExponential, it also gets somewhat different numeric results in some cases. I didn't examine the spec in enough detail to see if any of the ffx results are bugs or any of ours are.)

2 1

Low hanging fruit! AKA: The case of the forgotten bug
by Joost de Valk 27 Dec '05

27 Dec '05

Hi all, as requested by Eric Seidel, i figured out how to track all bugs in bugzilla which currently have a review- or a patch but no review status. There's currently 38 of them. This is "low-hanging-fruit" so, if you want to start hacking on webkit, or just looking to get a few bugs fixed fast, check these out! the tiny url is: http://tinyurl.com/78y9a the long one is: http://bugzilla.opendarwin.org/buglist.cgi? query_format=advanced&product=WebKit&bug_status=UNCONFIRMED&bug_status=N EW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=attachments.is patch&type0-0-0=equals&value0-0-0=1&field0-0-1=flagtypes.name&type0-0-1= substring&value0-0-1=review- &field0-1-0=attachments.isobsolete&type0-1-0=notequals&value0-1-0=1&fiel d0-2-0=flagtypes.name&type0-2-0=notsubstring&value0-2-0=review% 2B&field0-2-1=noop&type0-2-1=noop&value0-2-1=review- &field0-2-2=flagtypes.name&type0-2-2=notsubstring&value0-2-2=review%3F for those of you wanting to know: this is achieved by, in the advanced search tab of bugzilla's query.cgi, selecting Webkit as a product, selecting the first 4 statuses and then in the lower part of the page, under Advanced Searching using boolean charts setting: Flag is equal to review- OR Attachment is patch is equal to 1 (0 would give all bugs without patches) AND Attachment is obsolete is not equal to 1 AND Flag is not equal to review+ OR Flag is not equal to review? Kind regards and good lucking getting these bugs fixed! Joost PS if anyone thinks i missed bugs with this query, please point me to one of them so i can fix the query, quering bugzilla like this is hard to get right :) -- Joost de Valk #: AlthA on #webkit @ irc.freenode.net @: webkit(a)joostdevalk.nl W: http://www.joostdevalk.nl "The only people who find what they are looking for in life are the fault finders." - Foster's Law

1 0

Getting the code page
by oplus 27 Dec '05

27 Dec '05

Is this page still valid? There was some talk about moving to subversion around 12/5, but no announcement that the move was done. http://webkit.opendarwin.org/building/checkout.html

3 2