January 2008 - webkit-dev - lists.webkit.org

Re: [webkit-changes] [24723] trunk/WebCore
by Darin Adler 11 Sep '08

11 Sep '08

I'm not happy with the code organization here. XMLTokenizer now has tons of ifdefs and two separate implementations. It's fine to have a QXmlStream implementation, but the two implementations should be in separate files, side by side, as we do in the platform layer. Or the XML parser should be abstracted out so we have a single XMLTokenizer built on a single parser abstraction. I think this is also the type of patch that should be reviewed by at least one person other than the folks concentrating on the Qt port. With the huge number of check-ins today, I'm sure there are other interesting things like this that I missed. -- Darin

8 17

Crash on arm
by Naiem Shaik 12 Jun '08

12 Jun '08

Hi All, I am working on linux box. I have cross compiled the Webkit for ARM and ran the Gtklauncher on the ARM board. When I open www.yahoo.com I get a crash with following backtrace: #0 0x403fb1c4 in Balloc () from /usr/local/lib/libWebKitGtk.so.1 #1 0x403fb4d0 in mult () from /usr/local/lib/libWebKitGtk.so.1 #2 0x403fb684 in pow5mult () from /usr/local/lib/libWebKitGtk.so.1 #3 0x403fddf8 in kjs_dtoa () from /usr/local/lib/libWebKitGtk.so.1 #4 0x404766c4 in KJS::UString::from () from /usr/local/lib/libWebKitGtk.so.1 #5 0x4041a938 in KJS::JSImmediate::toString () from /usr/local/lib/libWebKitGtk.so.1 #6 0x4045d21c in KJS::add () from /usr/local/lib/libWebKitGtk.so.1 #7 0x40429528 in KJS::AddNode::evaluate () from /usr/local/lib/libWebKitGtk.so.1 #8 0x40429528 in KJS::AddNode::evaluate () from /usr/local/lib/libWebKitGtk.so.1 #9 0x40429528 in KJS::AddNode::evaluate () from /usr/local/lib/libWebKitGtk.so.1 #10 0x4042bb94 in KJS::ArgumentListNode::evaluateList () from /usr/local/lib/libWebKitGtk.so.1 #11 0x4042c070 in KJS::FunctionCallDotNode::evaluate () from /usr/local/lib/libWebKitGtk.so.1 #12 0x404261a0 in KJS::ExprStatementNode::execute () from /usr/local/lib/libWebKitGtk.so.1 #13 0x404235e0 in KJS::SourceElementsNode::execute () from /usr/local/lib/libWebKitGtk.so.1 I would have raised a bug for this but, on desktop it works fine, can someone please guide me as to what could be going wrong. Best Regards, ~Naiem

9 16

Changes to keyboard event handling
by Alexey Proskuryakov 27 Mar '08

27 Mar '08

I've just landed a patch that brings our keyboard event processing model much closer to that of Internet Explorer: <http://trac.webkit.org/projects/webkit/changeset/28620>. This fixes some bugs that couldn't be sanely fixed otherwise, and will hopefully make lives of Web developers easier, as they won't have to worry about that many different models. The patch comes with a long ChangeLog, and I'm also going to write a more approachable overview soon. Most changes have to do with what events are dispatched (e.g., keypress is no longer dispatched for Tab or arrow keys), and when default processing takes place (e.g., pressing Space on a button now fires onclick when releasing the key). I have tried to apply as many of the changes as I could to non-Apple ports, but I'm pretty sure that it wasn't enough. I'd be happy to help with figuring out what needs to be done in other ports, please do catch me on IRC, e-mail me, etc! - WBR, Alexey Proskuryakov.

3 2

New autotools build system landed in r28997
by Alp Toker 06 Mar '08

06 Mar '08

The new autotools build system has landed in commit r28997: http://bugs.webkit.org/show_bug.cgi?id=16390 Q: Is this specific to the GTK+ port? Right now the build system only supports GTK+, but it's been written to support multiple ports. Developers of two younger ports (ArOS, EFL) have already expressed an interest in sharing it. Q: Will this let me build a standalone JavaScriptCore library? Not yet, but it's a good basis for a standalone portable JavaScriptCore build system. This could be useful for scripting headless applications or building a test/benchmark driver. Q: I'm a Qt developer. Can I remove GTK+ from the qmake build files now? Hold up! We'll be maintaining the two systems in parallel for at least a week. I'll post a follow-up to list when the transition is complete. Q: I'm a WebKit developer. Should I try to keep this build system up to date when I add/remove files from the project? It would be helpful, but until the transition is complete (ie. the build bot starts using autotools) there's no pressure on anyone outside of the GTK+ port to maintain these files. Q: Does this mean I don't need Qt any more to build the GTK+ port? Yes. Offers of beer, gifts etc. should be directed at Jan Alonzo, and also Kimmo Kinnunen upon whose previous work this is loosely based.

