The story for passing URIs over the wire is well-known by now: either send the spec+charset pair, or use IPC::URI if you're really sure it's not going to break on you. We might as well add the slow path to IPC::URI as a fallback if serialization isn't possible.

This should do the trick.

This won't quite work -- calling NS_NewURI is not sufficient to duplicate a URI in general. Just create it. In the case of URIs with nsIPrincipals, or nested URIs (maybe?), the result won't be the same... The various nsIURI::Clone() implementations would tell you a bit more about what's involved in duplication, but of course that's not serializable in itself. So I think we still want to die in those cases. Implementing the new serialization interface seems like the way to go here. That way we look at each URI and can make sure we're doing the right thing.

One problem with the serialization route is with URL types implemented solely in JS, such as about:firstrun in Fennec. I don't quite understand what the problem with this solution is, seeing as it's the alternative mechanism that other code (such as the chrome registry) is already using.

dan are we good here?

What kind of URIs does the chrome registry deal with? If you can figure out how these cases are going to work: http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsFileDataProtocolHandler.cpp#144 http://mxr.mozilla.org/mozilla-central/source/caps/src/nsNullPrincipalURI.h#56 http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsSimpleNestedURI.h#56 Then I'm good!

The chrome reg handles nsJARURI in addition to the standard URL.

jdm, can we just use this spec+charset serialization for known schemes? For now, just about:

Sounds suitably hacky, but I'd r+ that ;)

to make it a bit less hacky, lets assert if we see something that isn't handled.

Now with a check for about: if non-serializable.

Comment on attachment 447906 [details] [diff] [review] Patch Nice. r=dwitte

This patch caused problems with the history landings, as schemes such as javascript: caused catastrophic failure. Good thing that there's an easy way to mitigate that!

Also, the first patch landed. http://hg.mozilla.org/projects/electrolysis/rev/84eb81208a4a

part 2: http://hg.mozilla.org/projects/electrolysis/rev/17bd6f89d86c

So... wait. How is having a whitelist like that sensible? Won't it just cause failures with schemes you didn't think about that we support, with extensions, etc, etc?

maybe NS_ABORT_IF_FALSE should just be an assertion?

Perhaps. What is this code trying to assert, in that case? You can't assert that nonserializable URIs don't exist; they clearly do....