741415 - Disable mozApps for Beta 13

Status: VERIFIED FIXED

(Firefox Graveyard :: Web Apps, defect)

Description

[Jason Smith [:jsmith]]

Steps:

1. Install Firefox Aurora 13
2. Go to apps.mozillalabs.com/appdir
3. Select an app to install

Expected:

The HTML implementation prompt should appear, as the mozApps API should not be enabled on Firefox 13 (only works on 14 or higher).

Actual:

The door hanger prompt for the Web Apps Integration into Desktop feature appears. This should not be implemented in this branch - The web apps integration into desktop feature did not make it to aurora 13, so there should be no code actively residing there.

Comment 1

[Jason Smith [:jsmith]]

Attachment: Aurora Web App Door Hanger

Comment 2

[[:fabrice] Fabrice Desré]

Marking as invalid since the support in m-c landed for aurora 13.

Comment 3

[Jason Smith [:jsmith]]

Reopening. True - It landed in time for Aurora 13. This bug is opened right now because this is enabled in Aurora 13 without the rest of the web apps integration into desktop implementation. The open question that needs to be answered is whether it's okay to keep it enabled in Aurora or if it needs to be backed out of Aurora. Note that there are issues that are affecting this judgment call (the mozApps whitelisting issue that does not allow using the HTML 5 dashboard and the fact that the state of apps installed on FF 12 builds or earlier vs. after FF 13 are completely different). Need Asa to comment to here to determine bug resolution, please keep open until the question is addressed.

Comment 4

[[:fabrice] Fabrice Desré]

So, please change this bug title to reflect what this is about. 

Also, I don't know what you mean by "the rest of the web apps integration into desktop implementation".

Comment 5

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #4)
> Also, I don't know what you mean by "the rest of the web apps integration
> into desktop implementation".

https://wiki.mozilla.org/Web_Apps_integration

Comment 6

[Alex Keybl [:akeybl]]

Tracking for FF13 since it sounds like we'll need to back out the door hanger code prior to release.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Jason: can you elaborate a little bit on why having the doorhanger appear is problematic without full desktop integration support? Is the only concern that it will be confusing to offer to install an app without having a clear way to later see/manage those apps (it looks like we don't even have bug 702363 yet), or are there also other concerns?

Comment 8

[:Felipe Gomes (needinfo for replies!)]

The native installation is not supported in Firefox 13, so showing the doorhanger to install an app is strange because it will barely do anything.
The only thing it will do is to "install" the app in your profile; that is, add the app to the list of apps you have installed in the marketplace.

I actually think we should completely unexpose the navigator.mozApps api from aurora and leave that for 14 only, to allow the marketplace to do correct feature detection. I don't know what the marketplace would want to do with the set of features that landed for Firefox 13. This is a question for the marketplace team.

Comment 9

[[:fabrice] Fabrice Desré]

We only need a dashboard to get something fully usable. This can be either about:apps or we can whitelist a hosted dashboard.

Having native support is absolutely not blocking the usage of the API.

Comment 10

[Jason Smith [:jsmith]]

In addition to what Felipe said - There's two additional problems this causes for in reference to bug 743705 and bug 741490.

Comment 11

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #9)
> We only need a dashboard to get something fully usable. This can be either
> about:apps or we can whitelist a hosted dashboard.

I don't think there's a defined plan yet for about:apps. The only dashboard that could be needing to be whitelisted is the HTML 5 dashboard (currently at myapps.mozillalabs.com). However, I generally don't understand why whitelisting is even being used in the first place, given that this a public API that should allow developers to build their own dashboards.

> Having native support is absolutely not blocking the usage of the API.

True, although in the current implementation state, a user would not even be able to tell what happened post clicking install right now (gulf of evaluation, bug 707277). Add on the two other problems in comment 9. The result is that the functionality is not usable in FF 13 right now. That's the main rationale for pulling it out of Aurora.

Comment 12

