[webkit-dev] Adding HTTP headers to URL request in WebView
I need to add several HTTP headers to the URL request that is sent after the user clicks any HTTP link in a WebView. I am having difficulty finding a delegate that gives me access the NSURLRequest before it is deep copied, so that I can replace it with a NSMutableURLRequest. Any suggestions would be appreciated. Bill Patterson ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Win32 App
In Cocoa I have made a command line application that init's a WebView, then calls, stringByEvaluatingJavaScriptFromString, however, I'm trying to get this to work in Windows. I've compiled WebKit and added a new Win32 command line project, however, I'm always getting back null when calling stringByEvaluatingJavaScriptFromString. Below is the source, and I've tried a variety of different things to eval (1 + 1, var foo = 1, etc.), and again, it's always null. Can't you use the debugger and single-step the function? Perhaps it returns immediately due to some error or something like that. -- Ariya Hidayat ([EMAIL PROTECTED]) Software Engineer, Qt Software, Nokia ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Blocking UI (linux/gtk)
hi,
Iam analyzing the UI response issues on the webkit linux/gtk port on arm
embedded platform. One observation is that the webcore timer driven
callbacks (e.g. layout, network, tokenizer etc) can block for unbounded
time. The other is that TimerBase::fireTimers fires all pending timers at
once which could mean the UI can be blocked furthur if there are multiple
timer events pending. This looks like an issue on platforms that run
GUI/webcore logic in same threads like gtk.
one of the suggested ways to improve this is to peridodically allow the ui
to run in these callbacks (though that may cause some reentrancy issues).
e.g. TimerBase::fireTimers(..) {for each iteration{ fireTimer;
g_main_context_iteration(..);}}
Appreciate any inputs.
thanks,
Zaheer
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Extreme drop in memory consumption
Hi All, We have started to monitor the memory consumption of JavaScriptCore under linux (qt port) and we noticed two extreme drops. The first (from r36283 to r36285) change hardly effects SunSpider (it used 2.5% less memory only) but the gain for V8 is almost 50% and for WindScorpion (https://lists.webkit.org/pipermail/webkit-dev/2008-August/004562.html) it is 41%. The second (from r36323 to r36325) change increased the memory consumption of SunSpider with about 1.4% while the memory consumption of V8 decreased with 44% and the memory consumption of WindScorpion decreased with 29%. The effect of these two changes together is that WindScorpion uses 58% less memory and V8 uses 72% less memory (while SunSpider uses almost the same amount of memory). Is the memory consumption measured in any platform? Have anyone noticed this change? Regards, Istvan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Win32 App
(reply all this time) Well, it looks like stringByEvaluatingJavaScriptFromString is calling: JSC::JSValue* scriptExecutionResult = coreFrame-loader()-executeScript(WebCore::String(script), true); The problem, I believe, is that coreFrame (an IWebFrame) is not set to a value because I'm not using an actual frame, or view of any kind. Does anyone know if there is a similar way as a Windows app to do the same as in Cocoa? Thank much, ~/Jason Hullinger On Mon, Sep 29, 2008 at 1:12 AM, Ariya Hidayat [EMAIL PROTECTED]wrote: In Cocoa I have made a command line application that init's a WebView, then calls, stringByEvaluatingJavaScriptFromString, however, I'm trying to get this to work in Windows. I've compiled WebKit and added a new Win32 command line project, however, I'm always getting back null when calling stringByEvaluatingJavaScriptFromString. Below is the source, and I've tried a variety of different things to eval (1 + 1, var foo = 1, etc.), and again, it's always null. Can't you use the debugger and single-step the function? Perhaps it returns immediately due to some error or something like that. -- Ariya Hidayat ([EMAIL PROTECTED]) Software Engineer, Qt Software, Nokia ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Maintainer wanted for wkpdf command-line client to WebKit
Dear WebKit developers I'm the developer of a small open-source utility named wkpdf which is basically a command-line interface to the WebKit framework on Mac OS X (see http://wkpdf.plesslweb.ch). The goal of wkdpf is to allow rendering HTML to PDF files from the command line. A number of options allow for setting the paper format, margins, enable background image rendering, etc. Although any HTML renderer should be able to perform this task, the choice of comparable tools is surprisingly small. No browser I know of implements a non-interactive command-line rendering mode. There are few specialized tools, e.g., htmldoc (http://www.easysw.com/htmldoc/) which converts simple HTML files to PDF, but the feature set of htmldoc is very limited. For high-end applications, there is a tool named Prince (http://www.princexml.com/) that is quite powerful but too expensive for casual or hobbyist use. In contrast, wkpdf leverages WebKit's excellent rendering capabilities and OS X's native PDF support to implement a HTML to PDF rendering tool that - thanks to WebKit - supports the latest CSS standards. Given the latest developments in CSS, e.g. pagination or columns, wkpdf could be even used for typesetting books written in HTML and CSS. wkpdf started as a toy project and it is still in its infancy but I think such a tool could be really useful for many users and also promotes the use of WebKit in non-interactive applications. Unfortunately, I don't have the time to working on wkpdf anymore. Thus I'm looking for a new maintainer or other ways to keep wkpdf alive. For example, I would be happy to contribute the wkpdf sources to the WebKit team. If you think that integration of wkpdf into the WebKit repository is useful, or if you would like to be the new maintainer for wkpdf please let me know via this mailing list or private email. Best regards, Christian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] setTimeout as browser speed throttle
Hi, One of the differences between Chrome and Safari is that Chrome sets the setTimeout clamp to 1ms as opposed to 10ms. This means that if the application writer requests a timer of less than 10ms, Chrome will allow it, whereas Safari will clamp the minimum timeout to 10ms. The reason we did this was to minimize browser delays when running graphical javascript applications. This has been a concern for some, so I wanted to bring it up here and get an open discussion going. My hope is to lower or remove the clamp over time. To demonstrate the benefit, here is one test case which benefits from removing the setTimeout clamp. Chrome gets about a ~4x performance boost by reducing the setTimeout clamp. This programming pattern in javascript is very common. http://www.belshe.com/test/sort/sort.htmlhttp://www.belshe.com/test/sort/sort.html One counter argument brought up is a claim that all other browsers use a 10ms clamp, and this might cause incompatibilities. However, it turns out that browsers already use widely varying values. We also really haven't seen any incompatibilities due to this change. It is true that having a lower clamp can provide an easy way for web developers to accidentally spin the CPU, and we have seen one high-profile instance of this. But of course spinning the CPU can be done in javascript all by itself :-) Here is a summary of the minimum timeout for existing browsers (you can test your browser with this page: http://www.belshe.com/test/timers.html )http://www.belshe.com/test/timers.html Safari for the mac: 10ms Safari for windows:15.6ms Firefox: 10ms or 15.6ms, depending on whether or not Flash is running on the system IE : 15.6ms Chrome: 1ms (future - remove the clamp?) So here are a couple of options: 1) Remove or lower the clamp so that javascript apps can run substantially faster. 2) Keep the clamp and let them run slowly :-) Thoughts? It would be great to see Safari and Chrome use the same clamping values. Thanks, Mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] stringByEvaluatingJavaScriptFromString: OSX Windows
On Monday 22 September 2008 13:57, Jason Hullinger wrote:
That function is not exported by the WebKit DLL, so there is no direct way
to GetProcAddress for the method name. Would anyone know what the best
approach would be to compile WebKit in order to generate the libs to build
my own program that could call that function? In other words, would
compiling under Qt, Cygwin or VC++ be better for this, or would any way
allow me to do what I need? I ask because I'm having a very difficult time
compiling for Windows and would like to concentrate on the best approach.
You may be able to use the QtWebkit port on your platforms, and use the
QVariant QWebFrame::evaluateJavaScript(const QString source)
method to do something similar to the ObjC function above. e.g:
QWebPage myPage;
QWebFrame *myFrame = myPage-mainFrame();
myFrame-setHtml(htmlforminput id='myInputElement' value='Default
value'/html);
QString value;
// returns Default value:
value = myFrame-evaluateJavaScript(myInputElement.value).toString();
myFrame-evaluateJavaScript(myInputElement.value='New value');
// returns New value:
value = myFrame-evaluateJavaScript(myInputElement.value).toString();
// returns hello:
value = myFrame-evaluateJavaScript(function hello(){ return 'hello'; }
hello();).toString();
Of course, how this might integrate with your existing (ObjC?) code is another
question :)
Some links that might help:
http://doc.trolltech.com/4.4/qtwebkit.html
http://doc.trolltech.com/4.4/qwebframe.html
http://trac.webkit.org/wiki/QtWebKit
Cheers,
MichaelG
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
We encountered 100% CPU spins on amazon.com, orbitz.com, mapquest.com, among others (looking through Radar histories). This was pre-clamp. Web sites make this mistake because they don't know any better, and it works fine in IE. It is a mistake these sites will continue to make, and Chrome is the only browser that will be susceptible. Being different from IE here is not a good thing. You will end up having to evangelize sites over and over to fix 100% CPU spins that occur only in your browser. Do you really want that kind of headache? A new API will let Web apps get the performance they need while avoiding compatibility problems. dave On Sep 29, 2008, at 10:06 PM, Maciej Stachowiak wrote: On Sep 29, 2008, at 7:26 PM, Mike Belshe wrote: Hi, One of the differences between Chrome and Safari is that Chrome sets the setTimeout clamp to 1ms as opposed to 10ms. This means that if the application writer requests a timer of less than 10ms, Chrome will allow it, whereas Safari will clamp the minimum timeout to 10ms. The reason we did this was to minimize browser delays when running graphical javascript applications. This has been a concern for some, so I wanted to bring it up here and get an open discussion going. My hope is to lower or remove the clamp over time. To demonstrate the benefit, here is one test case which benefits from removing the setTimeout clamp. Chrome gets about a ~4x performance boost by reducing the setTimeout clamp. This programming pattern in javascript is very common. http://www.belshe.com/test/sort/sort.html One counter argument brought up is a claim that all other browsers use a 10ms clamp, and this might cause incompatibilities. However, it turns out that browsers already use widely varying values. I believe all major browsers (besides Chrome) have a minimum of either 10ms or 15.6ms. I don't think this is widely varying. We also really haven't seen any incompatibilities due to this change. It is true that having a lower clamp can provide an easy way for web developers to accidentally spin the CPU, and we have seen one high-profile instance of this. But of course spinning the CPU can be done in javascript all by itself :-) The kinds of problems we are concerned about are of three forms: 1) Animations that run faster than intended by the author (it's true that 10ms vs 16ms floors will give slight differences in speed, but not nearly as much so as 10ms vs no delay). 2) Burning CPU and battery on pages where the author did not expect this to happen, and had not seen it on the browsers he or she has tested with. 3) Possibly slowing things dow if a page is using a 0-delay timer to poll for completion of network activity. The popular JavaScript library jQuery does this to detect when all stylesheets have loaded. Lack of clamping could actually slow down the loading it is intended to wait for. 4) Future content that is authored in one of Safari or Chrome that depends on timing of 0-delay timers will have different behavior in the other. Thus, we get less compatibility benefit for WebKit-based browsers through cross-testing. The fact that you say you have seen one high-profile instance doesn't sound to me like there are no incompatibilities. It sounds like there are some, and you have encountered at least one of them. Points 1 and 2 are what made us add the timer minimum in the first place, as documented in WebKit's SVN history and ChangeLogs. We originally did not have one, and added it for compatibility with other browsers. Currently Chrome gets an advantage on some benchmarks by accepting this compatibility risk. This leads to misleading performance comparisons, in much the same way as firing the load event before images are loaded would. Here is a summary of the minimum timeout for existing browsers (you can test your browser with this page: http://www.belshe.com/test/timers.html ) Safari for the mac: 10ms Safari for windows:15.6ms Firefox: 10ms or 15.6ms, depending on whether or not Flash is running on the system IE : 15.6ms Chrome: 1ms (future - remove the clamp?) So here are a couple of options: 1) Remove or lower the clamp so that javascript apps can run substantially faster. 2) Keep the clamp and let them run slowly :-) Thoughts? It would be great to see Safari and Chrome use the same clamping values. Or there is option 3: 3) Restore the clamp for setTimeout and setInterval to 10ms for compatibility, and add a new setHighResTimer API that does not have any lower bound. This would let aware Web applications get the same benefit, but without any of the compatibility risk to legacy Web content. The main argument against doing things this way is that it would add API surface area. But that seems like a small price to pay for removing the
