August 2010 - webkit-dev - lists.webkit.org

Build system complexity
by Jeremy Orlow 14 Aug '10

14 Aug '10

Are there currently any plans for simplifying the situation regarding build systems? I haven't seen any threads for a while, which I assume means no. Is there any low hanging fruit out there? Since many of the build systems are little more than lists of files, it really seems like we should be able to do some sort of consolidation. Or reduce the process down to updating one file and then running a script that updates/generates the rest. Currently, I cringe every time I find out I need to add a new file. In addition, has anyone ever looked at simplifying the mac port's xcode project? It's _by far_ the heaviest burden on the project given that you pretty much need to use xcode (which is mac only...no other port requires this), exported linker symbols are in a separate file, extra effort to expose a new file in WTF to WebCore, extra effort to expose a new file in WebCore to WebKit, etc. Has anyone recently looked at how the mac build could be simplified--especially from the perspective of contributors whose main development platform isn't a mac? Thanks! Jeremy

8 10

Issue with generated expected file.
by KrishnaMurthy Naidu 12 Aug '10

12 Aug '10

Hi All, I got the problem like, When I run the test code html file with google chrome the out is as expected .But if I run the same html file on gtkLauncher the output is different. But When I run it through DRT(dumprenderTree) it shows PASS. My expectation it should show Fail. I have paste bin the test case and generated expected file.Location: http://pastebin.com/uHbtgkbp Please help me how to debug the issue. Thanks Krishna.

1 0

On IDL files, events and writing DOM bindings
by Xan Lopez 12 Aug '10

12 Aug '10

Hi, as we all know, when writing DOM bindings on top of WebKit we are supposed to use the IDL files it ships as the source of the structure and behavior of the DOM. At first I had assumed that to figure out which events apply to each type/class it was OK to see which EventListeners were defined, and go on from there (ie, if there's a onabort defined in Element.idl, Element has an 'abort' Event defined). This, though, seems to be not completely accurate in many cases, and in others it's downright absent: Media elements are defined to have, for example, an 'ended' event, emitted when the playback has finished. The matching attribute is defined in HTMLMediaElement.idl, but the event listener for it is in DOMWindow.idl. This was done here https://bugs.webkit.org/show_bug.cgi?id=26100 completely on purpose, so I assume this is how it's meant to work. So the question is: is it possible to know which Events are defined for each class just from the IDL files, or are we expected to inject part of this knowledge ourselves when writing the bindings? Xan

3 8

Why are we running Sputnik?
by Eric Seidel 11 Aug '10

11 Aug '10

Chromium skips it (and if I remember correctly, they commissioned it?) Why do we want to be running these 6000 tests and slowing down our builds. I was talking with jamesr, and he seemed to think it adds little value to run it every time? (It was supposedly written as more of a development tool for V8?) But maybe I'm missing something? -eric

12 14

Ptr<T>
by Eric Seidel 11 Aug '10

11 Aug '10

I just spent a while debugging an error in code I wrote. I added a couple new Foo* members to a class. And forgot to 0 them in one of the constructors. RefPtr<T>, OwnPtr<T> would have done this for me. But I wanted these to be weak pointers. How about we add a Ptr<T> (or WeakPtr<T> or AutoNull<T> or whatever) to wtf to stop this nonsense. -eric

4 3

About fixing "old" layout bugs
by Xianzhu Wang 11 Aug '10

11 Aug '10

Hi, I'm new to webkit development, and I'd like to hear opinions about the problems I met. Now I'm trying to fix some "old" layout bugs, for example: * white space preceding <br> ( https://bugs.webkit.org/show_bug.cgi?id=37261) * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413) * line breaking around some punctuations ( https://bugs.webkit.org/show_bug.cgi?id=37698) Some people have warned me about the difficulty of fixing these bugs, and now I have realized it. Fixing the bugs themselves is not very difficult, for example, only 2 functional lines change can fix the first bug. However, the change will break more than 4000 existing layout tests mostly because trailing spaces preceding <br>s in current expectations of the tests (for example, "PASS " vs "PASS"). I tried to rebaseline all effected layout tests (for now on mac only), and the patch is about 6MB (Sorry I overlooked the "Bigfile" option when I submitted the patch, so I split it into 4 parts). My questions are: 1. The bugs violate the standards and cause some site compatibility issues. However, because the bugs are old, some web developers might treat them as features and depend on them, so fixing them might break some existing pages. Is there any existing policy about this problem? Are these bugs worth fixing? 2. What's the best practice to deal with a patche containing many updated layout test expectations? Is there a good way to rebaseline the effected tests on all platforms? Thanks, Xianzhu

5 9

how is expected.txt file generating while test layouttests
by KrishnaMurthy Naidu 11 Aug '10

11 Aug '10

2 2

strategy for evaluating performance issues related to memory.
by Mike Marchywka 10 Aug '10

10 Aug '10

So where does this stand right now? I hope to actually contribute at some point. but right now I'm just trying to determine approaches to even finding the problems. ( and yes my disk light still comes on for minutes at a time locking me out of doing antyhing with iceweasel or firefox) I guess at a gross level it would be nice to know when and why page faults occur but a more pro-active approach would be to start understanding the memory needs during design or code examination for other reasons. If there is nothing better, perhaps people could put in formatted comments about memory needs and access patterns and various parameters or issues or assumptions that in the code. I haven't entirely thought this through (duh) and hope to stimulate a discussion ( actually I'd be happy if someone had a one line answer or link to an answer but am not that opitmistic). I would approach this as an addition to finding memory leaks but maybe the worst offenders will go away if there is less clutter. Thanks. - - - - - - Mike Marchywka | V.P. Technology 415-264-8477 marchywka(a)phluant.com Online Advertising and Analytics for Mobile http://www.phluant.com note new address Mike Marchywka 1975 Village Round Marietta GA 30064 415-264-8477 (w)<- use this 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchywka(a)hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

6 10

Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
by Dmitry Titov 10 Aug '10

10 Aug '10

Hi, I'm looking to disable/remove the methods exposed on Navigator for registering the protocol handler and content handler (HTML5 spec is here<http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers> ). It was implemented a while ago, unfortunately neither Chrome nor Safari don't actually implement these. So they are exposed to JS and do nothing when called. There is some level of checks for parameter values but past those checks there is no implementation for Chrome. I've tested Safari 5 and it does not implement it. FF has the implementation since v3 I believe. It is not optimal to expose the methods but dont't have actual implementation (it screws up the feature detection), so I'm thinking about either removing those altogether (until the time someone wants to implement them for real, they are easy to add back) or adding a pair of #ifdefs around each of those methods. I'd lean to the removal, unless there is a port that has work ongoing or planned soon for those implementations. Does anybody vote for #ifdefs? Thanks, Dmitry These are the methods in question: Navigator.idl > interface [ ] *Navigator* { > .... > void *registerProtocolHandler*(in DOMString scheme, in DOMString > url, in DOMString title) raises(DomException); void *registerContentHandler*(in DOMString mimeType, in DOMString > url, in DOMString title) raises(DomException); };

7 10

Some landed patches have incorrect date in commit messages and ChangeLog
by Jian Li 10 Aug '10

10 Aug '10

Hi, I noticed that several patches landed recently have the incorrect date put in the commit messages and ChangeLog. Please fix the incorrect information in ChangeLog. For the commit messages, anyone know if we can fix them or not? Please make sure the correct date is used when you land your patch manually. Thanks. Jian

6 5