The default bug view has changed. See this FAQ.
Bug 1331968 (moz://a)

Make Firefox support moz://a

VERIFIED FIXED in Firefox 52

Status

()

Firefox
General
VERIFIED FIXED
2 months ago
3 days ago

People

(Reporter: bbondy, Assigned: mossop)

Tracking

unspecified
Firefox 53
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox51+ wontfix, firefox52 verified, firefox53 verified, firefox54 verified)

Details

(URL)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

2 months ago
I'd imagine with the new logo, a lot of people will try typing moz://a in the URL bar.  It currently does a search for moz://a.  

Easter egg waiting to happen? Or maybe another opportunity?

Comment 1

2 months ago
Easiest way would be for that to just redirect to about:mozilla - but it can be done more creatively for sure ;-)
Duplicate of this bug: 1331978
Alias: moz://a
Duplicate of this bug: 1331991

Comment 4

2 months ago
Perhaps alias about: to moz:// is even better?
moz://mozilla
moz://credit
moz://robots

Comment 5

2 months ago
I think it would be better if it sent people to the Mozilla Manifesto:

https://www.mozilla.org/about/manifesto/

After all, the manifesto is exactly what we're about!
(Assignee)

Updated

2 months ago
Assignee: nobody → dtownsend
(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.
(Assignee)

Updated

2 months ago
Depends on: 1332008
https://github.com/mozilla/moz-handler/releases/tag/release-0.1.0 is also a thing that Myk wrote.
(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?
(Assignee)

Comment 12

2 months ago
(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.
Comment hidden (mozreview-request)
(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.
(Assignee)

Comment 15

2 months ago
(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?
Flags: needinfo?(bkelly)
Duplicate of this bug: 1332182
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.
FYI: https://addons.mozilla.org/en-US/firefox/addon/moz-a-protocol-handler/
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.
Flags: needinfo?(bkelly) → needinfo?(rlb)
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 24

2 months ago
mozreview-review
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(). :-)

Comment 25

2 months ago
mozreview-review-reply
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

> Nit: `yield SpecialPowers.pushPrefEnv(...)`, which means you won't need to call clearUserPref afterwards.

Oh, also, can you please use getRootDirectory() to make this line a bit easier to read, and avoid hardcoding the full path to where these files end up?

Comment 26

2 months ago
... finally, should this live in toolkit/ rather than browser/ ?

Comment 27

2 months ago
(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.
(In reply to Mike Conley (:mconley)  - PTO on Jan 20th from comment #16)
> Hey bkelly, where is the off-main-thread URL parsing work happening?

To my knowledge its not being actively worked.  A prerequisite is the removal of addons that can hook the URL parsing with a js handler.  We can't do anything until we get to that point.  So once web extensions are the only addon API we can maybe make some progress.

There have been some bugs over time for this, but they seem to have gotten closed because of the addon thing.  For example, bug 888604.

We do have some "basic" URL parsing that can be used off thread, but it ignores any custom URL schemes.  See bug 1062005.  We can use this in some places (like service workers) where we restrict access to http/https/etc.

> 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.

So my big concern was really that it sounded like custom URL parsing was getting added back to web extensions as a public API.  That scared me quite a bit.  It sounds like from bug 1271553 comment 33, however, that that is not the case.

If we add some chrome js code that we own that does the moz:// thing I'm not as concerned.  We can always change that in the future without addon compat problems.  I was really just scared of a new API to support custom URL parsing.
I filed a new OMT URL parsing bug for those that care about that issue.  See bug 1332355.
Comment on attachment 8828169 [details]
Bug 1331968: Implement the moz: protocol handler to redirect to a fixed website.

https://reviewboard.mozilla.org/r/105654/#review106758

r-'ing for Gijs's points. For expediency, I suggest redirecting the review request to him for future iterations (I cannot currently do it as there is a draft review request preventing me).
Attachment #8828169 - Flags: review?(mconley) → review-
We have the substituting protocol handler precisely for the use case of protocols which want to map one URI space to another.  Please use that here also.  See the protocol defined in PageThumbsProtocol.js for an example.
Comment hidden (mozreview-request)
(Assignee)

Comment 37

2 months ago
(In reply to :Ehsan Akhgari from comment #35)
> We have the substituting protocol handler precisely for the use case of
> protocols which want to map one URI space to another.  Please use that here
> also.  See the protocol defined in PageThumbsProtocol.js for an example.

Can you elaborate more, I'm looking over that file and I don't see what that gives me.
Flags: needinfo?(ehsan)
(In reply to Dave Townsend [:mossop] from comment #37)
> (In reply to :Ehsan Akhgari from comment #35)
> > We have the substituting protocol handler precisely for the use case of
> > protocols which want to map one URI space to another.  Please use that here
> > also.  See the protocol defined in PageThumbsProtocol.js for an example.
> 
> Can you elaborate more, I'm looking over that file and I don't see what that
> gives me.

Sorry I didn't look at the patch closely enough.  You're not mapping moz://a to a file, so I guess the substituting protocol isn't really what you want.  Please ignore me and carry on.  :-)
Flags: needinfo?(ehsan)
(Assignee)

Comment 39

2 months ago
mozreview-review
Comment on attachment 8828169 [details]
Bug 1331968: Implement the moz: protocol handler to redirect to a fixed website.

https://reviewboard.mozilla.org/r/105654/#review106816

::: browser/components/mozProtocolHandler.js:35
(Diff revision 1)
> +    let protocol = Services.io.getProtocolHandler(realURL.scheme);
> +    let channel = protocol.newChannel2(realURL, loadInfo);

I actually don't want to set the original URI. Since we're directing to the web I want everything to see the new url we end up at.
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)

Comment 42

2 months ago
If we do anything with it, we ought to have it redirect to about:mozilla IMO. 
I really doubt that many people are going to play with the new wordmark unintentionally, so why not give them the easter egg if they're curious enough?

Barring that, redirecting to the manifesto would be my next most favored option, since that is indeed our reason for being, and lastly redirecting to the main mozilla.org website as a marketing ploy.

Comment 43

2 months ago
mozreview-review
Comment on attachment 8828169 [details]
Bug 1331968: Implement the moz: protocol handler to redirect to a fixed website.

https://reviewboard.mozilla.org/r/105654/#review106990

r=me though I'm still wondering if we should be moving this to toolkit (sorry, that comment might have gotten lost because it wasn't on reviewboard but just on the bug). Right now this won't work on android, and AIUI if we move it to toolkit (and add it to the package manifest for mobile/), we can trivially make that happen, so perhaps we should?

I don't really care particularly where we make this point initially, we can bikeshed that in another bug. This implements the target based on a pref, so it's trivial to change it afterwards.

::: browser/components/mozProtocolHandler.js:7
(Diff revision 4)
> + * License, v. 2.0. If a copy of the MPL was not distributed with this
> + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
> +
> +const Ci = Components.interfaces;
> +const Cc = Components.classes;
> +const Cu = Components.utils;

Nitty nit:

```js
const { classes: Cc, interfaces: Ci, utils: Cu } = Components;
```

and please also add `use "strict";` at the top.

::: browser/components/mozProtocolHandler.js:15
(Diff revision 4)
> +Cu.import("resource://gre/modules/Services.jsm");
> +Cu.import("resource://gre/modules/NetUtil.jsm");
> +
> +function mozProtocolHandler() {
> +  XPCOMUtils.defineLazyPreferenceGetter(this, "urlToLoad", "browser.mozprotocol.url",
> +                                        "https://www.mozilla.org/protocol");

Should we put this in all.js ?
Attachment #8828169 - Flags: review?(gijskruitbosch+bugs) → review+
(In reply to Nicolas B. Pierron [:nbp] from comment #28)
> 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.

Did anyone consider this? It sounds like a great idea, off-hand (Having moz as an alias to chrome). I just wonder if it got lost in the conversation.

Updated

2 months ago
URL: moz://a
OS: Unspecified → All
Hardware: Unspecified → All
(Assignee)

Comment 45

2 months ago
(In reply to Marco Bonardo [::mak] from comment #44)
> (In reply to Nicolas B. Pierron [:nbp] from comment #28)
> > 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.
> 
> Did anyone consider this? It sounds like a great idea, off-hand (Having moz
> as an alias to chrome). I just wonder if it got lost in the conversation.

I don't think we can easily make this an alias to chrome and use it for easter-eggy type things via moz://a.

(In reply to :Gijs from comment #43)
> Comment on attachment 8828169 [details]
> Bug 1331968: Implement the moz: protocol handler to redirect to a fixed
> website.
> 
> https://reviewboard.mozilla.org/r/105654/#review106990
> 
> r=me though I'm still wondering if we should be moving this to toolkit
> (sorry, that comment might have gotten lost because it wasn't on reviewboard
> but just on the bug). Right now this won't work on android, and AIUI if we
> move it to toolkit (and add it to the package manifest for mobile/), we can
> trivially make that happen, so perhaps we should?
> 
> I don't really care particularly where we make this point initially, we can
> bikeshed that in another bug. This implements the target based on a pref, so
> it's trivial to change it afterwards.

Mostly the pref is there for testing. The url it directs to is a redirect to the open design blog right now but we can point it wherever we like without having to uplift changes to Firefox.

> ::: browser/components/mozProtocolHandler.js:15
> (Diff revision 4)
> > +Cu.import("resource://gre/modules/Services.jsm");
> > +Cu.import("resource://gre/modules/NetUtil.jsm");
> > +
> > +function mozProtocolHandler() {
> > +  XPCOMUtils.defineLazyPreferenceGetter(this, "urlToLoad", "browser.mozprotocol.url",
> > +                                        "https://www.mozilla.org/protocol");
> 
> Should we put this in all.js ?

I'd rather keep this hidden.
The "moz" URI scheme is now registered with IANA:

http://www.iana.org/assignments/uri-schemes
Flags: needinfo?(rlb)
(In reply to Dave Townsend [:mossop] from comment #45)
> (In reply to Marco Bonardo [::mak] from comment #44)
> > (In reply to Nicolas B. Pierron [:nbp] from comment #28)
> > > 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.
> > 
> > Did anyone consider this? It sounds like a great idea, off-hand (Having moz
> > as an alias to chrome). I just wonder if it got lost in the conversation.
> 
> I don't think we can easily make this an alias to chrome and use it for
> easter-eggy type things via moz://a.

I honestly did not knew anything about this code, and I had a working prototype made by cloning the Chrome protocol files and changing the a few strings.

What issues do you expect?
(Assignee)

Comment 48

2 months ago
(In reply to Nicolas B. Pierron [:nbp] from comment #47)
> (In reply to Dave Townsend [:mossop] from comment #45)
> > (In reply to Marco Bonardo [::mak] from comment #44)
> > > (In reply to Nicolas B. Pierron [:nbp] from comment #28)
> > > > 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.
> > > 
> > > Did anyone consider this? It sounds like a great idea, off-hand (Having moz
> > > as an alias to chrome). I just wonder if it got lost in the conversation.
> > 
> > I don't think we can easily make this an alias to chrome and use it for
> > easter-eggy type things via moz://a.
> 
> I honestly did not knew anything about this code, and I had a working
> prototype made by cloning the Chrome protocol files and changing the a few
> strings.
> 
> What issues do you expect?

Various things like the chrome protocol having a very fixed url format (chrome://<namespace>/<type>/) and it causing escalated privileges for anything loaded from it. I also just don't want to over-complicate this bug. This is an easter egg so keeping it simple is all that is needed. The custom protocol gives us the scope to expand this in the future if we want to, for now simplicity is key to getting this landed quickly.

Comment 49

2 months ago
Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/24e88a2d883f
Implement the moz: protocol handler to redirect to a fixed website. r=gijs

Comment 50

2 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/24e88a2d883f
Status: NEW → RESOLVED
Last Resolved: 2 months ago
status-firefox53: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53
(Assignee)

Comment 51

2 months ago
Comment on attachment 8828169 [details]
Bug 1331968: Implement the moz: protocol handler to redirect to a fixed website.

Although this isn't a security or stability issue we'd like to see if that can jump the trains and get to release sooner and be a part of the buzz around the new Mozilla logo

Approval Request Comment
[Feature/Bug causing the regression]: New easter egg for the new Mozilla logo
[User impact if declined]: Users entering moz://a into the address bar will be taken to a yahoo search page
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]: No
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: This is a well contained change that simply adds one new XPCOM component to the build that allows a new protocol to work from the address bar.
[String changes made/needed]: None
Attachment #8828169 - Flags: approval-mozilla-beta?
Attachment #8828169 - Flags: approval-mozilla-aurora?

Comment 52

2 months ago
¡Hola!

On Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 ID:20170123125947 CSet: 36486fdc3813ef7943ae5b07b4128866d1938a6c moz://a redirects to https://blog.mozilla.org/opendesign/

¡Gracias!
Alex
Status: RESOLVED → VERIFIED
Comment on attachment 8828169 [details]
Bug 1331968: Implement the moz: protocol handler to redirect to a fixed website.

moz protocol handler, beta52+, should be in b2
Attachment #8828169 - Flags: approval-mozilla-beta?
Attachment #8828169 - Flags: approval-mozilla-beta+
Attachment #8828169 - Flags: approval-mozilla-aurora?

Comment 54

2 months ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/9a120078e698
status-firefox52: --- → fixed
Flags: in-testsuite+
Flags: qe-verify+
[Tracking Requested - why for this release]: Request from the Brand team to take this change as a ride along in a 51 point release.
status-firefox51: --- → affected
tracking-firefox51: --- → ?
Andrei, could you verify this? Thanks
Flags: needinfo?(andrei.vaida)
Track 51+ as the this might be a ride along in 51.
tracking-firefox51: ? → +
I reproduced this issue using 53.0a1, build ID: 20170118030214, on Windows 10 x64.
I can confirm this issue is fixed, I verified using:
 Fx 54.0a1, build ID: 20170202030211, 
 Fx 53.0a2, build ID: 20170202004013, 
 Fx 52.0b2, build ID: 20170130065342, 
on: Windows 10 x 64, Ubuntu 14.04 LTS and Mac OS X 10.11.
Accessing "moz://a" on the URL bar redirects the user to : https://blog.mozilla.org/opendesign/ .

Cheers!
Status: VERIFIED → RESOLVED
Last Resolved: 2 months ago2 months ago
status-firefox52: fixed → verified
status-firefox53: fixed → verified
status-firefox54: --- → verified
Flags: qe-verify+
Flags: needinfo?(andrei.vaida)

Updated

2 months ago
Status: RESOLVED → VERIFIED
Thanks for testing.

Looking like we won't ship it in the dot release (decision from product in an email thread)
status-firefox51: affected → wontfix
Depends on: 1349529
You need to log in before you can comment on or make changes to this bug.