June 2005 - webkit-dev - lists.webkit.org

DOM L2 HTML self-hosted tests
by Curt Arnold 26 Jun '05

26 Jun '05

Apparently, self-hosted tests for L2 HTML were not previously generated, or if they had been the build had been broken for a while. I've worked a couple of days getting the build process working for them and will commit the changes to the W3C CVS likely tomorrow. run-webkit-tests had problems with two classes of tests, the HTMLAppletElement tests would stall. Likely dump render tree wasn't expecting to render something with a Java applet. To work around the problem, I didn't put those tests in the layout-tests directory. Safari passed them all when run manually. The second problem was a crash in HTMLDocument17, 19, 20 and 21 which was a regression from Safari 412 and logged as bug 3713. I patched by local copy with a hack to suppress the crash and allow the tests to complete. HTMLLabelElement01-expected.txt: text run at (2,2) width 30: "error" HTMLLabelElement01-expected.txt: text run at (2,2) width 145: "TypeError - Null value" Regression, logged as Bug 3714. HTMLLabelElement.form is null when it shouldn't be. HTMLObjectElement01-expected.txt: text run at (2,2) width 30: "error" HTMLObjectElement01-expected.txt: text run at (2,2) width 145: "TypeError - Null value" Related but not regression, logged as Bug 3715. HTMLObjectElement.form is null when it shouldn't be. HTMLBodyElement09-expected.txt: text run at (2,2) width 40: "failure" HTMLBodyElement10-expected.txt: text run at (2,2) width 40: "failure" HTMLDocument24-expected.txt: text run at (2,2) width 40: "failure" HTMLDocument25-expected.txt: text run at (2,2) width 40: "failure" hasFeature03-expected.txt: text run at (2,2) width 40: "failure" hasFeature04-expected.txt: text run at (2,2) width 40: "failure" Tests checking consistency of hasFeature("XHTML") and hasFeature("XML"). Also failed by Firefox, need to review the tests. HTMLCollection07-expected.txt: text run at (2,2) width 40: "failure" HTMLCollection08-expected.txt: text run at (2,2) width 40: "failure" HTMLTableElement.rows is in document order, HTMLRowElement.rowIndex by position. In the test document, document order and position are not the same, Safari misses something. Passed by Firefox, IE and Opera. HTMLDocument04-expected.txt: text run at (2,2) width 40: "failure" Failed consistently by Firefox and Safari in self-hosted, but passed in JSUnit. Looks like self-hosted rendering error. Will review. HTMLElement113-expected.txt: text run at (2,2) width 40: "failure" HTMLElement114-expected.txt: text run at (2,2) width 40: "failure" HTMLElement142-expected.txt: text run at (2,2) width 40: "failure" HTMLElement143-expected.txt: text run at (2,2) width 40: "failure" HTMLElement26-expected.txt: text run at (2,2) width 40: "failure" HTMLElement27-expected.txt: text run at (2,2) width 40: "failure" HTMLElement55-expected.txt: text run at (2,2) width 40: "failure" HTMLElement56-expected.txt: text run at (2,2) width 40: "failure" HTMLElement84-expected.txt: text run at (2,2) width 40: "failure" HTMLElement85-expected.txt: text run at (2,2) width 40: "failure" HTMLInputElement21-expected.txt: text run at (2,2) width 40: "failure" All look like legitimate Safari problems, all tests passed by Firefox and IE. HTMLIsIndexElement01-expected.txt: text run at (2,2) width 40: "failure" HTMLIsIndexElement02-expected.txt: text run at (2,2) width 40: "failure" HTMLIsIndexElement03-expected.txt: text run at (2,2) width 40: "failure" All passed by Firefox, IE fails all three. Opera first two. Needs more investigation. HTMLScriptElement01-expected.txt: text run at (2,2) width 40: "failure" HTMLScriptElement02-expected.txt: text run at (2,2) width 40: "failure" HTMLScriptElement03-expected.txt: text run at (2,2) width 40: "failure" HTMLScriptElement04-expected.txt: text run at (2,2) width 40: "failure" HTMLScriptElement05-expected.txt: text run at (2,2) width 40: "failure" HTMLScriptElement06-expected.txt: text run at (2,2) width 40: "failure" HTMLScriptElement07-expected.txt: text run at (2,2) width 40: "failure" All appear to be production problems with self-hosted tests. Firefox passes them in JSUnit, fails them self-hosted. Understandable since "self- hosting" injects new script elements into test documents which would likely disrupt finding the script element under test. HTMLSelectElement20-expected.txt: text run at (2,2) width 40: "failure" HTMLTableColElement04-expected.txt: text run at (2,2) width 40: "failure" HTMLTableColElement06-expected.txt: text run at (2,2) width 40: "failure" Likely legitimate Safari problems. Passed by Firefox and Opera. Failed by IE. HTMLTableElement39-expected.txt: text run at (2,2) width 40: "failure" Failed by Firefox, IE and Safari. Passed by Opera. Will need to review.

