Open Bug 1569733 Opened 2 years ago Updated 1 year ago

Dynamic registry for standard URL schemes

Categories

(Core :: Networking, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: irakli, Unassigned)

References

()

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

As a fallout from Bug 1536744 it is no longer possible to implement an nsIProtocolHandler that supports standard URLs (In other words nsIProtocolHandler.URI_STD is no longer taken into account and newURI is no longer called). There for there is no longer possible to add custom protocols through extensions mechanism who's URLs would have notion of relative URLs or hostname / authority.

To restore that capability we should create a mutable (RWLock protected) data structure (Hashtable or Array) that extensions could register / unregister protocol schemes with that
NS_NewURI would consult to decide whether to use nsIStandardURL or nsSimpleURI.

Bug 1559356 fixed this issue by checking against static list of list of protocols but we need a more general dynamic solution so we don't have to modify list per each extension.

As a fallout from Bug 1536744 it is no longer possible to implement an nsIProtocolHandler that supports standard URLs (In other words nsIProtocolHandler.URI_STD is no longer taken into account and newURI is no longer called). There for there is no longer possible to add custom protocols through extensions mechanism who's URLs would have notion of relative URLs or hostname / authority.

To restore that capability we should create a mutable (RWLock protected) data structure (Hashtable or Array) that extensions could register / unregister protocol schemes with that
NS_NewURI would consult to decide whether to use nsIStandardURL or nsSimpleURI.

I've attempted to write a patch for this, but my lack of C++ experience & gecko internals turned this straightforward task into a challenge. I have uploaded the patch which I did not succeed in finishing, in case someone wants to take over or mentor me to get it completed.

Priority: -- → P3
Whiteboard: [necko-triaged]

Bugbug thinks this bug is a enhancement, but please change it back in case of error.

Type: defect → enhancement

As per discussion at it appears that it maybe desired to some cross / protocol interactions e.g. between (ipns:// & ipfs://) it does not directly affects this, but it's worth considering as probably it would make sense to register interaction policies wherever schemes are registered.

See Also: → 1601816
You need to log in before you can comment on or make changes to this bug.