Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
On Sat, 2010-07-24 at 03:32 -0300, Gustavo Sverzut Barbieri wrote: Guessed so from Qt port... Now we need to do that for both soup and curl, or write an abstraction for elf with some backend outside webkit FYI, this is being worked on in soup: https://bugzilla.gnome.org/show_bug.cgi?id=55 Perhaps you could discuss with Dan Winship and Sergio how you could help them there =) See you, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
Guessed so from Qt port... Now we need to do that for both soup and curl, or write an abstraction for elf with some backend outside webkit On Saturday, July 24, 2010, Darin Adler da...@apple.com wrote: This is a matter for the networking layer in your particular port rather than for WebKit itself. It does not require changes to WebKit. The Mac OS X WebKit networking layer, NSURLConnection, has this feature. It’s done by creating a custom NSURLProtocol object. -- Darin -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
On Thu, Jul 22, 2010 at 11:07 PM, Darin Adler da...@apple.com wrote: On Jul 22, 2010, at 2:12 PM, Gustavo Sverzut Barbieri wrote: Sorry to disturb this already dead thread, but we're (webkit-efl) thinking of letting applications/browsers register new protocol handlers to provide contents themselves. A co-worker, Flávio Ceolin, will send more details in another thread, but do you have any idea on the path to have them generically in WebCore? WebKit on Mac OS X already supports this and most other ports as well. Adding it to a platform does not require any changes to WebCore. The frame policy functions in FrameLoaderClient are the hook for this sort of thing, specifically dispatchDecidePolicyForNavigationAction. WebKit looks at the URL and decides it’s something an application can handle based on the OS-specific system for handling such things. Then if it does want to handle it, it calls the frame policy function with the action ignore, which prevents WebCore from doing anything with the link, and then passes the URL on to the other application. Hi Darin, Thanks! But not what I actually need... maybe I lacked an use case, but my usage is not just to handle an URL, rather to provide actual data to webkit based on them. For instance, if I want to access an web archive in tar/zip/rar without uncompressing, I'd like to be able, from my app, to load some data with the base uri being tar:// or maybe something that identifies that file (tar://bla.tar.gz), and then all the relative paths would be prepended tar://, so I could trap it, access the file inside the tar and then feed it back to webkit so the images are shown, css are used, etc... Maybe it is something else completely different? Ideas? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
This is a matter for the networking layer in your particular port rather than for WebKit itself. It does not require changes to WebKit. The Mac OS X WebKit networking layer, NSURLConnection, has this feature. It’s done by creating a custom NSURLProtocol object. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
Sorry to disturb this already dead thread, but we're (webkit-efl) thinking of letting applications/browsers register new protocol handlers to provide contents themselves. A co-worker, Flávio Ceolin, will send more details in another thread, but do you have any idea on the path to have them generically in WebCore? IMO, the logics would require the network backend to delegate to WebCoreSupport the unsupported KURL before failing, that could return some instance to handle the job. This class/instance to handle the job is not abstracted right now, but could be done in a way that we could use it in soup/curl (webkit-efl supported backends) and also in qt. For instance, Qt always delegate access using QNetworkAccessManager and can do what we said, but it is port-specific. As we have 2 network backends (we will likely remain with curl later), having a generic alternative is better, but we could just reuse our code in both backends. Any help is appreciated. Regards! On Thu, Jul 8, 2010 at 3:27 PM, Dmitry Titov dim...@chromium.org wrote: Thanks to all, the bug is here: https://bugs.webkit.org/show_bug.cgi?id=41878 I've added link to tracking Chromium bug as well. Dmitry On Wed, Jul 7, 2010 at 7:59 PM, Jeremy Orlow jor...@chromium.org wrote: That would be the standard thing to do. The sooner someone gets started on the feature, the easier it'll be to revert the patch that removes the code. :-) J On Thu, Jul 8, 2010 at 10:55 AM, David Levin le...@chromium.org wrote: On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov dim...@chromium.org wrote: 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? I vote against removal if only because Chromium has really wanted these badly for a long time and simply hasn't been able to find someone to implement them. Perhaps I could make it worth your while to implement rather than remove the stubs? :) Even if someone to implement them for chromium, it doesn't seem to fix the overall problem. Dmitry indicated that the presences of these is breaking feature detection in browsers using WebKit (-- which is something being heard from web developers). A simple solution is to remove them. Later, any port (including chromium) who gets someone to work on them could re-add these methods back properly under ifdef's. dave ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
On Jul 22, 2010, at 2:12 PM, Gustavo Sverzut Barbieri wrote: Sorry to disturb this already dead thread, but we're (webkit-efl) thinking of letting applications/browsers register new protocol handlers to provide contents themselves. A co-worker, Flávio Ceolin, will send more details in another thread, but do you have any idea on the path to have them generically in WebCore? WebKit on Mac OS X already supports this and most other ports as well. Adding it to a platform does not require any changes to WebCore. The frame policy functions in FrameLoaderClient are the hook for this sort of thing, specifically dispatchDecidePolicyForNavigationAction. WebKit looks at the URL and decides it’s something an application can handle based on the OS-specific system for handling such things. Then if it does want to handle it, it calls the frame policy function with the action ignore, which prevents WebCore from doing anything with the link, and then passes the URL on to the other application. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
Thanks to all, the bug is here: https://bugs.webkit.org/show_bug.cgi?id=41878 I've added link to tracking Chromium bug as well. Dmitry On Wed, Jul 7, 2010 at 7:59 PM, Jeremy Orlow jor...@chromium.org wrote: That would be the standard thing to do. The sooner someone gets started on the feature, the easier it'll be to revert the patch that removes the code. :-) J On Thu, Jul 8, 2010 at 10:55 AM, David Levin le...@chromium.org wrote: On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting pkast...@google.comwrote: On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov dim...@chromium.orgwrote: 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? I vote against removal if only because Chromium has really wanted these badly for a long time and simply hasn't been able to find someone to implement them. Perhaps I could make it worth your while to implement rather than remove the stubs? :) *Even if someone to implement them for chromium, it doesn't seem to fix the overall problem. *Dmitry indicated that the presences of these is breaking feature detection in browsers using WebKit (-- which is something being heard from web developers). A simple solution is to remove them. Later, any port (including chromium) who gets someone to work on them could re-add these methods back properly under ifdef's. dave ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov dim...@chromium.org wrote: 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? I vote against removal if only because Chromium has really wanted these badly for a long time and simply hasn't been able to find someone to implement them. Perhaps I could make it worth your while to implement rather than remove the stubs? :) PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov dim...@chromium.org wrote: 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? I vote against removal if only because Chromium has really wanted these badly for a long time and simply hasn't been able to find someone to implement them. Perhaps I could make it worth your while to implement rather than remove the stubs? :) *Even if someone to implement them for chromium, it doesn't seem to fix the overall problem. *Dmitry indicated that the presences of these is breaking feature detection in browsers using WebKit (-- which is something being heard from web developers). A simple solution is to remove them. Later, any port (including chromium) who gets someone to work on them could re-add these methods back properly under ifdef's. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
That would be the standard thing to do. The sooner someone gets started on the feature, the easier it'll be to revert the patch that removes the code. :-) J On Thu, Jul 8, 2010 at 10:55 AM, David Levin le...@chromium.org wrote: On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov dim...@chromium.org wrote: 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? I vote against removal if only because Chromium has really wanted these badly for a long time and simply hasn't been able to find someone to implement them. Perhaps I could make it worth your while to implement rather than remove the stubs? :) *Even if someone to implement them for chromium, it doesn't seem to fix the overall problem. *Dmitry indicated that the presences of these is breaking feature detection in browsers using WebKit (-- which is something being heard from web developers). A simple solution is to remove them. Later, any port (including chromium) who gets someone to work on them could re-add these methods back properly under ifdef's. dave ___ 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
