On Linux, where there are no native apps, it should simple ask to install.

Confirmed I'm seeing this on FF 8 / Ubuntu 11.10 with the extension.

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/24808709

Needs to be fixed for web apps integration to desktop feature (moz-central code) to prevent user errors when using web apps on linux.

Need a marketplace bug for when to inject mozApps API based on if native is supported or not.

Flagged as tracking for Firefox 14 - We aren't supporting linux at all for this feature, but there's implementation code for this feature active on linux right now.

In the short term, we should not show the notification prompt at all for linux. The behavior should be the same as what is seen on the HTML 5 shim. Assigning to Fabrice to implement, since this is part of the code change for enabling the desktop API.

Actually, hold off on comment 6. Fixing bug 707277 may make this bug invalid.

For comment 7 - Note this means so long as we ensure that the user understands the difference between was has been installed after clicking install. So on linux, this means only the HTML 5 shim.

Per the new implementation on nightly, this needs to be implemented now, as installing apps on linux right now always throws a DOMError. For linux, we need to use the HTML 5 shim (no mozApps API enabled) temporarily until linux support is added.

Felipe, I don't know who should review this. (Should I send the patch to the try server also if it is so simple?) I think we should also backport this to Aurora.

Updated patch. This doesn't add webapps related modules (Webapps.js, Webapps.jsm, webappsUI.jsm) to Linux builds.

Comment on attachment 618699 [details] [diff] [review] Avoid mozApps property and webapps modules on Linux Does #ifndef LINUX actually work? I would imagine you'd need something more like the usual XP_UNIX-but-not-XP_MACOSX dance. I don't think it makes sense to completely remove the APIs - exposing different APIs to the web depending on the platform is problematic, and the fact that we do some monkey-patching of it on one of our websites shouldn't really factor into the decision. We should implement the proper fallback behavior for Linux in the product, rather than relying on web shims.

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #12) > Does #ifndef LINUX actually work? I would imagine you'd need something more > like the usual XP_UNIX-but-not-XP_MACOSX dance. I haven't tried to build the second patch yet, but I've used the LINUX macro before. If it won't work I'll dance with XP_UNIX-but-not-XP_MACOSX :) (can't we create a new constant XP_LINUX?) > I don't think it makes sense to completely remove the APIs - exposing > different APIs to the web depending on the platform is problematic, and the > fact that we do some monkey-patching of it on one of our websites shouldn't > really factor into the decision. We should implement the proper fallback > behavior for Linux in the product, rather than relying on web shims. What could we do for Firefox 14 where the Linux implementation isn't ready? Should we print an error message saying we don't support Linux yet?

Yeah, we do need to remove it from 13, but for 14 (assuming the API will stick for other platforms), it should exist but throw an error as being unsupported.

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #12) > I don't think it makes sense to completely remove the APIs - exposing > different APIs to the web depending on the platform is problematic, and the > fact that we do some monkey-patching of it on one of our websites shouldn't > really factor into the decision. We should implement the proper fallback > behavior for Linux in the product, rather than relying on web shims. I think the proper fallback behavior for Linux should be that users should be able to install apps to their FF profile, but not the native desktop (this should be supported in the OWA API support added for desktop). (In reply to Felipe Gomes (:felipe) from comment #14) > Yeah, we do need to remove it from 13, but for 14 (assuming the API will > stick for other platforms), it should exist but throw an error as being > unsupported. What about having linux behavior being that you can only install apps that your profile, but to your native machine? That might already be supported by Fabrice's patch for adding desktop support for the OWA API.

(In reply to Felipe Gomes (:felipe) from comment #14) > Yeah, we do need to remove it from 13, but for 14 (assuming the API will > stick for other platforms), it should exist but throw an error as being > unsupported. You know I wonder now - If we don't support linux for web apps, could that burn us down the line with some of the new firefox features coming down the pipeline that contain apps integration? Such as new tab and the awesome bar (bug 748955, bug 748962, bug 748959)? I'm concerned that not supporting web apps for linux could end up giving us a headache of having to pref off code for linux in multiple spots, especially that apps integration into firefox is going have more features down the pipeline.

We can pref stuff off, or we can not compile it in, depends on what makes sense for a given component. Just as long as we don't expose non-functional UI to users.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #17) > We can pref stuff off, or we can not compile it in, depends on what makes > sense for a given component. Just as long as we don't expose non-functional > UI to users. I'm more in favor of the pref off through on an about:config parameter (something like webapps.linux.enabled, default to false), as I think we should not put too much of a barrier to entry for Marco's development he is doing on linux. This would be a benefit too for when Marco lands code, as he can actively choose to enable linux on a nightly build to test out the functionality. When we think the code is ready to become active, we could remove the pref. Thoughts?

(In reply to Jason Smith [:jsmith] from comment #18) > I'm more in favor of the pref off through on an about:config parameter > (something like webapps.linux.enabled, default to false), as I think we > should not put too much of a barrier to entry for Marco's development he is > doing on linux. This would be a benefit too for when Marco lands code, as he > can actively choose to enable linux on a nightly build to test out the > functionality. When we think the code is ready to become active, we could > remove the pref. Thoughts? I'm ok with preferring to pref stuff off, as long as it is reasonable from an implementation perspective.

We should land this in time for the Fx15 - currently the Linux experience for apps is worse than the HTML5 fallback, i.e. other browser on Linux. What can be done to make that happen?

(In reply to Anant Narayanan [:anant] from comment #20) > We should land this in time for the Fx15 - currently the Linux experience > for apps is worse than the HTML5 fallback, i.e. other browser on Linux. > > What can be done to make that happen? Given that Marco is building try builds for linux testing, we could just to a compile pref off flag Myk suggested to pref off areas done when we were disabling the web apps feature in 13 and 14 (bug 750936). In Marco's try build and patch to land, he could just remove the pref off compile flag for linux. Does this make sense to everyone? If so, can someone take point to get a patch out for this? If not, could you clarify why?

Given that the linux web apps bugs have both been r+ and are very closed to landing, I don't think implementing this bug fix is necessary anymore. When the linux patches land, please resolve this bug as a won't fix.

(In reply to Jason Smith [:jsmith] from comment #22) > Given that the linux web apps bugs have both been r+ and are very closed to > landing, I don't think implementing this bug fix is necessary anymore. When > the linux patches land, please resolve this bug as a won't fix. Or really should be invalid, given that this bug will no longer be valid once linux support lands.

[Triage Comment] removing tracking 14, see comment 22

Both linux web apps bugs have been pushed to inbound - this is heading to land now. Resolving as invalid, as we now support install web apps in linux.

(In reply to Jason Smith [:jsmith] from comment #25) > Both linux web apps bugs have been pushed to inbound - this is heading to > land now. Resolving as invalid, as we now support install web apps in linux. Marvellous!