Easiest way would be for that to just redirect to about:mozilla - but it can be done more creatively for sure ;-)
*** Bug 1331978 has been marked as a duplicate of this bug. ***
*** Bug 1331991 has been marked as a duplicate of this bug. ***
Perhaps alias about: to moz:// is even better? moz://mozilla moz://credit moz://robots
(In reply to Irvin (MozTW) from comment #4)> Perhaps alias about: to moz:// is even better? I don't think the scope creep is worthwhile, FWIW. Our new branding is stylized as 'moz://a', so making that do *something* feels right, but unless we start using variations of the branding to mean something specific I don't know that it adds much value. Also, from the dupe I filed: > I think we probably shouldn't expose this as a generic protocol handler to the web at large, but just a quirk in the location bar.
REALLY ought to register "moz" with IANA as well. Otherwise it might pop up as a "real" protocol declaration in the future and we might have a conflict. We can just reserve the prefix so that it's not available for general use. In possibly unrelated news, I'm looking for cosponsors for my Multiple Operation Zone draft RFC which will allow browsers to view SNMP messages. Just came up with the idea this morning, and really hoping I can land it in webkit.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #6)> Also, from the dupe I filed:> > I think we probably shouldn't expose this as a generic protocol handler to the web at large, but just a quirk in the location bar. Agreed, although I'd love to expose it in Chrome via a WebExtension. Unfortunately, there doesn't appear to be an API for that in Chrome, although Firefox will have one per bug 1271553 (whose code is the basis for the old-style extension that Richard referenced).
(In reply to Myk Melez [:myk] [@mykmelez] from comment #9)> Agreed, although I'd love to expose it in Chrome via a WebExtension. > Unfortunately, there doesn't appear to be an API for that in Chrome,> although Firefox will have one per bug 1271553 (whose code is the basis for> the old-style extension that Richard referenced). What? I thought we were finally going to be able to be able to do off-main-thread parsing of URLs. The main thing blocking us from doing this was addons providing custom protocol handlers. I have a major objection if we are adding that back and requiring all URL parsing to remain on the main thread. Its huge perf penalty in the platform today.
If we're going to do /anything/, please let it be the simplest thing and not a giant waste of time and risk. Don't we all have more important things to do?
Perhaps as simple as `if ("moz://a".equals(input)) {` in the URL bar 'go' handler?(In reply to Ben Kelly [:bkelly] from comment #10)> (In reply to Myk Melez [:myk] [@mykmelez] from comment #9)> > Agreed, although I'd love to expose it in Chrome via a WebExtension. > > Unfortunately, there doesn't appear to be an API for that in Chrome,> > although Firefox will have one per bug 1271553 (whose code is the basis for> > the old-style extension that Richard referenced).> > What? I thought we were finally going to be able to be able to do> off-main-thread parsing of URLs. The main thing blocking us from doing this> was addons providing custom protocol handlers. I have a major objection if> we are adding that back and requiring all URL parsing to remain on the main> thread. Its huge perf penalty in the platform today. Let's not derail this bug. (In reply to Richard Newman [:rnewman] from comment #11)> If we're going to do /anything/, please let it be the simplest thing and not> a giant waste of time and risk. Don't we all have more important things to> do?> > Perhaps as simple as `if ("moz://a".equals(input)) {` in the URL bar 'go'> handler? We're not doing anything complex here, but the necessity of the awesomebar means we have to do more than that for things to look right.
(In reply to Dave Townsend [:mossop] from comment #12)> (In reply to Ben Kelly [:bkelly] from comment #10)> > (In reply to Myk Melez [:myk] [@mykmelez] from comment #9)> > > Agreed, although I'd love to expose it in Chrome via a WebExtension. > > > Unfortunately, there doesn't appear to be an API for that in Chrome,> > > although Firefox will have one per bug 1271553 (whose code is the basis for> > > the old-style extension that Richard referenced).> > > > What? I thought we were finally going to be able to be able to do> > off-main-thread parsing of URLs. The main thing blocking us from doing this> > was addons providing custom protocol handlers. I have a major objection if> > we are adding that back and requiring all URL parsing to remain on the main> > thread. Its huge perf penalty in the platform today.> > Let's not derail this bug. What is derailing about this? Saying "please don't do it this way, you'll be getting in the way of ongoing work in platform" seems like a very pertinent comment. I would like to see moz://a do something cool in the browser, too, but I'd also rather it be done in such a way that it doesn't make work for somebody else down the line.
(In reply to Nathan Froyd [:froydnj] from comment #14)> (In reply to Dave Townsend [:mossop] from comment #12)> > (In reply to Ben Kelly [:bkelly] from comment #10)> > > (In reply to Myk Melez [:myk] [@mykmelez] from comment #9)> > > > Agreed, although I'd love to expose it in Chrome via a WebExtension. > > > > Unfortunately, there doesn't appear to be an API for that in Chrome,> > > > although Firefox will have one per bug 1271553 (whose code is the basis for> > > > the old-style extension that Richard referenced).> > > > > > What? I thought we were finally going to be able to be able to do> > > off-main-thread parsing of URLs. The main thing blocking us from doing this> > > was addons providing custom protocol handlers. I have a major objection if> > > we are adding that back and requiring all URL parsing to remain on the main> > > thread. Its huge perf penalty in the platform today.> > > > Let's not derail this bug.> > What is derailing about this? Saying "please don't do it this way, you'll> be getting in the way of ongoing work in platform" seems like a very> pertinent comment. I would like to see moz://a do something cool in the> browser, too, but I'd also rather it be done in such a way that it doesn't> make work for somebody else down the line. Sorry, it looked like a discussion about a webextension API. What way exactly shouldn't we do things like this (see the current implementation) and what is the current alternative?
Hey bkelly, where is the off-main-thread URL parsing work happening?
*** Bug 1332182 has been marked as a duplicate of this bug. ***
There is also work happening here: https://bugzilla.mozilla.org/show_bug.cgi?id=1332008 These aren't exactly duplicates - if there is a way to redirect to anything other than the search page quickly I think everyone is in favor of that, even if it's just to about:robots or something. Even better would be to point it at the open design blog that talks about the rebranding: https://blog.mozilla.org/opendesign/ From the side of marketing we do plan to put effort into doing easter eggs here, but were unable to dedicate any resources in time for launch. We also plan to reach out and involve others in that.
Also - a request has already been sent for a provisional registration with IANA. It's unclear what the timeline on those requests are, however.
The IANA SLA is here: https://www.nro.net/wp-content/uploads/ICANN-RIR-SLA-signature25May16.pdf They should ack within 2 business days and respond substantively in 4 business days. https://tools.ietf.org/html/rfc7595 says that provisional registrations are first-come, first-serve basis. We'll likely need to have a more full-featured idea of what the scheme is for before we can get a permanent registration, but provisional will do for now. Richard Barnes may have more context, since he's the one that sent the provisional registration request.
I think making moz://a go to the Manifesto is exactly what's needed, in terms of both scope and destination. Gerv
(In reply to Dave Townsend [:mossop] from comment #12)> (In reply to Richard Newman [:rnewman] from comment #11)> > If we're going to do /anything/, please let it be the simplest thing and not> > a giant waste of time and risk. Don't we all have more important things to> > do?> > > > Perhaps as simple as `if ("moz://a".equals(input)) {` in the URL bar 'go'> > handler?> > We're not doing anything complex here, but the necessity of the awesomebar> means we have to do more than that for things to look right. What exactly does "look right" mean here? What's the UX requirement that a URL bar hack wouldn't satisfy?
Comment on attachment 8828169[details]Bug 1331968: Implement the moz: protocol handler to redirect to a fixed website.https://reviewboard.mozilla.org/r/105654/#review106624 I would steal this because I have comments and mconley's queue is big, but mozreview won't let me. So instead you just get my comments, which I hope are still helpful. We should probably make sure platform is happy with this addition. In defense of this code: we already have lots of these custom protocol handlers (e.g. the page thumbnailing code for the new tab page uses them, too, we have one for feed:, ...). AFAICT off-hand, this one could happily run off-main-thread assuming the stuff we're delegating to is OK with that. It's not like we go off to ask for some browser windows and depend on data in them or anything crazy like that. If we want to take the URL parsing itself out of the protocol handler (leaving just channel creation) we could do that with some revisions and flags (e.g. flag to say "parse this URI as any old nsISimpleURI" and have the IO service delegate parsing to the rust parser, OMT if it fancies). I don't think adding one more trivial protocol handler substantially changes the burden of "front-end" code towards the project of swapping out the URI parser. Nathan / Ben, can you clarify what chrome code should be doing instead, and how/why this addition would be problematic? ::: browser/components/mozProtocolHandler.js:35 (Diff revision 1) > + let protocol = Services.io.getProtocolHandler(realURL.scheme);> + let channel = protocol.newChannel2(realURL, loadInfo); I believe :ckerschb converted a bunch of this to use `Services.io.newChannelFromURIWithLoadInfo`, see e.g. https://dxr.mozilla.org/mozilla-central/source/toolkit/components/thumbnails/PageThumbsProtocol.js#86-91 . This code should probably also set originalURL to something. Maybe. Maybe not, actually, I don't know how much code is going to deal correctly with that. :-\ ::: browser/components/mozProtocolHandler.js:37 (Diff revision 1) > +> + newChannel2(uri, loadInfo) {> + let realURL = NetUtil.newURI(this.urlToLoad);> + let protocol = Services.io.getProtocolHandler(realURL.scheme);> + let channel = protocol.newChannel2(realURL, loadInfo);> + channel.loadFlags != Ci.nsIChannel.LOAD_REPLACE; This doesn't seem to do anything? ::: browser/components/mozProtocolHandler.js:41 (Diff revision 1) > + let channel = protocol.newChannel2(realURL, loadInfo);> + channel.loadFlags != Ci.nsIChannel.LOAD_REPLACE;> + return channel;> + },> +> + newChannel(uri) { This can just call `newChannel2(uri, null);` rather than duplicating it. ::: browser/components/tests/browser/browser_mozprotocol.js:3 (Diff revision 1) > + Services.prefs.setCharPref("browser.mozprotocol.url",> + "https://example.com/browser/browser/components/tests/browser/mozprotocol_redirect.html"); Nit: `yield SpecialPowers.pushPrefEnv(...)`, which means you won't need to call clearUserPref afterwards. ::: browser/components/tests/browser/browser_mozprotocol.js:6 (Diff revision 1) > + yield BrowserTestUtils.withNewTab({ gBrowser, url: "about:blank" }, function*() {> + gBrowser.loadURI("moz://a"); Nit: just pass a string. I think you added that in bug 1255520! :-) ::: browser/components/tests/browser/browser_mozprotocol.js:16 (Diff revision 1) > +// Check that regular websites can't link to moz://a> +add_task(function*() { Instead of doing this here, please update https://searchfox.org/mozilla-central/source/caps/tests/mochitest/browser_checkloaduri.js , which is a lot less work and a bit less fragile than the double yield for an executeSoon'd resolve(). :-)
... finally, should this live in toolkit/ rather than browser/ ?
(In reply to Dão Gottwald [:dao] from comment #23)> (In reply to Dave Townsend [:mossop] from comment #12)> > (In reply to Richard Newman [:rnewman] from comment #11)> > > If we're going to do /anything/, please let it be the simplest thing and not> > > a giant waste of time and risk. Don't we all have more important things to> > > do?> > > > > > Perhaps as simple as `if ("moz://a".equals(input)) {` in the URL bar 'go'> > > handler?> > > > We're not doing anything complex here, but the necessity of the awesomebar> > means we have to do more than that for things to look right.> > What exactly does "look right" mean here? What's the UX requirement that a> URL bar hack wouldn't satisfy? It'd have to be a hack in several places, and would therefore be fragile. Several places because we'd at a minimum also need to make sure the autocomplete suggestions aren't wrong (ie not just say "search for 'moz://a'" and then do something else), and those are based on (among other things) asking for URI fixup, which in turn depends on whether we think the user input is a real URL that we can load (or delegate, or...). Sure, we can add hacks all the way down, and keep adding hacks in other places as we find them, but that doesn't seem very attractive. Just adding a protocol handler seems a lot cleaner to me.
Sorry for being late in the conversation. I had an idea back in November, sadly lost the prototype I made, which was to replace the "chrome://" by "moz://", in the chrome protocol handler. The chrome protocol handles much more than the chrome resources today, and I think this would definitely makes more sense to prefix all these resources with "moz" than "chrome", and avoid providing extra page-rank for another unrelated browser. As many addons still depends on the chrome protocol handler, we cannot remove it, but we can keep it as an alias. Then creating a page "a" to advocate Mozilla history is another story.
(In reply to :Gijs from comment #27)> also need to make sure the> autocomplete suggestions aren't wrong (ie not just say "search for> 'moz://a'" and then do something else), and those are based on (among other> things) asking for URI fixup FYI, today it's a little bit simpler, since it's the urlbar that decides what browser does, and no more the opposite (no more "guessing"). So the urlbar *could* just push out a special result that reads as moz://a and rather goes to mozilla.org. Though, even if we can, should we? The problem I see is that in such a way it would just work in the urlbar when typed. pasting or dropping it wouldn't work (and would need another hack in browser code), having a bookmark to it wouldn't work, and other similar things. Thus, still a pile of hacks.
(In reply to Marco Bonardo [::mak] from comment #29)> (In reply to :Gijs from comment #27)> > also need to make sure the> > autocomplete suggestions aren't wrong (ie not just say "search for> > 'moz://a'" and then do something else), and those are based on (among other> > things) asking for URI fixup> > FYI, today it's a little bit simpler, since it's the urlbar that decides> what browser does, and no more the opposite (no more "guessing"). So the> urlbar *could* just push out a special result that reads as moz://a and> rather goes to mozilla.org.> Though, even if we can, should we? The problem I see is that in such a way> it would just work in the urlbar when typed. pasting or dropping it wouldn't If we supported the "type in URL bar -> submit" case, wouldn't that automatically cover the "paste in URL bar -> submit" case?> work (and would need another hack in browser code), having a bookmark to it> wouldn't work, and other similar things. Thus, still a pile of hacks. This is essentially an easter egg. Supporting just the most straightforward way to get there seems alright to me if that makes things simpler.
(In reply to Dão Gottwald [:dao] from comment #30)> If we supported the "type in URL bar -> submit" case, wouldn't that> automatically cover the "paste in URL bar -> submit" case? Nope, it would be possible, but currently the 2 things follow 2 different code paths (re-using same helpers) and it's not worth changing that just for this.