When a user goes to about:apps in Firefox 14 or higher, a user should be taken to apps.persona.org to see their apps on the HTML 5 dashboard. This means: 1. Type about:apps into FF 14 or later Expected: The user should be redirected to apps.persona.org.

Let's implement this feature after 744257 lands. We can also use this bug to discuss if apps.persona.org will be ready by Apr 24, and if not, redirect about:apps to myapps.mozillalabs.com.

Why would this block the first version of AITC? I think this might block the AITC k9o dashboard bug, but not the first release, as the first release does not really have end-user consumption?

Flagging productwanted - this proposal conflicts with bug 702363. One of these bugs needs to be resolved as invalid, as both have conflicting ideas against each other.

Jen - Which bug should be implemented in line with what AITC needs - bug 702363 or bug 744985? They are conflicting bugs in terms of requirements, so one of them is the valid bug, the other is invalid. Unless I'm not seeing some inbetween line where both could co-exist.

Please do not remove flags without first discussing it with the person who added it. I had a chat with Jen and Ragavan today, the plan is to release the first version of AITC with about:apps redirecting to *a* URL (not necessarily persona, but some remote site hosted by Mozilla). This will be the case for Desktop/Android. This is the plan for now, but it may change, at which point we can remove the blocker. But the main point is that shipping AITC without a way to get to the dashboard is pretty meaningless. I'd also argue that simply adding a redirect from about:apps to a URL isn't making anything more "user-accessible", they're practically the same, one is just shorter to type. We can still leave bug 702363 open, as the option of implementing a client-side about:apps is still open (but it has some issues, such as not being able to reuse the existing dashboard code because of its reliance on jQuery etc.). When plans change, we can update the bugs accordingly.

