Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
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); };
On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov <dimich@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
On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting <pkasting@google.com> wrote:
On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov <dimich@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
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 <levin@chromium.org> wrote:
On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting <pkasting@google.com> wrote:
On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov <dimich@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
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 <jorlow@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 <levin@chromium.org> wrote:
On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting <pkasting@google.com>wrote:
On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov <dimich@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
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 <dimich@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 <jorlow@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 <levin@chromium.org> wrote:
On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting <pkasting@google.com> wrote:
On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov <dimich@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: barbieri@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202
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
On Thu, Jul 22, 2010 at 11:07 PM, Darin Adler <darin@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: barbieri@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202
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
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 <darin@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: barbieri@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202
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=557777 Perhaps you could discuss with Dan Winship and Sergio how you could help them there =) See you, -- Gustavo Noronha Silva <gns@gnome.org> GNOME Project
participants (7)
-
Darin Adler
-
David Levin
-
Dmitry Titov
-
Gustavo Noronha Silva
-
Gustavo Sverzut Barbieri
-
Jeremy Orlow
-
Peter Kasting