1 0

Code clean up and compiling on 10.3.9
by David Storey 26 Jun '05

26 Jun '05

Hi, First I'd like to quickly introduce myself. I'm David, from Newcastle, England, and have recently graduated from a MSc in Internet and Distributed Systems, at the University of Durham. I'd like like to get involved in WebKit development to gain some much needed experience, and help improve something I use frequently and that I'm interested in. As I've limited knowledge of C/Obj-C (i'm mainly a Java developer), I though one of the best places to start would be on the code clean up and documentation. Is there any timeframe when or if WebKit will compile on 10.3.9? I don't have access to Tiger and can't afford to buy it, so I can't make any changes until it compiles. I don't have access to the Tiger DVD to get the missing header files either. At one stage JavaScriptCore compiled on Panther (it fails again now), so I decided to have a go at cleaning up that part of the project. Unfortunately it took two days to clean up every class, and by that stage when I performed the regression test, there were a number (even though I didn't make any real changes). It seemed that it actually passed many more than the master copy though. I thought I would submit the changes anyway, but i followed the steps on the site to produce a patch file, but it only created a blank file. I'm not sure if that was something to do with the app not compiling, or if I did anything wrong. Most the changes were just white-space changes. While working on the code cleanup there were a number of areas that different programmers implemted differently which were not covered by the style guidelines. Maybe there should be some guidelines to cover these: 1. Should first level statements after the method name be indented 4 spaces too? mostly they are indented twice e.g. methodName(param) { statement; } instead of methodName(param) { statement; } 2. Case statements do not seem to be mentioned. some use {} and some don't, even in the same switch block. Should all case statments have or not have braces? if they should, should they be like : } case CSSSelector::List: { OR case CSSSelector::List: { statemnts; } case ... 3. Braces are not mandatory when the statements are only one line for 'if and 'for' etc. Sometimes no braces are used and sometimes not. Should there be a guideline to keep this consistent. Personally I prefer always using braces, as it is clearer, but not everyone may agree. 4. There should possibly be a guideline for how many spaces to indent when wrapping a line that is too long to fit on one line. 5. Often code goes on for pages without any line breaks at all. Possibly there should be a guideline on when to leave a line space between blocks of code, such as leaving a line before a return statement at the end of a method or between and if or for block. 6. Not really knowing C, i wasn't sure what the '#if apple changes' -- and other such if constructs that xCode highlights in red -- are for? I wasn't sure if these should be indented like a normal if statement? 7. There are no guidelines for casting. I personally prefere: var = (cast) methodName(param, otherParam); but often they were formatted without the space, such as : var = (cast)methodName(param, otherParam); I think that is it for the moment. sorry for going on, but after spending two days at code reformatting, I noticed a few things. Thanks for your time, hopefully in the future will be able to make some contribution to the project, Regards, David ------------------------------------------------------ David Storey University of Durham ------------------------------------------------------

3 2

(no subject)
by Hanspeter Schaub 25 Jun '05

25 Jun '05

With the latest builds, I've noticed that when viewing PDFs using the Safari built-in viewing capability (without the 3rd party plugin), I no longer seem to have the full set of options with the contextual menu? (using the right-click on PDF mode). There used to be a "view in Preview" option, among others. Are these removed on purpose? thanks, HP --------------------------------------------------------------- Hanspeter Schaub Phone: (540) 763-8370 Email: HanspeterSchaub(a)mac.com Web: http://homepage.mac.com/hanspeterschaub

3 2

DOM L2 Core and HTML tests
by Curt Arnold 22 Jun '05

22 Jun '05

Very few of the L2 Core tests are "HTML-compatible". Of the 11 that are one, createDocumentType04, causes Safari to crash (logged as http://bugzilla.opendarwin.org/show_bug.cgi?id=3653) and hc_nodenormalizedocumentfragment2 failed. hc_nodenormalizedocumentfragment2 adds an empty text node to a document fragment and then normalizes the document fragment expecting the elimination of the empty text node. Apparently, I never got around to making functional self-hosted versions of the L2 HTML tests and they are not present in the snapshots. The build script can produce them, but they are not currently functional. I'll try to debug them and see what I can do to make them available.

1 0

Javascript test failures
by Carsten Guenther 22 Jun '05

22 Jun '05

Hi, not sure if this is known or not or if I misinterpret the output but the run-mozilla-tests script currently complains about lots of regressions when running on a fresh build from ToT: ... 98 regressions found. 119 tests fixed. Carsten

2 1

Secure site problems since Webkit 312
by Matt Gough 22 Jun '05

22 Jun '05

Since Mac OS X 10.3.9 and later came out, I have often experienced problems with many secure sites which results in Safari displaying the following: *** Safari can’t open the page. Safari can’t open the page “https://www.abc.com” because the network connection was reset, which sometimes occurs when the server is busy. You might be able to open the page later. *** These will either occur when trying to log in, or will happen after a successful login when jumping to a different page on the same site. In fact it has become so commonplace nowadays that I switch to Firefox before bothering to visit such a site. Interestingly, I sometimes get an error being reported in Safari's Activity window "POSIX error: Connection reset by peer" on a sub page that I am trying to go to. If I then double-click that page in the Activity window it will come up OK. I really don't believe the servers are busy and I think there has been some kind of regression in Webkit 312 and later. I never had problems in 10.3.8 and earlier. Since these are secure sites (often banking sites) it is impossible to provide a test case. However, if you bank with HSBC in the uk (or maybe even in the US), you may be able to reproduce this yourselves. Matt Gough

2 1

WebCore compilation failure
by Kevin Ballard 22 Jun '05

22 Jun '05

At the time of this writing, WebCore fails to compile. This is caused by a recent change, which can be seen in revision 1.554 of WebCore.pbproj/project.pbxproj. The problem is that the $() construct was used instead of ${} in writing a shell script, which causes the script to fail. The fix is very simple. Open up the build settings of the WebCore target and fix the rule for .y files to use ${} instead of $(). Or simply apply the following patch: Index: WebCore.pbproj/project.pbxproj =================================================================== RCS file: /cvs/root/WebCore/WebCore.pbproj/project.pbxproj,v retrieving revision 1.554 diff -u -r1.554 project.pbxproj --- project.pbxproj 2005/06/22 00:23:09 1.554 +++ project.pbxproj 2005/06/22 01:45:01 @@ -2035,7 +2035,7 @@ "$(DERIVED_FILE_DIR)/$(INPUT_FILE_BASE).h", "$(DERIVED_FILE_DIR)/$(INPUT_FILE_BASE).cpp", ); - script = "bison -d -p cssyy khtml/css/parser.y -o \"$DERIVED_FILE_DIR/$(INPUT_FILE_BASE).cpp\"\ncat \"$DERIVED_FILE_DIR/ parser.cpp.h\" \"$DERIVED_FILE_DIR/$(INPUT_FILE_BASE).hpp\" > \"$DERIVED_FILE_DIR/$(INPUT_FILE_BASE).h\" 2> /dev/null || echo -n"; + script = "bison -d -p cssyy khtml/css/parser.y -o \"$DERIVED_FILE_DIR/${INPUT_FILE_BASE}.cpp\"\ncat \"$DERIVED_FILE_DIR/ parser.cpp.h\" \"$DERIVED_FILE_DIR/${INPUT_FILE_BASE}.hpp\" > \"$DERIVED_FILE_DIR/${INPUT_FILE_BASE}.h\" 2> /dev/null || echo -n"; }; 937C34ED0868E4B4006F4B22 = { fileRef = 934E43780414294A008635CE; Note that I had to edit this file by hand since I don't have Xcode 2.0 anymore, just 2.1, but it appears to work (my build hasn't finished yet, since I'm doing a clean build, but if the error was still there the build would have stopped minutes ago). -Kevin Ballard -- Kevin Ballard kevin(a)sb.org http://www.tildesoft.com http://kevin.sb.org

2 1

Adding CIA to the CVS repo
by Kevin Ballard 22 Jun '05

22 Jun '05

There's a nifty service for version control systems called CIA <http://cia.navi.cx/>. Basically, you simply throw their hook script onto your repo and your commit information starts getting logged on their site. That's decent for looking at activity, but what makes it so much better is you can then tell it to mirror the messages to your IRC channel on Freenode, which means anybody hanging out there gets notified whenever somebody commits something. I think it would be quite useful. The only problem with CIA is you get used to the messages, and occasionally it goes down so you don't get IRC notifications, and you feel lost. But of course, that would simply put you back in the state we are right now. Any thoughts? -- Kevin Ballard kevin(a)sb.org http://www.tildesoft.com http://kevin.sb.org

1 0

layout test failures
by Darin Adler 22 Jun '05

22 Jun '05

I'm seeing new failures on these layout tests (even after a clean build): fast/forms/element-by-name fast/js/exception-linenums fast/loader/loadInProgress These were working 24 hours ago. Others confirm they are seeing these failures, although not everyone sees all three. Lets not commit any other code changes to the tree until we resolve these regressions. Here's hoping it's just something wrong on my computer. -- Darin

5 4

Debugging mid-page relayout issues
by Mitz Pettel 22 Jun '05

22 Jun '05

I have encountered a bug that occurs on a certain page only sometimes and only when it's loaded via HTTP (i.e. not when opened as a webarchive). It looks like the bug occurs only when relayouting occurs when the HTML is not fully loaded (or perhaps when images are loaded after the page HTML has been loaded). I'm afraid I don't know much more than that about the exact conditions. Do you know of any techniques that will allow me to reproduce those conditions without relying on that specific page and on the server it's coming from? Thanks, -- Mitz Pettel

4 4