Only return an origin for schemes that are allowed in the URL spec
Categories
(Core :: Networking, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox120 | --- | fixed |
People
(Reporter: valentin, Assigned: dotoole)
References
(Blocks 3 open bugs)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file, 4 obsolete files)
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.
Reporter | ||
Comment 1•6 years ago
|
||
There's a web-platform-test expecting the origin for a ssh URI to be null
Depends on D30711
Comment 2•6 years ago
|
||
In Thunderbird we're using a chrome:// origin to be able to store permissions for an email address. https://searchfox.org/comm-central/rev/f759b2f94ff3ef9057f58b9b2dc36fea7994bb9d/mailnews/base/util/mailnewsMigrator.js#155
It's of course a hack...
Reporter | ||
Comment 3•6 years ago
|
||
(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 ☺
Comment 4•6 years ago
|
||
Valentin,
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 ?
Updated•6 years ago
|
Updated•6 years ago
|
Reporter | ||
Comment 5•5 years ago
|
||
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
Comment 6•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 7•4 years ago
|
||
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://.
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 10•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 11•2 years ago
|
||
Depends on D179716
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•1 years ago
|
Reporter | ||
Comment 12•1 year ago
|
||
Comment 13•1 year ago
|
||
Comment 14•1 year ago
|
||
Comment 15•1 year ago
|
||
Comment 16•1 year ago
|
||
bugherder |
Updated•1 year ago
|
Description
•