[Jason Smith [:jsmith]]

Meant to say comment 10, not comment 9.

Comment 13

[[:fabrice] Fabrice Desré]

(In reply to Jason Smith from comment #11)
>
> I don't think there's a defined plan yet for about:apps. The only dashboard
> that could be needing to be whitelisted is the HTML 5 dashboard (currently
> at myapps.mozillalabs.com). However, I generally don't understand why
> whitelisting is even being used in the first place, given that this a public
> API that should allow developers to build their own dashboards.

Hint: fennec is gonna have about:apps, and there are pretty happy with that. 

We need to whitelist (or have another mechanism to grant usage permission for all the mozApps.mgmt.* calls because without that any site can get your list of installed apps, including install receipts.
 
> > Having native support is absolutely not blocking the usage of the API.
> 
> True, although in the current implementation state, a user would not even be
> able to tell what happened post clicking install right now (gulf of
> evaluation, bug 707277). Add on the two other problems in comment 9. The
> result is that the functionality is not usable in FF 13 right now. That's
> the main rationale for pulling it out of Aurora.

bug 743705 is probably not the one you meant. Also, let me know what a Linux user will see in Fx 14.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #13)
> (In reply to Jason Smith from comment #11)
> >
> > I don't think there's a defined plan yet for about:apps. The only dashboard
> > that could be needing to be whitelisted is the HTML 5 dashboard (currently
> > at myapps.mozillalabs.com). However, I generally don't understand why
> > whitelisting is even being used in the first place, given that this a public
> > API that should allow developers to build their own dashboards.
> 
> Hint: fennec is gonna have about:apps, and there are pretty happy with that. 
> 
> We need to whitelist (or have another mechanism to grant usage permission
> for all the mozApps.mgmt.* calls because without that any site can get your
> list of installed apps, including install receipts.

Gotcha. Talking on IRC, maybe the best plan here is to whitelist myapps.mozillalabs.com in the short term then. Once we get a better understanding of where the dashboard will move, we'll implement a whitelist change to reflect that.

>  
> > > Having native support is absolutely not blocking the usage of the API.

That's true, but the intention was to have the API implementation go hand and hand with web apps integration into desktop feature. The testing follows that plan as well (I'd like to fall in alignment with the intended target milestone for the feature as a whole), given that the pieces need to be there with a lower churn on requirements (basically to provide a clear picture of what's implemented). As a result, there's insufficient testing on the desktop API right now on Aurora to give a clear picture on quality state. From that, I don't think the desktop API support should merge to Aurora, given that sanity testing reveals the linux issue and the whitelisting issue.

> > 
> > True, although in the current implementation state, a user would not even be
> > able to tell what happened post clicking install right now (gulf of
> > evaluation, bug 707277). Add on the two other problems in comment 9. The
> > result is that the functionality is not usable in FF 13 right now. That's
> > the main rationale for pulling it out of Aurora.
> 
> bug 743705 is probably not the one you meant. Also, let me know what a Linux
> user will see in Fx 14.

Right. The bug I meant to refer to has been marked as a Won't Fix, so no worries about it here. As for what a linux user should see, I'd double check with product management on this one (honestly not sure). Given that time is tight though for defining linux behavior, I'm also still in favor of pulling this out of aurora to be safe.

Comment 15

[Jason Smith [:jsmith]]

When I say should merge to Aurora, I mean be in Aurora 13 right now.

Comment 16

[Jason Smith [:jsmith]]

Due to the thrashing of trying to figure out what's implemented for FF 13 is too high, I also believe this provides further rationale to pull this out of Aurora. The FF 13 experience to my understanding should be the same as FF 12 or higher.

Comment 17

[Jennifer Arguello :ticachica]

After speaking to various people about what this means, I would definitely recommend this code be taken out of FF13.  We do not want Fx13 Beta users navigating to the Mozilla Marketplace and then installing an app and having the UI be broken.

Comment 18

[Jason Smith [:jsmith]]

Sounds good. Can someone take point on this to get the implementation out of FF 13 Aurora? Felipe? Fabrice?

Comment 19

[[:fabrice] Fabrice Desré]

(In reply to Jennifer Arguello :ticachica from comment #17)
> After speaking to various people about what this means, I would definitely
> recommend this code be taken out of FF13.  We do not want Fx13 Beta users
> navigating to the Mozilla Marketplace and then installing an app and having
> the UI be broken.

Sorry, but this lacks any real justification. How is the UI "broken"?

We just need bug 741490 to provide a fully functionnal experience.

Comment 20

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #19)
> Sorry, but this lacks any real justification. How is the UI "broken"?
> 
> We just need bug 741490 to provide a fully functional experience.

That's not the only bug needed. Other bugs that are in consideration include:

- bug 706634
- bug 707277
- bug 740922

There's also the general churn going on right now with the desktop implementation. It's currently high, so there's lack of clarity if the UI implemented is really what we want or not. We're tight on time as well. I'd feel more comfortable therefore handling this during FF 14 to give time not only for the bugs to be fixed, but to handle testing when churn is lower (it's quite high right now). A lower churn for testing gives better justification as to whether we know if the implementation truly meets a quality standard we are stating.

Comment 21

[[:fabrice] Fabrice Desré]

(In reply to Jason Smith from comment #20)
> (In reply to Fabrice Desré [:fabrice] from comment #19)
> > Sorry, but this lacks any real justification. How is the UI "broken"?
> > 
> > We just need bug 741490 to provide a fully functional experience.
> 
> That's not the only bug needed. Other bugs that are in consideration include:
> 
> - bug 706634

How can this be needed for fx 13, since no native install will be there on any plpatform?

> - bug 707277

That's a dashboard/marketplace issue.

> - bug 740922

Even if we want to change that, that's clearly not a blocker.


Anyway, I'm gonna stop doing anything on fx desktop dealing with apps.
You're trying to build a cathedral, no wonder it's taking ages instead of iterating on the usable pieces we have.

Comment 22

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #21)
> (In reply to Jason Smith from comment #20)
> > (In reply to Fabrice Desré [:fabrice] from comment #19)
> > > Sorry, but this lacks any real justification. How is the UI "broken"?
> > > 
> > > We just need bug 741490 to provide a fully functional experience.
> > 
> > That's not the only bug needed. Other bugs that are in consideration include:
> > 
> > - bug 706634
> 
> How can this be needed for fx 13, since no native install will be there on
> any plpatform?

We don't know what the behavior we'll be doing on linux yet (the corner case isn't clearly defined). Do we still show the confirmation? Do we just rely on the HTML 5 shim? The behavior isn't clearly defined.

> 
> > - bug 707277
> 
> That's a dashboard/marketplace issue.

I disagree. This has to do with the behavior post selecting "install" on the notification prompt. What behavior allows a user to know what happens post install? Right now, a user gets no notification at all (gulf of evaluation problem). We would need a UX flow to define what happens post install to ensure that the user knows what happens after clicking install. For FF 13, what would the user expect post-install?

Comment 23

[:Felipe Gomes (needinfo for replies!)]

Here is my reasoning:

Installing an app in 13 will only add it to your list of apps, but the user clicking in the doorhanger will be expecting it to show up in the OS.
The main problem is that the experience would change drastically between Firefox 13 and 14, and this will leave users confused. Firefox 14 should be a clear release as being the first version to support webapps.

The much better alternative is that the Marketplace should treat Firefox 13 in the same manner as it will treat other browsers (i.e., no built-in support), and the experience would be very similar (but more correct) than having this bug + bug 741490

Comment 24

[Jennifer Arguello :ticachica]

Ok I'm going to show both flows here since I am trying to understand the user experience of Fx13 and try to mitigate confusion that may occur once a user upgrades to Fx14. I am not saying the API should not be available just trying to see what the big picture is. 

Fx14 Expected Behavior:
1. User goes to Marketplace and installs an app
2. A door hanger shows and the app is installed natively on Windows/Mac
3. User can launch the app in a native fashion, i.e. shortcut on desktop, applications folder, etc.
4. The user can see all the apps that are installed by going to My Purchases on the Marketplace.
5. (Optionally) I see about:apps as an iterim solution as we figure out where the apps dashboard will live. Fennec is exposing it because of the same reason that we haven't decided to have one place for the apps dashboard to live and for development purposes they needed some where to see all their apps and launch them since native launch was not working. It is looking like it will be about:apps, but it needs more iteration and we need to see what persona.org is planning too. 

Fx13 Actual Behavior:
1. User is using Fx13 
2. User goes to Mozilla Marketplace
3. User installs an app
3. Door hanger appears
4. User hits install
5. Nothing happens in UI since there is no native install support in Fx13.  
And the only way to launch and app is to use a dashboard right? Is that about:apps in Fx13?  And when it launches it launches into a tab correct?

If my understanding is correct, the user experience of 13 and 14 differ greatly and so there may be confusion. 

I hope that better explains the concern.

Comment 25

[Jason Smith [:jsmith]]

(In reply to Jennifer Arguello :ticachica from comment #24)
> Ok I'm going to show both flows here since I am trying to understand the
> user experience of Fx13 and try to mitigate confusion that may occur once a
> user upgrades to Fx14. I am not saying the API should not be available just
> trying to see what the big picture is. 
> 
> Fx14 Expected Behavior:
> 1. User goes to Marketplace and installs an app
> 2. A door hanger shows and the app is installed natively on Windows/Mac
> 3. User can launch the app in a native fashion, i.e. shortcut on desktop,
> applications folder, etc.
> 4. The user can see all the apps that are installed by going to My Purchases
> on the Marketplace.
> 5. (Optionally) I see about:apps as an iterim solution as we figure out
> where the apps dashboard will live. Fennec is exposing it because of the
> same reason that we haven't decided to have one place for the apps dashboard
> to live and for development purposes they needed some where to see all their
> apps and launch them since native launch was not working. It is looking like
> it will be about:apps, but it needs more iteration and we need to see what
> persona.org is planning too. 
> 
> Fx13 Actual Behavior:
> 1. User is using Fx13 
> 2. User goes to Mozilla Marketplace
> 3. User installs an app
> 3. Door hanger appears
> 4. User hits install
> 5. Nothing happens in UI since there is no native install support in Fx13.  
> And the only way to launch and app is to use a dashboard right? Is that
> about:apps in Fx13?  And when it launches it launches into a tab correct?
> 
> If my understanding is correct, the user experience of 13 and 14 differ
> greatly and so there may be confusion. 
> 
> I hope that better explains the concern.

+1. Yes that's definitely a key concern. The user flow is significantly different, even though the UI is the same right now from the user's perspective. There's a good chance of confusion.

Comment 26

[Alfred Kayser]

Exactly where will apps be visible in Firefox?

Comment 27

[Myk Melez [:myk] [@mykmelez]]

(In reply to Fabrice Desré [:fabrice] from comment #21)
> You're trying to build a cathedral, no wonder it's taking ages instead of
> iterating on the usable pieces we have.

All of our code is publicly available and has been throughout this entire process.  And we are very much iterating on the usable pieces we have.  In fact, our series of patches, which progressively add functionality, iterate on the usable functionality you implemented.

There is no cathedral-style development taking place.


The issue here has nothing to do with development methodology.  It's about user experience; i.e. when, in the iterative process of developing this software, we expose our users to the experience we've created.

The experience we are currently providing them, after only one of the numerous patches to implement the experience have landed, is not sufficient even for most beta testing.  We should not expose our users to it.

Comment 28

[Jason Smith [:jsmith]]

Given the time constraint, we're likely going to take care of this after merging to beta. This still needs to be pulled out before releasing FF 13 though.

Comment 29

[Alex Keybl [:akeybl]]

(In reply to Jason Smith from comment #28)
> Given the time constraint, we're likely going to take care of this after
> merging to beta. This still needs to be pulled out before releasing FF 13
> though.

Do you have an ETA for having the backout prepared?

Comment 30

[Jason Smith [:jsmith]]

(In reply to Alex Keybl [:akeybl] from comment #29)
> (In reply to Jason Smith from comment #28)
> > Given the time constraint, we're likely going to take care of this after
> > merging to beta. This still needs to be pulled out before releasing FF 13
> > though.
> 
> Do you have an ETA for having the backout prepared?

Not yet. I'll get on this immediately.

Comment 31

[:Felipe Gomes (needinfo for replies!)]

Attachment: Patch

We could revert everything from bug 697006 but in this patch I'm taking the more conservative approach and just remove what is exposed, if that's fine.
It is not intended for mozilla-central, only for Firefox 13.

Comment 32

[:Gavin Sharp [email: [e-mail]]]

Does disabling only the UI, as that patch does, solve the STR in comment 0? I'm a little confused as to how that patch could have an impact on the "HTML implementation", since that implementation presumably tries to overwrite the native one (present since Firefox 11) regardless of whether it one shows UI or not?

Comment 33

[:Felipe Gomes (needinfo for replies!)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #32)
> Does disabling only the UI, as that patch does, solve the STR in comment 0?
> I'm a little confused as to how that patch could have an impact on the "HTML
> implementation", since that implementation presumably tries to overwrite the
> native one (present since Firefox 11) regardless of whether it one shows UI
> or not?

Not really. Ideally we should unexpose the entire API from 13, but as there was already some traction in this bug I decided to address only what the title says here (remove the UI) to discourage people from using it at all. (Also I don't know if Fennec or B2G is being built off 13 and thus we need to leave it there, although I highly suspect the answer is no.)

Comment 34

[Dão Gottwald [:dao]]

Comment on attachment 617131 [details] [diff] [review]
Patch

Why do we want to discourage people from using navigator.mozApps? They'll at least want to use it for future Firefox releases, right? Since we never migrate all of our users, sites starting to use it when Firefox 14 is released would break in Firefox 13.

Comment 35

[Jason Smith [:jsmith]]

(In reply to Dão Gottwald [:dao] from comment #34)
> Comment on attachment 617131 [details] [diff] [review]
> Patch
> 
> Why do we want to discourage people from using navigator.mozApps? They'll at
> least want to use it for future Firefox releases, right? Since we never
> migrate all of our users, sites starting to use it when Firefox 14 is
> released would break in Firefox 13.

No. This does not discourage users from using navigator.mozApps. They end up instead going back to the old behavior in the HTML implementation with this code disabled and as a result, using the HTML 5 dashboard. If you want to see the behavior that should happen, try installing a web app on an alternative browser or in a Firefox build right now 12 or above. Now, if the code being pulled out does not cause the old behavior in the HTML implementation to occur, then there's a problem (that's what I'll do to verify this bug).

Note - There are sites already using navigator.mozapps way before Firefox 13. The app directory (apps.mozillalabs.com/appdir) is a good example of this.

Dao please read over the comments above to get a picture of why this code is being pulled. If you have questions, please ping me.

Comment 36

[Jason Smith [:jsmith]]

And when I mean 12 or above, I mean 12 or earlier (Firefox 12, Firefox 11, Firefox 10, ...).

Comment 37

[:Gavin Sharp [email: [e-mail]]]

(In reply to Jason Smith from comment #35)
> No. This does not discourage users from using navigator.mozApps. They end up
> instead going back to the old behavior in the HTML implementation with this
> code disabled and as a result, using the HTML 5 dashboard.

That's not what this patch does; we're just talking past each other here. This patch strips out the UI code, which has no impact on the DOM API.

It seems like the patch that we want to back out is http://hg.mozilla.org/mozilla-central/rev/17de225179ac . I forgot that despite the mozApps API landing in 11, we only enabled it for Desktop Firefox in 13 (along with the UI code).

Comment 38

[Ed Lee :Mardak]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #37)
> It seems like the patch that we want to back out is
> http://hg.mozilla.org/mozilla-central/rev/17de225179ac
This looks like the right approach if we don't mind some extra unused UI code.

There was also a decision in the last few days for not letting users get at the current implementation in 14 before the May 3rd apps soft launch (was April 26th launch). This is because there are undesired/unimplemented functionality in what will be Beta 13 and Aurora 14 and will be fixed soon in post-April-24th Nightly 15.

This means we want to turn off mozApps on in Aurora-13-to-be-Beta-13 as well as turn off in the to-be-Aurora-14 while keeping it available in to-be-Nightly-15.

Comment 39

[Ed Lee :Mardak]

Disabling for Beta 13 should just involve reversing bug 697006 on the Aurora 13 repository, right?

How does disabling for Aurora 14 work? After the nightly->aurora code move, there's a week before Aurora nightly updates and in this time we can do the same backout on the 14-in-aurora repository?

Comment 40

[:Gavin Sharp [email: [e-mail]]]

We can do the backouts whenever, it's not critical that it happens before the first updates.

Comment 41

[:Felipe Gomes (needinfo for replies!)]

Attachment: Remove mozApps from beta

I also looked into adding these to removed-files.in but interestingly they are already there: http://hg.mozilla.org/mozilla-central/rev/de34e4fefcad

I don't quite understand why most files are listed in removed-files.in, even ones still in use. I'm guessing this was due to the transition to omni.jar.  If so, I believe this patch is all I need, but I'm marking feedback only for now to check.

This is intended for mozilla-beta only

Comment 42

[Lukas Blakk [:lsblakk] use ?needinfo]

We're already heading towards beta3 so getting this backout landed sooner rather than later would be great here. Please nominate for approval-mozilla-beta as soon as possible.

Comment 43

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 619700 [details] [diff] [review]
Remove mozApps from beta

I got a try build with this patch to test the packaged builds and it works properly. Switching to review

Comment 44

[Dão Gottwald [:dao]]

Why isn't this a straight backout of bug 697006 (except strings, I guess)?

Comment 45

[:Felipe Gomes (needinfo for replies!)]

Just to have the minimal change possible that is necessary to disable this API. I could back out only patch 1 from bug 697006 but IIRC talking with gavin during the work week we figured just removing these files from the package was probably the best way to go

Comment 46

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 619700 [details] [diff] [review]
Remove mozApps from beta

Going with the simpler approach seems best. I imagine this might require some dev-doc changes?

Comment 47

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 619700 [details] [diff] [review]
Remove mozApps from beta

[Approval Request Comment]
Regression caused by (bug #): api landed in bug 697006
User impact if declined: api exposed to the web before feature complete
Testing completed (on m-c, etc.): sent to try https://tbpl.mozilla.org/?tree=Try&rev=0f64495f948c
Risk to taking this patch (and alternatives if risky): small I think, it's code removal
String changes made by this patch: none

Comment 48

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 619700 [details] [diff] [review]
Remove mozApps from beta

try run looks good, let's get this out.

Comment 49

[:Felipe Gomes (needinfo for replies!)]

https://hg.mozilla.org/releases/mozilla-beta/rev/50cb09eabb57

Comment 50

[Simona Badau, Desktop QA]

Verified on Firefox 13 beta 3 that after installing an application from apps.mozillalabs.com/appdir, the HTML implementation prompt appears and not the door hanger for the Web Apps Integration.

Verified on Windows 7, Ubuntu 12.04 and Mac OS X 10.6:
Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0

Setting this to VERIFIED FIXED.