September 2010 - webkit-dev - lists.webkit.org

Why does the browser process take up CPU after loadFinished signal is fired?
by luying pan 29 Sep '10

29 Sep '10

Hi All, I'm posting this question on the dev list because it's probably a question that can be best answered by developers who know a lot about the inner workings of webkit. I'm testing various webkit ports on fedora and have observed the same cpu usage behavior across all ports. The pcpu number from ps on the webkit browser process always tappers down slowly after each loadFinished signal has been fired, even if it's a page that does not have any ajax/javascript activities after the page is done loading. It sometimes takes a few minutes for the cpu number to go back down to zero. My question is what does webkit do after the page is done loading that's taking up CPU? Running the browser through strace shows me that a lot of times clock_gettime is called continuously after the page has loaded, and no more request comes in. However even when these clock_gettime calls subside, I still see CPU number great than zero. Any pointers would be helpful or even just sections of the code to look at. I'm trying to use webkit in a resource constrained environment so every little bit of cpu gain counts. Luying

1 0

JSC binding code question
by Kinuko Yasuda 29 Sep '10

29 Sep '10

Hi Webkit folks, I'm writing a JSC binding code (custom binding code for now) for a method that can take JSON-format parameters, and I want to know what would be the right/recommended way. I mean, I want to write a binding code that can executes javascript code like: directoryEntry.getFile("lockfile.txt", {create: true, exclusive: true}); Where the getFile() method is defined as: interface DirectoryEntry : Entry { void getFile(in DOMString path, in Flags flags, /* ... */); }; interface Flags { attribute boolean create; attribute boolean exclusive; }; (They are from the File API: Directories and System's draft [1]) And what I have written for this is like following: if (!exec->argument(1).isNull() && !exec->argument(1).isUndefined() && exec->argument(1).isObject() && !exec->argument(1).inherits(&JSFlags::s_info)) { JSObject* object = exec->argument(1).getObject(); flags = Flags::create(); JSValue jsCreate = object->get(exec, Identifier(exec, "create")); flags->setCreate(jsCreate.toBoolean(exec)); JSValue jsExclusive = object->get(exec, Identifier(exec, "exclusive")); flags->setExclusive(jsExclusive.toBoolean(exec)); } Basically the code calls JSObject::get() to get values for the given property names. This looked straightforward, but I was told that the get(exec) re-enters Javascript and could do any arbitrary thing. This means that during the get() even the parameter object or the calling object (imp) may get deallocated. So here I have two questions: 1) How can I write a safe binding code that reads JSON-format parameters? Is there some recommended way or any good idea? 2) I saw several other code doing the same/similar thing as I do (calling JSObject::get()) to get arbitrary parameter values. Are they safe? Is there a guarantee that the code executed during get() doesn't deallocate some objects? Any help/suggestions/comments would be highly appreciated. Thanks! Kinuko [1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html [2] http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSDirectoryEntryCu…

3 4

X-Purpose on prefetching requests
by Gavin Peters (蓋文彼德斯) 29 Sep '10

29 Sep '10

