Open Bug 1553105 Opened 4 years ago Updated 3 months ago

Only return an origin for schemes that are allowed in the URL spec


(Core :: Networking, task, P2)





(Reporter: valentin, Assigned: valentin)


(Blocks 4 open bugs)


(Whiteboard: [necko-triaged])


(1 file)

It seems we have a bunch of tests that rely on chrome:// and moz-extension:// schemes having a non-null origin.
We should either fix the tests, or make sure that we properly address these exceptions.

There's a web-platform-test expecting the origin for a ssh URI to be null

Depends on D30711

In Thunderbird we're using a chrome:// origin to be able to store permissions for an email address.
It's of course a hack...

(In reply to Magnus Melin [:mkmelin] from comment #2)

In Thunderbird we're using a chrome:// origin to be able to store permissions for an email address.

Thanks for letting me know. We could ifdef the exceptions for Thunderbird, but I expect we'll have the same exceptions in m-c for a while ☺


We have an ongoing effort to bring new protocols like ipfs, dat, ssb, ... into Firefox via WebExtensions (tracked by bug 1271553). This change implies that all of them will get origin "null" which in turn would disable important web capabilities.

Any chance we could figure out a solution that would enable such new protocols to continue having origin ?

No longer regressions: libdweb-protocol
See Also: → libdweb-protocol

Hi Irakli,

Would it be OK if we just allow origins for dweb,dat,ipfs,ipns,ssb,wtp or do we need something more extensible?
I intend to land this along with bug 1603699

Flags: needinfo?(rFobic)

Hi Valentin,

I apologize for the delay in response. I have discussed this with @bz in the past and I believe we came to conclusion that ideally we’ll have a static list of protocols and RWLock protected dynamic list as a last resort for unknown protocol schemes. That should allow add-ons to experiment with different protocols without having to patch the Firefox.

More details can be found in Bug 1569733.

Flags: needinfo?(rFobic)

I think the way we should fix this is that there's a public origin (spec algorithm) and a private origin (that accounts for chrome:// and friends). In particular new URL() should do the right thing and not reveal we have special code for chrome://.

Severity: normal → S3
Blocks: 1603699
See Also: libdweb-protocol
Duplicate of this bug: 1821343
You need to log in before you can comment on or make changes to this bug.