arni2033 Reporter
	Description • 9 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150525141253

Steps to reproduce:

1. Open clear profile with e10s ON.
2. Paste irc://irc.mozilla.org/firefox in addressbar, press Enter.



Actual results:

Browser opened search results for "irc://irc.mozilla.org/firefox" in current page.


Expected results:

Browser should suggest to choose application for that irc:// link.

	Loic
	Comment 1 • 9 years ago

It's not specific to IRC links. Probably a dupe.

	Tracy Walker [:tracy]
	Comment 2 • 9 years ago

WFM on Mac with latest Nightly. (Win only?)

arni, please update your build and try again, thanks.

	arni2033 Reporter
	Comment 3 • 9 years ago

Just installed latest Nightly on my Windows7 and irc:// links still not working in e10s.

	Jonathan Howard
	Comment 4 • 9 years ago

Same bug on Linux.

Maybe bug 940206 (which does not have e10s milestone set, possibly should.)

	Mardeg
	Comment 7 • 9 years ago

Copying over relevant bug 940206 comment 22:

"It is using a chrome custom protocol handler (nsIProtocolHandler).  This is the same confusion I had.  This bug is not relevant. Look at the latest beta versions of my addon for code that works (frame.js is the frame script, frame.jsm contains the handler):
https://addons.mozilla.org/en-us/firefox/addon/torrent-status-tool/

To the best of my knowledge, the only way to use these with e10s enabled is to manually register your protocol handler in a frame script.  I could not find as way to do this using the old chrome.manifest registration.  Protocol handlers registered in a component exist but are never called to handle content."

	Samuel Sieb
	Comment 8 • 9 years ago

Looks like we need to change the protocol handler registration.

	James Ross
	Comment 10 • 9 years ago

I don't see the relationship to bug 1175056, as ChatZilla uses nsIProtocolHandler and not nsIWebContentHandlerRegistrar.

	:Gijs (he/him)
	Comment 11 • 9 years ago

(In reply to James Ross from comment #10)
> I don't see the relationship to bug 1175056, as ChatZilla uses
> nsIProtocolHandler and not nsIWebContentHandlerRegistrar.

I agree. The general case here, for things like mibbit, also doesn't really seem like a dupe of the owncloud bug... Brad, can you clarify?

	Brad Lassey [:blassey] (use needinfo?)
	Comment 12 • 9 years ago

(In reply to :Gijs Kruitbosch from comment #11)
> (In reply to James Ross from comment #10)
> > I don't see the relationship to bug 1175056, as ChatZilla uses
> > nsIProtocolHandler and not nsIWebContentHandlerRegistrar.
> 
> I agree. The general case here, for things like mibbit, also doesn't really
> seem like a dupe of the owncloud bug... Brad, can you clarify?

Consensus in triage was that these all have a common solution of remoting nsIHandlerService

	James Ross
	Comment 13 • 9 years ago

Thanks Brad; so can we a) confirm the bug we've been duped to here and b) make that bug (or one it depends on?) actually mention this idea of remoting nsIHandlerService? The current chain of DUP -> UNCO -> FIXED isn't exactly explaining the situation. :)

	Ian Nartowicz
	Comment 14 • 9 years ago

Bug 940206 claims to have fixed nsIWebContentHandlerRegistrar in e10s.  Has it?  Is that just a sticking plaster awaiting a more complete fix?

	arni2033 Reporter
	Comment 16 • 9 years ago

fix range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=85237019374be7a67a2720a5913bfbde64012ebf&tochange=6f40e9b622236da96a2c10e57b95118acc85ecd4