403798 - register{Protocol,Content}Handler should use NS_ERROR_DOM_SECURITY_ERR

Status: NEW

(Firefox :: File Handling, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

Right now they use NS_ERROR_FAILURE.

Comment 1

[Florian Quèze [:florian]]

The spec says:

User agents should raise security exceptions if the methods are called with protocol or mimeType values that the UA deems to be "privileged". For example, a site attempting to register a handler for http URIs or text/html content in a Web browser would likely cause an exception to be raised. 

Comment 2

[Florian Quèze [:florian]]

Attachment: patch v1

I'm not sure the way I check if a content type is handled internally is correct. I would like to have feedbacks on this point.

Comment 3

[Florian Quèze [:florian]]

CC'ing biesi and bz to get some feedback...

Comment 4

[Boris Zbarsky [:bzbarsky]]

It depends on the question you want answered, really.  How should types handled by plug-ins be handled?  With the attached code a type handled by a plug-in will either test internal or not depending on whether the user has used that plug-in in the current browsing session.

So I suspect this code isn't what you want.  You want something more like <http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/components/nsBrowserContentHandler.js&rev=1.46&mark=600-604#600>.  Note that the return value is an integer that indicates exactly how the type is handled, in case you want to do something special with plug-ins.

Comment 5

[Florian Quèze [:florian]]

Attachment: wip

Following a discussion on #handlers, we don't want to throw security exceptions when the content type is text/html because this could be valid to handler html document sent with the header Content-Disposition: Attachment.
So we should rather throw a NOT SUPPORTED exception when we don't register a handler because of it's content type.

The attached work in progress patch doesn't really work, when I throw NS_ERROR_DOM_NOT_SUPPORTED_ERR in the Error Console I get:
Error: uncaught exception: [Exception... "'<error>' when calling method: [nsIWebContentHandlerRegistrar::registerContentHandler]" nsresult: "0x8053000c (<unknown>)" location: "JS frame :: http://people.mozilla.com/~ctalbert/test-KML-content.html :: <TOP_LEVEL> :: line 5" data: no]

Comment 6

[Florian Quèze [:florian]]

This is blocked until I find a solution to throw NS_ERROR_DOM_* exceptions from a js XPCOM component without the exception appearing like this in the Error Console:
 '<error>' when calling method: [nsIWebContentHandlerRegistrar::registerContentHandler]" nsresult: "0x8053000c
(<unknown>)"

Comment 7

[Boris Zbarsky [:bzbarsky]]

I assume setting Components.returnCode doesn't work again for some reason?

Comment 8

[Florian Quèze [:florian]]

(In reply to comment #7)
> I assume setting Components.returnCode doesn't work again for some reason?
> 

Either I don't know how to use it or it doesn't work.

When I do:
    Components.returnCode = NS_ERROR_DOM_SYNTAX_ERR;
    return;
I don't get anything at all in the Error Console.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Are you making the call into the JS component from C++, or from other JS code?

Note that if the latter, there is in fact a bug on making the throw work...

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Components.returnCode has been broken for a while, see bug 287107.

Comment 11

[Florian Quèze [:florian]]

(In reply to comment #9)
> Are you making the call into the JS component from C++, or from other JS code?

Not sure. The original call is from JS but I suspect there is a C++ layer somewhere.

Comment 12

[Florian Quèze [:florian]]

I think I won't have time to work on this in the near future. Reassigning to nobody.