When the prefetch feature was originally added to WebKit, the first patch (bug 3652), it had a header X-Moz, for backwards compatibility with Firefox. Currently, when Firefox follows link prefetch requests, it adds a header "X-Moz: prefetch" to the request. However, before 3652 was landed, we removed this. The "X-Moz" header is pretty ugly, it has a very bad name. I felt a bit unsatisfied about this, so today I circled back and landed a patch to cause WebKit, when following prefetches, to send an "X-Purpose: prefetch" header, which is modelled closely on the "X-Purpose: preview" header that is sent by Safari when it does its preview generating loads (for those pictures of websites you see on the new tab screen). That patch is in bug 46529. I've also started a discussion in the HTTPbis working group about the three incompatible methods of notification that exist (X-Moz, X-Purpose, and do nothing), to see if a new header "Purpose" makes sense. The X-Purpose patch was controversial though; so Alexey Proskuryakov suggested we start a discussion in the mailing list. Right now, as I see it (and please chime in with what I'm missing), points in favour of sending X-Purpose are: - Conformity. Existing browsers that do prefetching/previewing notify servers, WebKit browsers should follow this. - Differentiation. Allows some kinds of differential treatment. A heavily loaded server may not want to serve prefetches, and 500 them. Some servers today 404 all X-Moz requests; while I think that's a shame, it is good to let people opt out of a feature. - Statistics. Server authors may wish to distinguish the origins of their traffic; although of course this is tricky, since prefetch loads are not always viewed and not always ignored. (send Cache-Control: must-revalidate) to prefetch requests, and you'll accurately know about uses, although at some cost in latency for your users. - Monitoring. Perhaps your web monitoring software or network operations department would like to know the difference between user navigation, and browser-initiated navigation. However, against X-Purpose, we have: - Acceptance. We want prefetching to succeed, and this header will promote opt-out. Besides, opt-out after getting the request is slow anyway. - Cost. Why make requests longer than they need to be? - Dangerous. If people vary content based on this header, they could cause all sorts of caching troubles (for instance a proxy might cache a 404 from a server that's differentiating traffic). What do people think? From I think we should follow existing practice, and send the header. I don't think the header cost is very big, and I am not sure that caching 404s is defensible anyway. Lots of headers shouldn't be used to mutate content; this is not new. Thoughts? - Gavin For the original landing of prefetching, see: https://bugs.webkit.org/show_bug.cgi?id=3652 For this new bug, see: https://bugs.webkit.org/show_bug.cgi?id=46529

4 16

Request to add Build Bot
by Brent Fulgham 27 Sep '10

27 Sep '10

I've finally gotten a system setup and configured to run as a build bot for the WinCairo port. Per the instructions in the wiki, I've filed a bug (https://bugs.webkit.org/show_bug.cgi?id=46360) to add the configuration to the build system. Could someone generate an ID/password combination so I could complete the setup and try to get the bot harnessed to the build system? Thanks! -Brent

3 2

Re: [webkit-dev] Have EWS compile patches that are review+ once it is done with the ones that are review?
by Eric Seidel 24 Sep '10

24 Sep '10

On Fri, Sep 24, 2010 at 11:42 AM, Eric Seidel <eseidel(a)google.com> wrote: > https://bugs.webkit.org/show_bug.cgi?id=35460 > > On Fri, Sep 24, 2010 at 10:25 AM, Darin Adler <darin(a)apple.com> wrote: >> It’s not great that if I review a patch that means it won’t get EWS results. Maybe the EWS could be changed to test out “review+” patches once it gets done with all the “review?” patches? >> >> Is that practical? >> >> -- Darin >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev(a)lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >

2 1

Have EWS compile patches that are review+ once it is done with the ones that are review?
by Darin Adler 24 Sep '10

24 Sep '10

It’s not great that if I review a patch that means it won’t get EWS results. Maybe the EWS could be changed to test out “review+” patches once it gets done with all the “review?” patches? Is that practical? -- Darin

3 3

Disable sheriffbot bug posts?
by Adam Barth 24 Sep '10

24 Sep '10

Hi webkit-dev, Does anyone find the sheriffbot bug posts useful? My sense is that they're too noisy because of flaky tests and large blamelists. I'm inclined to turn them off unless someone else is finding them useful. Thanks, Adam

7 7

Fwd: [webkit-changes] [68146] trunk/WebCore
by Alexey Proskuryakov 24 Sep '10

24 Sep '10

It is unfortunate that this fix changes unused code. Will it be covered by existing layout tests when ScriptFunctionCall and ScriptCallback start being used? The patch and bug were highly confusing. Without any explanation of why this assertion was wrong, a test case, or an explanation of why one can't be made, I had to spend considerable time figuring out why it shouldn't be rolled out immediately. - WBR, Alexey Proskuryakov Начало переадресованного сообщения: > От: commit-queue(a)webkit.org > Дата: 23 сентября 2010 г. 8:57:01 Тихоокеанское летнее время > Кому: webkit-changes(a)lists.webkit.org > Тема: [webkit-changes] [68146] trunk/WebCore > > Revision > 68146 > Author > commit-queue(a)webkit.org > Date > 2010-09-23 08:56:59 -0700 (Thu, 23 Sep 2010) > Log Message > > 2010-09-23 Luiz Agostini <luiz.agostini(a)openbossa.org> > > Reviewed by Andreas Kling. > > Invalid assertion in ScriptCallback > https://bugs.webkit.org/show_bug.cgi?id=46348 > > Removing invalid ASSERT from method ScriptCallback::call(). > > * bindings/js/ScriptFunctionCall.cpp: > (WebCore::ScriptCallback::call): > Modified Paths > > trunk/WebCore/ChangeLog > trunk/WebCore/bindings/js/ScriptFunctionCall.cpp > Diff > > Modified: trunk/WebCore/ChangeLog (68145 => 68146) > > --- trunk/WebCore/ChangeLog 2010-09-23 15:51:41 UTC (rev 68145) > +++ trunk/WebCore/ChangeLog 2010-09-23 15:56:59 UTC (rev 68146) > @@ -1,3 +1,15 @@ > +2010-09-23 Luiz Agostini <luiz.agostini(a)openbossa.org> > + > + Reviewed by Andreas Kling. > + > + Invalid assertion in ScriptCallback > + https://bugs.webkit.org/show_bug.cgi?id=46348 > + > + Removing invalid ASSERT from method ScriptCallback::call(). > + > + * bindings/js/ScriptFunctionCall.cpp: > + (WebCore::ScriptCallback::call): > + > 2010-09-23 Martin Robinson <mrobinson(a)igalia.com> > > Reviewed by Ariya Hidayat. > Modified: trunk/WebCore/bindings/js/ScriptFunctionCall.cpp (68145 => 68146) > > --- trunk/WebCore/bindings/js/ScriptFunctionCall.cpp 2010-09-23 15:51:41 UTC (rev 68145) > +++ trunk/WebCore/bindings/js/ScriptFunctionCall.cpp 2010-09-23 15:56:59 UTC (rev 68146) > @@ -215,9 +215,9 @@ > > CallData callData; > CallType callType = getCallData(m_function.jsValue(), callData); > + if (callType == CallTypeNone) > + return ScriptValue(); > > - ASSERT(callType != CallTypeNone); > - > JSValue result = JSC::call(m_exec, m_function.jsValue(), callType, callData, m_function.jsValue(), m_arguments); > hadException = m_exec->hadException(); > > _______________________________________________ > webkit-changes mailing list > webkit-changes(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes

4 4

http://webkit.org/demos/sticky-notes
by Roger Purves 23 Sep '10

23 Sep '10

to the forum: Would it be difficult to rewrite the demo with textareas (*) replacing the sticky-notes? For my purposes, the so modified demo would only need to work offline, using Safari 5 to open the text file containing the code. In particular I have no interest in using the modified demo in any web site delivered by a server. (Incidentally, in the demo as it is now, too much text entered into a note will result in text spilling out onto the background.) Any help or advice would be much appreciated. Thank you, Roger Purves (*) By textarea, I mean the resizable entity that Safari 5 displays if the fragment below is opened: ................................................... <html> <body> <textarea> </textarea> </body> </html> ...................................................

1 0

Changing API for Document::nodesFromRect
by Antonio Gomes 23 Sep '10

23 Sep '10

Hi all. A few months back, http://trac.webkit.org/changeset/64272 added Document::nodesFromRect as a convenient interface for the rect-based hit testing extension (also added in the same checkin). The intention behind this checkin is to enable WebKit to enlarge the target area of mouse events, by building up a fuzzy rectangular area to be processed by the engine while hit testing, which can be specially useful for touch devices. As is today, the method signature looks like this: void nodesFromRect(int x, int y, int horizontalPadding, int verticalPadding). Basically, the rectangular area to be processed by the engine is built up using the original event position as its center point (x and y), expanding it by the given paddings for each orientation (vertical and horizontal). Empirical results from testing the use of nodesFromRect in capacitive touch screens showed us that users tend to tap below elements. So for even more accurate results (which means pleasant tapping experience), it makes sense to use a region that is offset more above the touch point, favoring elements above the touch point. The Mozilla mobile team also had the same feeling (as described in [1]) and adjusted their nodesFromRect API accordingly by making it possible to specify different offset for each direction (top, right, bottom, left). I propose we to follow their more flexible approach: method signature would change to RefPtr<NodeList> nodesFromRect(int x, int y, int top, int right, int bottom, int left). Whoever still want to share the same value for vertical offsets will be happy, and who want it more flexible will also be happy. Filed bug https://bugs.webkit.org/show_bug.cgi?id=46336 about that. [1] http://starkravingfinkle.org/blog/2010/05/smart-tapping-in-mobile-firefox/ [2] http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIDOMWin… -- --Antonio Gomes

1 0