(In reply to Anant Narayanan [:anant] from comment #5) > Please do not remove flags without first discussing it with the person who > added it. Generally it's not a good idea to flag a bug as a blocker without going through a triage first. It can be nomed, but making an explicit blocker without discussion isn't a good idea. Changing the whiteboard to a ? mark, given that there's no conclusion whether this should block or not. Also - Please make sure I'm part of those discussions too (along with relevant parties associated). > > I had a chat with Jen and Ragavan today, the plan is to release the first > version of AITC with about:apps redirecting to *a* URL (not necessarily > persona, but some remote site hosted by Mozilla). This will be the case for > Desktop/Android. That's not agreed on nor thought about yet per bug 748977 needing a UX defined yet, so that conclusion does not really make a lot of sense, given that a UX discussion has not even take place yet on this (I've heard it's in the works, but not in the immediate future). > > This is the plan for now, but it may change, at which point we can remove > the blocker. But the main point is that shipping AITC without a way to get > to the dashboard is pretty meaningless. I'd also argue that simply adding a > redirect from about:apps to a URL isn't making anything more > "user-accessible", they're practically the same, one is just shorter to type. See bug 748977 - I have no idea where this "plan" wording is coming from, as there isn't even a UX defined yet for this. The original intentions for the 1st iteration of AITC was not to be user-facing, it was to lay the foundation to allow the pieces to be tested end to end. That was to my understanding what we were using that blocking flag for. The 2nd iteration was to the user-facing portion of it, specifically the satisfying the UX portions of bug 748977. If there's changes to that, then we should discuss this, as major stakeholders need to agree on this. > > We can still leave bug 702363 open, as the option of implementing a > client-side about:apps is still open (but it has some issues, such as not > being able to reuse the existing dashboard code because of its reliance on > jQuery etc.). > > When plans change, we can update the bugs accordingly. Umm...no. The two bugs in the idea proposed conflict with one another, which is why this bug was flagged productwanted in the first place. If we are going with a URL redirect, then the other bug has to be closed as invalid (given that both cannot co-exist with one another, as the behavior is entirely different).

Wait a second, the proposal here definitely isn't a blocker, as I recall the rationale made during desktop web runtime triages indicated that about:apps is not an end-user exposed point of consumption for apps. This definitely isn't a blocker on the same basis.

Please justify your statement that adding a redirect from about:apps to a URL somehow makes this feature ready for user consumption.

(In reply to Jason Smith [:jsmith] from comment #6) > That's not agreed on nor thought about yet per bug 748977 needing a UX > defined yet, so that conclusion does not really make a lot of sense, given > that a UX discussion has not even take place yet on this (I've heard it's in > the works, but not in the immediate future). What UX needs to be defined in order to implement a feature where typing about:apps into the URL bar takes you to a dashboard? This is not a user-facing feature by any means. > See bug 748977 - I have no idea where this "plan" wording is coming from, as > there isn't even a UX defined yet for this. Same as above. > The original intentions for the 1st iteration of AITC was not to be > user-facing, it was to lay the foundation to allow the pieces to be tested > end to end. That was to my understanding what we were using that blocking > flag for. The 2nd iteration was to the user-facing portion of it, > specifically the satisfying the UX portions of bug 748977. If there's > changes to that, then we should discuss this, as major stakeholders need to > agree on this. My comment from #8 stands, how does adding a redirect from about:apps to a dashboard suddenly make this ready for user consumption? > Umm...no. The two bugs in the idea proposed conflict with one another, which > is why this bug was flagged productwanted in the first place. If we are > going with a URL redirect, then the other bug has to be closed as invalid > (given that both cannot co-exist with one another, as the behavior is > entirely different). They do not conflict. This bug is about adding a redirect from about:apps to *a* URL, and I plan on setting that URL as a pref. The pref can point to a local resource (which is what bug bug 702363 is about), or point to a remote resource such as persona (which is what this bug was about). Blocker or not, I plan on implementing this.

The main intent of this patch is to allow easy customizability of where about:apps redirects to. I think most of us agree that about:apps should point to some sort of dashboard that allows management of apps. The closest thing we have to that right now is the dashboard at myapps.mozillalabs.com. This patch redirects about:apps to the value of the "services.aitc.dashboard.url" preference. While we separately resolve the issue of where the dashboard will actually be hosted during marketplace release (persona, mozillalabs or even a local resource URI), this allows us to tweak the behaviour with a small pref change even after the tree for FF16 closes.

Note that bug 702363 is currently marked with FF16 as a milestone. Landing this patch does not conflict with that as with a few tweaks to that patch and a pref change we can simply redirect about:apps to the local dashboard implemented in bug 702363 if/when we decide to do so. In the interim, myapps.mozillalabs.com seems like a suitable destination.

(In reply to Anant Narayanan [:anant] from comment #8) > Please justify your statement that adding a redirect from about:apps to a > URL somehow makes this feature ready for user consumption. I'm actually implying the opposite. This doesn't provide any value to the end-user, so it does not move us closer to making the feature ready for user consumption. (In reply to Anant Narayanan [:anant] from comment #9) > (In reply to Jason Smith [:jsmith] from comment #6) > > That's not agreed on nor thought about yet per bug 748977 needing a UX > > defined yet, so that conclusion does not really make a lot of sense, given > > that a UX discussion has not even take place yet on this (I've heard it's in > > the works, but not in the immediate future). > > What UX needs to be defined in order to implement a feature where typing > about:apps into the URL bar takes you to a dashboard? This is not a > user-facing feature by any means. Then why is it needed in the first place? Why do we need to have about:apps redirect to a dashboard URL? > > > See bug 748977 - I have no idea where this "plan" wording is coming from, as > > there isn't even a UX defined yet for this. > > Same as above. > > > The original intentions for the 1st iteration of AITC was not to be > > user-facing, it was to lay the foundation to allow the pieces to be tested > > end to end. That was to my understanding what we were using that blocking > > flag for. The 2nd iteration was to the user-facing portion of it, > > specifically the satisfying the UX portions of bug 748977. If there's > > changes to that, then we should discuss this, as major stakeholders need to > > agree on this. > > My comment from #8 stands, how does adding a redirect from about:apps to a > dashboard suddenly make this ready for user consumption? See my response above. I was implying the opposite here (that it doesn't move us closer to user consumption). > > > Umm...no. The two bugs in the idea proposed conflict with one another, which > > is why this bug was flagged productwanted in the first place. If we are > > going with a URL redirect, then the other bug has to be closed as invalid > > (given that both cannot co-exist with one another, as the behavior is > > entirely different). > > They do not conflict. This bug is about adding a redirect from about:apps to > *a* URL, and I plan on setting that URL as a pref. The pref can point to a > local resource (which is what bug bug 702363 is about), or point to a remote > resource such as persona (which is what this bug was about). Why? What value do we get out of adding this? Does this fall in line with how firefox typically uses about pages? Random question to someone from FF engineering - What's typical use cases for having about pages? There's seems to be desire for about:apps in some bugs (its a reoccuring theme), but what it is seems never be clear. > > Blocker or not, I plan on implementing this. I think the overarching problem I have right now is I don't understand what about:apps is and why it should even exist in the first place (it's this lingering topic that always comes back for some reason). But then again, it does not affect end users, so I have no issues with the implementation of this (just a lingering point of confusion I guess?).

(In reply to Jason Smith [:jsmith] from comment #12) > (In reply to Anant Narayanan [:anant] from comment #8) > > Please justify your statement that adding a redirect from about:apps to a > > URL somehow makes this feature ready for user consumption. > > I'm actually implying the opposite. This doesn't provide any value to the > end-user, so it does not move us closer to making the feature ready for user > consumption. Then why do you think it is bad for the bug to be marked a blocker? Are only bugs that make the feature ready for user consumption considered blockers? If so, I disagree. It makes it harder for me to track what bugs I need to finish before the next release, and I certainly consider this one on the list. > Then why is it needed in the first place? Why do we need to have about:apps > redirect to a dashboard URL? Good question! My main goal here is have a common entry point to *some* dashboard, instead of waiting for us to resolve the debate between local vs. hosted dashboards, and in the hosted case, where exactly we will end up hosting it. If we get this code in before the FF16 tree closes, it is easy to petition for a single pref change during an Aurora/Beta uplift to have about:apps point to the location we finally decided to ship with. By not having a single entry point, we'll need to make the case to land a little more complex code, potentially during an Aurora/Beta uplift, which is obviously risky. > Why? What value do we get out of adding this? Does this fall in line with > how firefox typically uses about pages? No, but then again, it's not typical for about pages to point to remote content (with the exception of about:home I guess, but it does also have an offline fallback). > Random question to someone from FF engineering - What's typical use cases > for having about pages? There's seems to be desire for about:apps in some > bugs (its a reoccuring theme), but what it is seems never be clear. It's a way for "power users" and developers to get at something (about:config, about:buildconfig, etc.). For AITC, it seems like the ideal entry point for the audience we are hoping will test the feature during the first release. Instead of asking them to go to the dashboard by typing a URL, it is far easier to tell someone to go to "about:apps" than a full URL, while allowing us to change our mind about where exactly the dashboard will be located (local, remote, etc.). At a later point (yet TBD), we will definitely expose the dashboard to the general user population, but that will be a different bug and will need input from the Firefox UI/UX team, no doubt.

(In reply to Anant Narayanan [:anant] from comment #13) > (In reply to Jason Smith [:jsmith] from comment #12) > > (In reply to Anant Narayanan [:anant] from comment #8) > > > Please justify your statement that adding a redirect from about:apps to a > > > URL somehow makes this feature ready for user consumption. > > > > I'm actually implying the opposite. This doesn't provide any value to the > > end-user, so it does not move us closer to making the feature ready for user > > consumption. > > Then why do you think it is bad for the bug to be marked a blocker? Are only > bugs that make the feature ready for user consumption considered blockers? > If so, I disagree. It makes it harder for me to track what bugs I need to > finish before the next release, and I certainly consider this one on the > list. Because if this wasn't implemented, we would probably still go forward with a release. A blocker I think usually means that "we will not release without this fixed," and it should be used for really important things that are absolute essentials. For example, in the desktop web runtime we're blocked on: - Flash failing to initialize in the runtime sometimes (very bad, P1 k9o requirement) - No unit tests (needed to have a feature on mozilla central) - The getInstalled() situation you know about (needs an implementation to greatly improve the uninstall UX flow) Note that just because something isn't a blocker doesn't mean it's not important (there are bugs we view that we want fixed). If tracking is an issue, we can figure out a mechanism for that. I do agree though that having some way to declare a "want" is useful though to track. For marketplace-beta release, we did marketplace-beta= to declare a want, but not a blocker. Would blocking-aitc= be acceptable to help you track and declare this as a want? > > > Then why is it needed in the first place? Why do we need to have about:apps > > redirect to a dashboard URL? > > Good question! My main goal here is have a common entry point to *some* > dashboard, instead of waiting for us to resolve the debate between local vs. > hosted dashboards, and in the hosted case, where exactly we will end up > hosting it. If we get this code in before the FF16 tree closes, it is easy > to petition for a single pref change during an Aurora/Beta uplift to have > about:apps point to the location we finally decided to ship with. > > By not having a single entry point, we'll need to make the case to land a > little more complex code, potentially during an Aurora/Beta uplift, which is > obviously risky. Fair enough, makes sense. > > > Why? What value do we get out of adding this? Does this fall in line with > > how firefox typically uses about pages? > > No, but then again, it's not typical for about pages to point to remote > content (with the exception of about:home I guess, but it does also have an > offline fallback). > > > Random question to someone from FF engineering - What's typical use cases > > for having about pages? There's seems to be desire for about:apps in some > > bugs (its a reoccuring theme), but what it is seems never be clear. > > It's a way for "power users" and developers to get at something > (about:config, about:buildconfig, etc.). For AITC, it seems like the ideal > entry point for the audience we are hoping will test the feature during the > first release. Instead of asking them to go to the dashboard by typing a > URL, it is far easier to tell someone to go to "about:apps" than a full URL, > while allowing us to change our mind about where exactly the dashboard will > be located (local, remote, etc.). Okay, that makes sense. Agreed. > > At a later point (yet TBD), we will definitely expose the dashboard to the > general user population, but that will be a different bug and will need > input from the Firefox UI/UX team, no doubt. Right, which will likely be addressed in bug 748977.

Random question - Is this implementation shown here Desktop Firefox specific or is it an implementation that runs across Desktop and Android? Disclaimer - Android webrt implementation uses about:apps already to hold a dashboard for apps on fennec native.

This is desktop only for now.

Comment on attachment 634709 [details] [diff] [review] Redirect about:apps to value of dashboard.url Review of attachment 634709 [details] [diff] [review]: ----------------------------------------------------------------- Technically this looks good. I haven't followed the discussion in the bug. I trust Anant to do the right thing. ::: services/aitc/Aitc.js @@ +86,5 @@ > + QueryInterface: XPCOMUtils.generateQI([Ci.nsISupports, > + Ci.nsIAboutModule]), > + > + getURIFlags: function(aURI) { > + return Ci.nsIAboutModule.ALLOW_SCRIPT; Do you think URI_SAFE_FOR_UNTRUSTED_CONTENT would be appropriate? I'm trying to think if random pages on the internets may want to link to about:apps. Would there be any security implications? This could always be a simple follow-up bug...

I remember some people (eg. me and Andreas) had objections with using a remotely hosted page for this. Users should have a usable dashboard when they work offline. But maybe none of this stuff is really usable offline...

We could/should make the hosted dashboard work well offline (appcache/etc) – that isn't a perfect (e.g., if your first visit to the dashboard is when you are offline), but should make it more usable.

I agree with Ian & Fabrice. We're just getting our foot in the door by adding a redirect to about:apps here, it does not preclude us from building a fully offline dashboard as discussed in bug 702363. Even if we do have a fully offline dashboard in Firefox, making the hosted one AppCache-friendly would be awesome! Jason: I'm marking this blocking-aitc+ it helps me track what things I need to work on and check-in for the first version.

(In reply to Anant Narayanan [:anant] from comment #20) > Even if we do have a fully offline dashboard in Firefox, making the hosted > one AppCache-friendly would be awesome! FYI: Nick did some awesome work today to appcachify the dashboard: https://github.com/mozilla/openwebapps/commit/13e5a82ce35169f162fd71cba92458e73e72b928

For point of reference, here's some references Myk pointed to for about URI scheme: http://en.wikipedia.org/wiki/About_URI_scheme And as a result, came across this: http://en.wikipedia.org/wiki/Epiphany_%28web_browser%29#Web_Applications_mode

Will double check this in 7/11 nightly build tomorrow, but for 7/10, this does redirect to the dashboard, but there's missing content, an incorrect appcache prompt, etc. At first glance, this looks like the redirect from about:apps to the dashboard URL does occur, but is not reflected in the location bar. The content errors are strange (they don't happen when you go to myapps directly).

Indeed, styling of the about:apps seems to be missing.

(In reply to Jason Smith [:jsmith] from comment #25) > Created attachment 640960 [details] > About Apps Missing Content > > Will double check this in 7/11 nightly build tomorrow, but for 7/10, this > does redirect to the dashboard, but there's missing content, an incorrect > appcache prompt, etc. At first glance, this looks like the redirect from > about:apps to the dashboard URL does occur, but is not reflected in the > location bar. The content errors are strange (they don't happen when you go > to myapps directly). And this definitely happens on 7/11 nightly too. Anant - Any ideas?

Yeah, I should have known, this was my mistake. There are two hacky solutions to this problem: - Change services.aitc.dashboard.url to http://myapps.mozillalabs.com/ (this causes a "redirect" from about:apps to https://myapps.mozillalabs.com/). This will likely break AITC though, so is probably not an option. - Have myapps.mozillalabs.com use absolute URLs instead of relative URLs. These two are only band-aids to the real problem, which is that about:apps is not a redirect, so trying to load an asset like about:apps/icon.png won't work which is what the dashboard is in effect trying to do when loading a relative resource. I'll think about a real fix...

(In reply to Anant Narayanan [:anant] from comment #28) > Yeah, I should have known, this was my mistake. There are two hacky > solutions to this problem: > > - Change services.aitc.dashboard.url to http://myapps.mozillalabs.com/ (this > causes a "redirect" from about:apps to https://myapps.mozillalabs.com/). > This will likely break AITC though, so is probably not an option. > - Have myapps.mozillalabs.com use absolute URLs instead of relative URLs. > > These two are only band-aids to the real problem, which is that about:apps > is not a redirect, so trying to load an asset like about:apps/icon.png won't > work which is what the dashboard is in effect trying to do when loading a > relative resource. > > I'll think about a real fix... Shall I open a new bug track this or reopen this one?