706634 - Install (with native app) is not supported on Linux, shows up in the confirmation

Status: RESOLVED INVALID

(Firefox Graveyard :: Web Apps, defect, P1)

Description

[Ian Bicking (:ianbicking)]

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

Comment 1

[Brion Vibber]

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

Comment 2

[Jason Smith [:jsmith]]

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

Comment 3

[Jason Smith [:jsmith]]

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

Comment 4

[Jason Smith [:jsmith]]

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

Comment 5

[Jason Smith [:jsmith]]

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.

Comment 6

[Jason Smith [:jsmith]]

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.

Comment 7

[Jason Smith [:jsmith]]

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

Comment 8

[Jason Smith [:jsmith]]

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.

Comment 9

[Jason Smith [:jsmith]]

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.

Comment 10

[Marco Castelluccio [:marco]]

Attachment: Avoid mozApps property on Linux

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.

Comment 11

[Marco Castelluccio [:marco]]

Attachment: Avoid mozApps property and webapps modules on Linux

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

Comment 12

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

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.

Comment 13

[Marco Castelluccio [:marco]]

(In reply to :Gavin Sharp (use [e-mail] 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?

Comment 14

[:Felipe Gomes (needinfo for replies!)]

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.

Comment 15

[Jason Smith [:jsmith]]

(In reply to :Gavin Sharp (use [e-mail] 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.

Comment 16

[Jason Smith [:jsmith]]

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

Comment 17

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

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.

Comment 18

[Jason Smith [:jsmith]]

(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?

Comment 19

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

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

Comment 20

[Anant Narayanan [:anant]]

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?

Comment 21

[Jason Smith [:jsmith]]

(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?

Comment 22

[Jason Smith [:jsmith]]

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.

Comment 23

[Jason Smith [:jsmith]]

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

Comment 24

[Lukas Blakk [:lsblakk] use ?needinfo]

[Triage Comment]
removing tracking 14, see comment 22

Comment 25

[Jason Smith [:jsmith]]

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.

Comment 26

[Anant Narayanan [:anant]]

(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!