2 2

get the bits of the complete page
by zaheer ahmad 18 Feb '08

18 Feb '08

hi, iam working on the gtk port of webkit and have a need to get the bitmap of the entire page without actually rendering it. Is there an easy way to get in the current implementation. one of the ways i thought was to create a cairo surface over a memory buffer (instead of the drawing window in webkit_page_expose_event) and pass it to the scrollview::paint with a complete rectangle. Not sure if this is the right track to solve this issue (also this could be performance/memory intensive) Any inputs would be greatly helpful. thanks, Zaheer

2 5

Trunk policy regarding new features and stabilization
by Eric Seidel 07 Feb '08

07 Feb '08

I'd like to get some clarification from other members of the WebKit project, regarding the policy regarding having features on/off on trunk. Specifically Apple folks, since they are the largest single vendor actively contributing to the WebKit Open Source Project. I'm interested in discussing the general policy towards new features on trunk and "stabilization" of trunk during release times for various vendors. This was prompted by my recent discovery that SVG_FOREIGN_OBJECT feature had been turned off. I assume for "stabilization" concerns. I've filed a bug: http://bugs.webkit.org/show_bug.cgi?id=16991 about that specific case. * Is trunk the advised location for all feature development? At what point should a feature be moved off onto it's own branch? * Is the current policy that there will be times of "stabilization" for the trunk, to match with a certain vendor or set of vendors release cycles? * If a vendor (or group of contributers) wishes to ship from trunk, is there a procedure by which they can "close" trunk to new feature development? My personal preferences would be: * Trunk is the location for all feature development. Large features which would disturb other development (introduce more than N p1 bugs, break the build, break patches repeatedly, etc.) * Currently there is no policy to enact a time of "stabilization" for trunk, however I think such could make sense if there was a way for enough contributers to agree. Stabilization periods should last no more than a month or two, during which time, all feature work should continue on a feature branch (similar to last summer, except *not nearly so long*). * I know of no such procedure, but I can see rational for creating one. Without one, my default would be to leave trunk always "open", unless policies are defined allow for its closure (like perf regressions?). Looking forward to your comments. -eric

2 2

Removing ICU dependancy from WebKit?
by Rachel Bassett 06 Feb '08

06 Feb '08

Dear all, I'm currently trying to cross compile WebKit (Linux PC -> MIPS) using the DirectFB, cairo, pango etc, GTK+, WebKit combination. I've successfully built the stack up to GTK+ with the GTK+ demo app running ok. However when I try to build up WebKit, it needs ICU. But the ICU component is not cross compilable (according to their forum, although some other blogs imply they have succeeded but don't say how). I could struggle with that route however I read on the wiki page http://trac.webkit.org/projects/webkit/wiki/Mobile, that the dependency on ICU could be removed from WebKit. Any hints or tips on this, gratefully received. Thanks Rachel ___________________________________________________________ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/

4 4

How many times Webkit is included into Safari ?
by Vincent MARIANI 31 Jan '08

31 Jan '08

Hello, I admire your work on webkit, numerous rendering bugs of Safari has been fixed on Webkit and I would like to know exactly how many times Safari is upgraded each year with the lastest version of Webkit. Indeed, I would like to understand deeply the impact between your job, the official webkit framework and Safari wich becomes each day a better browser than the other ones (in my mind). Thanks a lot for your job, Vive Webkit, Vincent MARIANI – Responsable R&D --------------------------------------------- Smart Agence – Les compagnons du Web 3, rue Geoffroy-Marie 75009 Paris tél. : 01 75 43 21 00 fax : 01 48 24 38 47 http://www.smartagence.com

1 0

[webkit-dev] Fwd: [whatwg] postMessage support now in Firefox trunk, implementation issues, feedback, tests
by Maciej Stachowiak 31 Jan '08

31 Jan '08

Jeff Walden mentioned on IRC that some of the tests mentioned below fail in WebKit TOT and seem to show cross-domain postMessage not working (I suspect it's failing security checks for some unrelated reason). Can someone (ideally someone who understands postMessage) please try these? I'm afraid the steps are a little complicated. I'm also curious if the PAC file approach would be a viable way to do cross-domain security testing more generally (it is able to test different subdomains and ports unlike our current approach). Begin forwarded message: > From: Jeff Walden <jwalden+whatwg(a)MIT.EDU> > Date: January 29, 2008 10:36:51 PM PST > To: whatwg(a)whatwg.org > Subject: [whatwg] postMessage support now in Firefox trunk, > implementation issues, feedback, tests > Reply-To: jwalden+whatwg(a)MIT.EDU > > https://bugzilla.mozilla.org/show_bug.cgi?id=postMessage > > I just landed HTML5 postMessage support in Firefox, so it should be > in Firefox 3! Thanks to WebKit people for pushing on this, because > I didn't think this had a chance of making 3, to be utterly honest, > having tried once before several months ago. To be honest, I'm > still in a state of shock this got taken. :-) > > > First: > > I strongly encourage all implementers of postMessage to compare how > they do against the set of tests (for both postMessage and > MessageEvent functionality) that I wrote during implementation of > postMessage. I made special efforts not to do any Mozilla-specific > testing without a user-agent guard, and I don't believe there are > any unguarded Mozilla-specific tests any more -- and to an extent > nothing not specified by HTML5 or otherwise commonly implemented, > more or less. There's significant bustage against the tests in the > user agents I tested even on basic functionality, to the extent that > the API's not usable for what it was intended due to incorrect > errors being thrown on access and such. (I've guarded against these > problems in the tests with try/catches and "sentinel" timeout checks > when there's no other way to communicate a failure). The tests are > available here: > > http://web.mit.edu/jwalden/www/whatwg/postMessage.zip > > To run the tests, extract them somewhere on your hard drive and > start an HTTP server on port 8888 serving the postMessage/ folder as > its root folder. Make sure that your server will serve .xhtml files > with the XHTML MIME-type -- a couple tests use it because I was too > lazy to use external files for scripts and wanted to include special > characters literally (or wanted to test specific Unicode-related > handling). Next, set up proxy autoconfig in your UA to point to <http://localhost:8888/proxy.js > >. Now navigate to: > > http://localhost:8888/tests/dom/tests/mochitest/whatwg/ > >> From there click the "Run tests" link to see how you do. For >> individual test results, see the individual test links. Be very >> careful when you run these -- the uri-checking hard-codes URIs >> instead of using something like location.href in the interest of >> robustness against colluding failures, so running with, say, a >> stray hash or question mark at the end of a page URL will usually >> cause that test to fail. > > I spent a lot of time on these tests, and I'm not aware of any bugs > in them, but I'd very much appreciate people reading through them, > running them, and checking for any errors I might have made, say, in > not marking a test as Moz-specific or such (subject to the points > noted below). > > > Second: > > The spec's incomplete or vague on a few points right now. The > points I know where I forged new ground or think clarifications/ > explicit notes may be in order are: > > * event.domain/uri values in a rewritten about:blank document > The spec seems to somewhat indicate that we should be using > about:blank and "" as uri/domain right now, but that's fairly > useless in terms of allowing postMessage in dynamically-created > pages. This probably wants to change to reflect the document's > origin/principal, and assuming things go the way most browsers have > implemented it, this means those values are the same as for the > opener of about:blank. This is tested in > test_postMessage_special.xhtml. Note that there are two different > tests of this behavior which change the document in slightly > different ways, and Mozilla expects them to have the same results > right now. > > * event.domain/uri values in data: URLs > Mozilla currently gives data: URLs the principal of the opener/ > parent, so we use that URI for computing uri/domain of messages from > data: URLs. The two tests for this are UA-guarded for now as > behaviors differ across browsers on this, but in the long run > everyone should come to an agreement on this. > > * event.domain with non-standard ports > We have it so domain doesn't include the port number, ever. The > spec says this, but it's not absolutely explicit. > > * event.domain/uri values for IDN URLs > We use the Unicode-ized values of these, not the Punycode versions. > (Actually, that's a lie -- what we use depends on whether the > relevant TLD is whitelisted for non-punycode display or not, which > is clearly the wrong behavior; at the moment I doubt this will be > fixed for Firefox 3, sadly.) I think this is what authors would > most likely expect, if not now then when IDN is truly widespread > (when we'd be stuck with punycode if we were to choose it now), but > the spec doesn't say anything about IDN yet. > > * event.domain/uri when calling through another same-origin page > Page A and B are same-origin; A calls a method in B, which calls > postMessage. The dispatched event has uri/domain of B, not of A. > The spec's reasonably clear on this, but best to note it explicitly > here. > > * event.domain for non-hierarchical URLs > I don't test this because I'm aware of no common protocol that would > be cross-browser, but .domain would be the empty string, not null, > in this case. If we ever changed the behavior of data: URLs, I > suspect we'd hit the logic to return an empty string. > > * event.domain when document.domain has been changed > The value of event.domain is the original domain for the page, not > the value to which document.domain may have been set. > > * handling a postMessage-dispatched MessageEvent by throwing > Any exceptions thrown by exception handlers when postMessage is > called on a window are ignored; they are not propagated up to an > exception handlers. In particular, this happens regardless of the > origin of the window whose script threw an exception, even if it is > identical to that of the window that called postMessage. It doesn't > seem like a good design to me to have to check for a pending > exception and only allow it if the target had the same origin; best > to avoid the problem entirely and just unconditionally prevent any > exceptions from propagating rather than introduce the possibility of > error in determining when an exception may be safely propagated. > (Also consider that if you were to propagate in the cross-origin > case you'd have to make sure the thrower hadn't set any properties > on the exception, or at least that said properties would not be > accessible to the postMessage caller.) > > > (One last note that's relevant yet not relevant: if you're wondering > what Mozilla does for "chrome" content that runs with elevated > privileges, we forcibly make the source of the dispatched events > null. In this way chrome can postMessage chrome or content, but no > method is provided for response or even for referring to the > sender. To respond, the target window must be able to get a > reference to the sending window some other way.) > > > > That covers everything I ran into while implementing this; comments, > suggestions for other tests, complaints about test bugs, suggestions > for error message clarifications, yadda yadda are all greatly > appreciated! > > Jeff Walden > > P.S. -- Mailman, you suck for not using using the various vendor- > specific and standard forms of pre-wrap on the ASCII emails you > display, and I refuse to acquiesce to your demands for line breaks > in what I type. >

2 1

Acid3 status
by Eric Seidel 30 Jan '08

30 Jan '08

Hixie is nearly done with his Acid3 test. He's said he has space for 2 more tests, but is otherwise "ready". Acid3 has certainly found some bugs in WebKit. WebKit has also found bugs in Acid3 (I'm sure we'll find more). Here is a list of all of the failures we currently have, and their associated Bugzilla bugs: Failed 35 tests. Test 0: expected: pre-wrap, got: normal - found unexpected computed style 4812 - :last-child bug <http://bugs.webkit.org/show_bug.cgi?id=4812> Test 1: method [object NodeIterator].nextNode() didn't forward exception 4714 - NodeIterator forwarding exceptions<http://bugs.webkit.org/show_bug.cgi?id=4714> Test 2: expected: [object HTMLElement], got: null - expectation 13 failed Test 4: expected: null, got: [object HTMLIFrameElement] - expectation 21 failed Test 6: expected: [object HTMLTitleElement], got: null - failed to handle regrafting correctly 3492 - TreeWalker brokenness <http://bugs.webkit.org/show_bug.cgi?id=3492> Test 8: Null value 16766 - Range doesn't update on tree modifications<http://bugs.webkit.org/show_bug.cgi?id=16766> Test 11: when trying to surround two halves of comment: wrong exception raised; code = 3 16749 - Range.surroundContents throws wrong exception<http://bugs.webkit.org/show_bug.cgi?id=16749> Test 13: collapsed is wrong after deletion 16766 - Range doesn't update on tree modifications<http://bugs.webkit.org/show_bug.cgi?id=16766> Test 18: expected: 10, got: 8 - DOCTYPE nodeType wrong 12751 - DocType nodes aren't part of the document<http://bugs.webkit.org/show_bug.cgi?id=12751> Test 23: no exception for createElementNS('null', ':div') 16833 - createElementNS doesn't throw enough exceptions<http://bugs.webkit.org/show_bug.cgi?id=16833> Test 25: failed to raise exception 16693 - createDocumentType does not throw enough exceptions<http://bugs.webkit.org/show_bug.cgi?id=16693> Test 26: e1 - parent element doesn't exist after looping Test 27: e1 - parent element doesn't exist after waiting 17076 - Document tree does not survive long enough<http://bugs.webkit.org/show_bug.cgi?id=17076> Test 35: expected: 0, got: 1 - :first-child still applies to element that was previously a first child Test 36: expected: 1, got: 0 - last child did not match :last-child Test 37: expected: 1, got: 0 - :only-child did not match only child 5468 - broken :first-child, :last-child, :only-child selectors<http://bugs.webkit.org/show_bug.cgi?id=5468> Test 38: expected: 0, got: 1 - removing all children didn't make the element match :empty 11387 - :empty applies to all elements<http://bugs.webkit.org/show_bug.cgi?id=11387> Test 39: expected: 1, got: 0 - :nth-child(odd) failed with child 0 6248 - implement :nth-child selectors<http://bugs.webkit.org/show_bug.cgi?id=6248> Test 40: expected: 1, got: 0 - part 2:7 5468 - broken :first-child, :last-child, :only-child selectors<http://bugs.webkit.org/show_bug.cgi?id=5468> Test 42: expected: 1, got: 0 - rule did not start matching after change 11384 - CSS2/3 child selectors aren't dynamic<http://bugs.webkit.org/show_bug.cgi?id=11384> Test 44: expected: 0, got: 1 - misparsed selectors 16751 - html* .test {} is parsed as html .test<http://bugs.webkit.org/show_bug.cgi?id=16751> Test 59: expected: submit, got: - <button> doesn't have type=submit 16798 - HTMLButtonElement.type should default to "submit"<http://bugs.webkit.org/show_bug.cgi?id=16798> Test 64: expected: ./test.html, got: test.html - object elements didn't resolve URIs correctly 16799 - HTMLObjectElement.data should cannonicalize urls<http://bugs.webkit.org/show_bug.cgi?id=16799> Test 66: expected: null, got: #text - wrong localName 17060 - Text.localName should be null<http://bugs.webkit.org/show_bug.cgi?id=17060> Test 69: expected: 33, got: 0 - SVGSVGTextElement.getNumberOfChars() incorrect 17062 - SVGTextElement.getNumberOfChars returns incorrect value<http://bugs.webkit.org/show_bug.cgi?id=17062> Test 71: UTF-8 encoded XML document with invalid character did not have a well-formedness error 17079 - XML document sent with wrong encoding should fail<http://bugs.webkit.org/show_bug.cgi?id=17079> Test 72: expected: TITLE (first test), got: TITLE - undefined 17080 - WebKit fails Acid3 HTML parsing test<http://bugs.webkit.org/show_bug.cgi?id=17080> Test 73: Undefined value 17082 - WebKit fails Acid3 modification of style text block test<http://bugs.webkit.org/show_bug.cgi?id=17082> Test 74: expected: 10, got: 1 - click event handler called the wrong number of times 17083 - Acid3 expects nested event dispatch support<http://bugs.webkit.org/show_bug.cgi?id=17083> Test 75: getSVGDocument failed for <iframe> referencing an svg document. 17061 - HTMLIFrameElement should have a getSVGDocument() method<http://bugs.webkit.org/show_bug.cgi?id=17061> Test 76: Value undefined (result of expression anim.beginElement) is not object. Test 77: expected: 0, got: 100 - Incorrect animVal value after svg animation. 17077 - SVG Animation is broken (and thus turned off)<http://bugs.webkit.org/show_bug.cgi?id=17077> Test 78: expected: 4776, got: 5550 - getComputedTextLength failed. 17078 - SVGTextElement.getComputedTextLength does not work as expected<http://bugs.webkit.org/show_bug.cgi?id=17078> Test 86: calling setMilliseconds() with no arguments didn't result in NaN 16753 - Date.set* methods with no arguments should result in NaN<http://bugs.webkit.org/show_bug.cgi?id=16753> Test 92: Function object's prototype's constructor was ReadOnly 15003 - Function object's prototype's constructor should not be ReadOnly<http://bugs.webkit.org/show_bug.cgi?id=15003> Elapsed time: 4.03s (debug build) There are also some visual failures: 16760 <http://bugs.webkit.org/show_bug.cgi?id=16760> - HTML Object elements should not render 404 content 16770 <http://bugs.webkit.org/show_bug.cgi?id=16770> - Acid3 expects :visited styles to update after iframe load 17085 <http://bugs.webkit.org/show_bug.cgi?id=17085> - Acid3 Ahem test font no longer loads properly 17086 - Positioned X is a few pixels off<http://bugs.webkit.org/show_bug.cgi?id=17086> Bugs discovered during testing, but not required to pass Acid3: 8961 <http://bugs.webkit.org/show_bug.cgi?id=8961> - document.write() does not flush plain text (shift-click on the A to see failure) 14256 <http://bugs.webkit.org/show_bug.cgi?id=14256> - Inspector hits assertion while inspecting image in Acid3 17004 <http://bugs.webkit.org/show_bug.cgi?id=17004> - Assertion clicking on n/100 in Acid3 results This is certainly not a full list of all the bugs which will need to be fixed before Acid3 will pass 100% in WebKit-based browsers. However, this is all the bugs that I know to be visible at this time. All Acid3 bugs have Acid3 in the title, you can find them using this query: http://bugs.webkit.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bu… Your comments (and help fixing them) are certainly appreciated. Thanks, Eric

2 1