Closed Bug 744193 Opened 12 years ago Closed 12 years ago

Install web app on host OS - Linux

Categories

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

All
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 15

People

(Reporter: marco, Assigned: marco)

References

()

Details

(Whiteboard: [qa!])

Attachments

(1 file, 3 obsolete files)

Support native installation of Web Apps on Linux.
Blocks: 731054
This is not targeted for the first release of web apps integration into desktop.
No longer blocks: 731054
No longer depends on: 731541
(In reply to Jason Smith from comment #1)
> This is not targeted for the first release of web apps integration into
> desktop.

True, although it would be an excellent opportunity for getting community members involved. I'd be happy to coordinate with anybody who wants to work on this.
Agreed. Could you link the Google Summer of Code project to this bug?
I'm working on this on top of bug 731541 patch, this is why I made this bug depend on that.
I've sent a proposal for the Google Summer of Code to work on native webapps support for Linux, but I was planning to do this anyway.
(In reply to Marco Castelluccio from comment #4)
> I'm working on this on top of bug 731541 patch, this is why I made this bug
> depend on that.
> I've sent a proposal for the Google Summer of Code to work on native webapps
> support for Linux, but I was planning to do this anyway.

Gotcha. Do you have a ETA on when a patch would land with Linux support? Just wondering when I need to have an associated test plan by.
Assignee: nobody → mar.castelluccio
(In reply to Jason Smith from comment #5)
> Gotcha. Do you have a ETA on when a patch would land with Linux support?
> Just wondering when I need to have an associated test plan by.

Do you mean only the installation bits or also the webapp runtime?
(In reply to Marco Castelluccio from comment #6)
> (In reply to Jason Smith from comment #5)
> > Gotcha. Do you have a ETA on when a patch would land with Linux support?
> > Just wondering when I need to have an associated test plan by.
> 
> Do you mean only the installation bits or also the webapp runtime?

Generally, a picture of the schedule for the implementation of the feature for it's major parts (including the examples you've provided). Specifically, I'm looking to know what Firefox release milestone you are looking to target (e.g. Firefox 14, Firefox 15, etc) for each piece and the parts underlying that are getting implemented for each part. 

Btw, to clarify who I am, I'm the desktop QA driver for web apps. If you are looking for insight on how to test your feature, ping me with any questions you have. As for creating the test plan, we should work together on it once the features have landed, as I already have a good amount of general test cases you can run for web apps integration into desktop.
I'll write a list of the pros and cons of the two approaches I've described in my GSoC proposal.

For now I'm working on the installation without packages, that is the solution I prefer, but nothing has been decided yet.
(In reply to Marco Castelluccio from comment #8)
> For now I'm working on the installation without packages, that is the
> solution I prefer, but nothing has been decided yet.

Note - It may be worth to implement the "simpler" solution first for a 1st release. The 2nd release could include package management.
(In reply to Jason Smith from comment #9)
> Note - It may be worth to implement the "simpler" solution first for a 1st
> release. The 2nd release could include package management.

Yes, we could also use the solution with packages on the most used distributions (deb and rpm based, like Ubuntu, Fedora, etc.) and the other solution on the other distributions, so that we would support everything.
If another distribution with another package management system would like to be supported, the developers can simply write an extension to do so.
(In reply to Shyukri Shyukriev from comment #11)
> Created attachment 617564 [details]
> [Object DOMError] on OpenSUSE 12.1 64-bit, 14.0a1 (2012-04-23)

Right, I know of the bug you are talking about. We need to disable the confirmation for nightly in bug 706634 for linux in the short-term. In this bug, we'll need to provide an implementation for linux, that include re-enabling the confirmation and fixing the issue causing the DOMError.
Whiteboard: [marketplace-beta-]
(In reply to Shyukri Shyukriev from comment #11)
> Created attachment 617564 [details]
> [Object DOMError] on OpenSUSE 12.1 64-bit, 14.0a1 (2012-04-23)

That DOMError is thrown because the manifest file of the applications on https://apps.mozillalabs.com/appdir/ doesn't allow installation from that website.
Target Milestone: --- → Firefox 14
Version: unspecified → Trunk
(In reply to Marco Castelluccio from comment #13)
> (In reply to Shyukri Shyukriev from comment #11)
> > Created attachment 617564 [details]
> > [Object DOMError] on OpenSUSE 12.1 64-bit, 14.0a1 (2012-04-23)
> 
> That DOMError is thrown because the manifest file of the applications on
> https://apps.mozillalabs.com/appdir/ doesn't allow installation from that
> website.

That's weird, cause I can install apps from that site on windows and mac right now.
(In reply to Jason Smith from comment #14)
> That's weird, cause I can install apps from that site on windows and mac
> right now.

You're right, it seems I tried with the only application that has a wrong manifest :)

>  "installs_allowed_from": [
>    "https://appstore.mozillalabs.com",
>    "https://apps-preview.mozilla.org"
>  ]
(In reply to Jason Smith from comment #1)
> This is not targeted for the first release of web apps integration into
> desktop.

It would be nice if this was noted on this page https://quality.mozilla.org/2012/04/desktop-web-apps-landed-in-nightly-try-it-out/ so us Linux users don't waste our time and hope energy. Merely omitting Linux-related bits doesn't say it doesn't work on Linux and that Linux won't be supported in the first release.
Target Milestone: Firefox 14 → ---
Marco - Are there any patches you need reviewed and help on? Let me know - I'll ping a couple of developers to get review or help on it if needed.
(In reply to Jason Smith [:jsmith] from comment #17)
> Marco - Are there any patches you need reviewed and help on? Let me know -
> I'll ping a couple of developers to get review or help on it if needed.

Jason, we could start with bug 744190, that is needed for the installation. Thank you :)
Attached patch Install webapps on Linux (obsolete) — Splinter Review
Attachment #617564 - Attachment is obsolete: true
Attachment #622566 - Flags: feedback?(felipc)
Marco - Could you create a try build for your linux patches? If the try build passes, I'd be more than happy to try out the linux web apps implementation and give you feedback.
Comment on attachment 622566 [details] [diff] [review]
Install webapps on Linux

Review of attachment 622566 [details] [diff] [review]:
-----------------------------------------------------------------

This patch is looking great, Marco!

::: browser/modules/WebappsInstaller.jsm
@@ +670,5 @@
> +    this.appNameAsFilename = this.appNameAsFilename.toLowerCase();
> +
> +    // Need a unique name here, maybe like installDir on Windows
> +    this.installDir = Services.dirsvc.get("Home", Ci.nsILocalFile);
> +    this.installDir.append("." + this.appNameAsFilename);

hmm this is an interesting question...  On one hand, the name here doesn't matter in the UI (as what will matter is the shortcut name), so going with the origin;protocol;port seems like the best option (as that solves all conflict situations as only one app is allowed per origin).

on the other hand, most linux users still access the filesystem, and ~ in particular, so having non user-friendly names here might be a big deal. so we might have to do what we did on Mac  (user friendly name and appending (2), (3) on conflicts)

One alternative would be to have a ~/webapps/ folder and the apps are installed in that subdirectory, but I'm not sure how I feel about it yet. Do most linux distros discourage adding folders to Home? if yes that might be a good alternative to not polute the home dir with a folder for each app.



What are you thinking for the profile dir? Inside the installDir, like on Windows?

@@ +743,5 @@
> +    let desktopINI = this.installDir.clone();
> +    desktopINI.append(this.appNameAsFilename + ".desktop");
> +
> +    let webapprtExecutable = this.installDir.clone();
> +    webapprtExecutable.append("webapprt-stub");

since this is used twice (here and in _copyPrebuiltFiles), it'd be better to define this as a member variable in _init and use it both here and in _copyPrebuiltFiles. 

Then in _copyPrebuiltFiles instead of having the string hard-coded in the copyTo call, you use .leafName  (see how the uninstaller is copied on Windows).

@@ +765,5 @@
> +        process.runAsync([], 0);
> +      }
> +    }
> +    catch (e) {
> +      throw("Error executing kbuildsycoca: " + e);

this error can be silently ignored.

is there any function in a library that we could use to call this (through js-ctypes) instead of running it? Mostly out of curiosity..
Attachment #622566 - Flags: feedback?(felipc) → feedback+
Whiteboard: [marketplace-beta-]
(In reply to Felipe Gomes (:felipe) from comment #21)
> Comment on attachment 622566 [details] [diff] [review]
> Install webapps on Linux
> 
> Review of attachment 622566 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This patch is looking great, Marco!

Thank you :)

> hmm this is an interesting question...  On one hand, the name here doesn't
> matter in the UI (as what will matter is the shortcut name), so going with
> the origin;protocol;port seems like the best option (as that solves all
> conflict situations as only one app is allowed per origin).
> 
> on the other hand, most linux users still access the filesystem, and ~ in
> particular, so having non user-friendly names here might be a big deal. so
> we might have to do what we did on Mac  (user friendly name and appending
> (2), (3) on conflicts)

The applications are installed in a hidden directory under the home directory, so probably user-friendly names aren't needed.
Anyway, it's something to think about.

> One alternative would be to have a ~/webapps/ folder and the apps are
> installed in that subdirectory, but I'm not sure how I feel about it yet. Do
> most linux distros discourage adding folders to Home? if yes that might be a
> good alternative to not polute the home dir with a folder for each app.

Well, there is a standard directory under the home that should be used for configuration files ($XDG_CONFIG_HOME, usually it is ~/.config). Mozilla applications aren't using the standard right now, but we could use it for the webapps.
I'd need to change some code (IIRC in nsAppRunner), because it assumes the profile is located in ~/.APPLICATIONNAME).

> What are you thinking for the profile dir? Inside the installDir, like on
> Windows?

Yes, everything will be in the home directory, so there's no need to have different subdirectories for them.

> @@ +765,5 @@
> > +        process.runAsync([], 0);
> > +      }
> > +    }
> > +    catch (e) {
> > +      throw("Error executing kbuildsycoca: " + e);
> 
> this error can be silently ignored.
> 
> is there any function in a library that we could use to call this (through
> js-ctypes) instead of running it? Mostly out of curiosity..

I've just read that this isn't needed anymore with the latest versions of KDE (the KDED daemon watches for .desktop files changes).
I'll test on a KDE distro to make sure that this is true.

Looks like there's an API for menu building (http://api.kde.org/4.0-api/kdelibs-apidocs/kded/html/classKBuildSycoca.html), but it is internal to the KDED daemon and used only for its modules (http://api.kde.org/4.0-api/kdelibs-apidocs/kded/html/index.html).

(In reply to Jason Smith [:jsmith] from comment #20)
> Marco - Could you create a try build for your linux patches? If the try
> build passes, I'd be more than happy to try out the linux web apps
> implementation and give you feedback.

Jason, I'll do this in the coming days. So that also smaug can use it for his work.
Priority: -- → P3
Target Milestone: --- → Firefox 15
So someone picked up on the feature disparity, even though its being worked on here. sigh. http://linux.slashdot.org/story/12/05/15/1316229/mozilla-leaves-out-linux-for-initial-web-app-support
(In reply to John Drinkwater (:beta) from comment #23)
> So someone picked up on the feature disparity, even though its being worked
> on here. sigh.
> http://linux.slashdot.org/story/12/05/15/1316229/mozilla-leaves-out-linux-
> for-initial-web-app-support

Thanks for bringing this everyone's attention.
(In reply to Marco Castelluccio from comment #26)
> There's a try build:
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mar.
> castelluccio@studenti.unina.it-02d48bf8a631/

Tried installing BarFight and Favimon on the app directory - didn't work. I got a prompt saying the following:

Error in installation: [object DOMError @ 0xa961e38 (native @ 0xa8a6020)]

In the error console, I saw the following:

Timestamp: 05/23/2012 06:02:42 PM
Error: Error installing app: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFileOutputStream.init]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: resource:///components/nsINIProcessor.js :: <TOP_LEVEL> :: line 136"  data: no]
Source File: resource:///modules/WebappsInstaller.jsm
Line: 36
(In reply to Jason Smith [:jsmith] from comment #27)
> Tried installing BarFight and Favimon on the app directory - didn't work. I
> got a prompt saying the following:
> 
> Error in installation: [object DOMError @ 0xa961e38 (native @ 0xa8a6020)]
> 
> In the error console, I saw the following:
> 
> Timestamp: 05/23/2012 06:02:42 PM
> Error: Error installing app: [Exception... "Component returned failure code:
> 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFileOutputStream.init]"  nsresult:
> "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame ::
> resource:///components/nsINIProcessor.js :: <TOP_LEVEL> :: line 136"  data:
> no]
> Source File: resource:///modules/WebappsInstaller.jsm
> Line: 36

Could you try with marketplace.mozilla.org?
I'm investigating why some apps from apps.mozillalabs.com/appdir fail installing.
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mar.castelluccio@studenti.unina.it-337cd233fbea/

Ok, the webapp that is failing, fails also on Windows, so it's probably a manifest error.

(I'll post updated try builds on the wiki page for the GSoC project)
Mozilla is getting some serious stick for not supporting Foss first but windows 

http://www.technewsworld.com/story/75164.html

Personally i love Mozilla for its Foss work , lets users decide & cross platform
magnumarchonbasileus, 

Thanks for you interest in this issue.

Please read the bug and you'll see that it's work in progress and currently in the latest try-build Marco has linked, marketplace and apps work on Linux.

Also, this bug is for commenting the work in progress, if you want to discuss about the issue, please use the mailing lists:

https://groups.google.com/forum/?fromgroups#!topic/mozilla.marketing/byBTV1Cg0Vk

Thanks.
Marco, let us know if you need more testing with the latest try-build or if you need help with other things like uninstallation or about:apps panel.
Tested this on Ubuntu 11.1 as well - didn't get errors on install this time, but nothing appeared to change on my machine - where did my apps get installed?
(In reply to Jason Smith [:jsmith] from comment #33)
> Tested this on Ubuntu 11.1 as well - didn't get errors on install this time,
> but nothing appeared to change on my machine - where did my apps get
> installed?

You have to search for it using the Unity panel dashboard. This is a bit complicated and for that reason an about:apps panel from inside Firefox is needed for most Linux flavours.
(In reply to Rubén Martín [:Nukeador] from comment #34)
> (In reply to Jason Smith [:jsmith] from comment #33)
> > Tested this on Ubuntu 11.1 as well - didn't get errors on install this time,
> > but nothing appeared to change on my machine - where did my apps get
> > installed?
> 
> You have to search for it using the Unity panel dashboard. This is a bit
> complicated and for that reason an about:apps panel from inside Firefox is
> needed for most Linux flavours.

That problem will likely be solved down the line by some of the internal access Firefox will have to the native apps in places such as new tab and the awesome bar integration for web apps (both are planned features). I would suggest finding a way to not rely on that implementation though for now (i.e. find a place to install the apps that a user will easily discover).
(In reply to Jason Smith [:jsmith] from comment #35)
> That problem will likely be solved down the line by some of the internal
> access Firefox will have to the native apps in places such as new tab and
> the awesome bar integration for web apps (both are planned features). I
> would suggest finding a way to not rely on that implementation though for
> now (i.e. find a place to install the apps that a user will easily discover).

The applications are installed in the standard places. When you install an application through Synaptic, for example, you get the application in the dash. The Ubuntu Software Center installs applications in the dash and in the Unity launcher (that is the most discoverable place), but uses a Unity-only API to do so.
I think the best solution, however, is bug 747283 for Linux.
Jason/Marco,

  If you want to go in this way we will probably have incompatibility with non-Ubuntu distros.

  Looking at Opera browser widget when you add a new widget it goes direct to the "menu" (like "Start" menu from windows) and it works for ubuntu unity, gnome2, kde environments.

  May the installed webapps could be displayed in the menu following the Freedesktop standard? (http://standards.freedesktop.org/menu-spec/1.1/)

thanks,
Saulo
I second Saulo. Following the freedesktop standard is the way to go. I 'll glad to help if needed :)

Thanks!
We are using the freedesktop standard.
Depends on: 759906
Attached patch Install webapps on Linux (obsolete) — Splinter Review
Just an updated patch.
Attachment #622566 - Attachment is obsolete: true
Blocks: 760748
Blocks: 760750
No longer depends on: 759906
Comment on attachment 629422 [details] [diff] [review]
Install webapps on Linux

I've tested this patch on my gnome2 system, and it seems to work wonderfully! I can install apps, they appear in my start menu, and the webapprt (from bug 745018) launches the app.

Felipe, are you the right person to sign off on landing this? I'll gladly sr (not that I think that's needed, but still) if this looks good to you.

Marco, do you know anything else that needs to happen here before we land this? I'm sure there's more tweaks we could make etc, but I'd love to have something in the tree here, and this seems to work just fine as a first cut.
Attachment #629422 - Flags: review?(felipc)
Comment on attachment 629422 [details] [diff] [review]
Install webapps on Linux

Review of attachment 629422 [details] [diff] [review]:
-----------------------------------------------------------------

Hi Marco, thanks for submitting this patch. Is there any reason you didn't request review on it yet, or is it just because you were waiting on some of the follow-ups bugs?

There are only a few changes to be made, and you can post a patch with those changes and carry forward the r+.

If you manage to update it soon that's great, but if you don't i'll make these changes myself to land this in time before the branching on tuesday.

(or if there is any reason we shouldn't land this + bug 745018 let me know. FWIW it's totally fine for me to leave the UI uninstall/discovery as follow-ups that do not hold the initial landing)

::: browser/modules/WebappsInstaller.jsm
@@ +654,5 @@
> +    this.appNameAsFilename = this.appNameAsFilename.replace(filenameRE, "");
> +    this.appNameAsFilename = this.appNameAsFilename.toLowerCase();
> +
> +    // TODO: DECIDE INSTALL AND CONFIG DIR (NOW THEY ARE THE SAME)
> +    // TODO: NEED UNIQUE NAME

Need to remove these TODO comments.  We haven't decided what would be the best install dir name, but since it's gonna be an invisible folder, and install and config will be the same, I'm leaning towards using the same scheme as Windows (e.g. ".http;www.example.com") (see bug 758044), because this gets rid of the unique id problem.

What do you think about making this change, Marco?

@@ +673,5 @@
> +                          .createInstance(Ci.nsILocalFile);
> +      this.desktopINI.initWithPath(xdg_data_home_env);
> +    }
> +    else {
> +      this.desktopINI = Services.dirsvc.get("Home", Ci.nsIFile).QueryInterface(Ci.nsILocalFile);

small note: nsILocalFile is not needed anymore due to bug 682360 being fixed, using nsIFile is enough. But there are other usages in this file that we can change that all at once if you don't get to this change before

@@ +679,5 @@
> +      this.desktopINI.append("share");
> +    }
> +
> +    // XXX: DEPENDS ON BUG 744190
> +    //this.desktopINI = Services.dirsvc.get("XDGDataHome", Ci.nsIFile).QueryInterface(Ci.nsILocalFile);

remove this comment and the commented line

@@ +702,5 @@
> +
> +  _removeInstallation: function() {
> +    try {
> +      if (this.installDir.exists())
> +        this.installDir.remove(true);

yeah, unless we make the name scheme change, we'll have to take care of this in a more detailed way, otherwise a properly named app might remove some existing content from the home folder.

this is not a problem on Windows because it uses the origin as the name, and not on Mac either because the installDir is the temp folder.

@@ +740,5 @@
> +    writer.setString("WebappRT", "InstallDir", this.processFolder.path);
> +    writer.writeFile();
> +
> +    // $XDG_DATA_HOME/applications/<webappname>.desktop
> +    this.desktopINI.create(Ci.nsIFile.NORMAL_FILE_TYPE, 0755);

does the actual name of this file matters, or the only thing that matters are the contents inside it? (since there's a "Name" entry inside it I'm guessing that's what is displayed in the UI)

If it doesn't matter, please use the easy-to-use createUnique here to avoid overriding other shortcuts

If it matters then we can use the getAvailableFile function defined in the helper functions below to have a better looking unique name

@@ +764,5 @@
> +      }
> +    }
> +    catch (e) {
> +      throw("Error executing kbuildsycoca: " + e);
> +    }*/

remove commented out block

@@ +819,5 @@
>    let converter = Cc["@mozilla.org/intl/scriptableunicodeconverter"]
>                      .createInstance(Ci.nsIScriptableUnicodeConverter);
>    converter.charset = "UTF-8";
>    let istream = converter.convertToInputStream(aData);
> +  NetUtil.asyncCopy(istream, ostream, function(x) { aCallback(x) });

is this change necessary?
Attachment #629422 - Flags: review?(felipc) → review+
FYI to Felipe - When the two linux web apps bugs land and switch the bugs to "resolved fixed," feel free to resolve bug 706634 as well saying that we no longer need to disable linux support in the install doorhanger (resolved invalid).
(In reply to Felipe Gomes (:felipe) from comment #42)
> If you manage to update it soon that's great, but if you don't i'll make
> these changes myself to land this in time before the branching on tuesday.

Felipe, note that the merge will be done on Monday this time (changed from the normal schedule this time only), so that means this needs to land on Sunday if its to be guaranteed to make the merge.

I'll gladly do the landing of this if needed, let me know if you want some help with that!
(In reply to Felipe Gomes (:felipe) from comment #42)
> Hi Marco, thanks for submitting this patch. Is there any reason you didn't
> request review on it yet, or is it just because you were waiting on some of
> the follow-ups bugs?
> 
> There are only a few changes to be made, and you can post a patch with those
> changes and carry forward the r+.
> 
> If you manage to update it soon that's great, but if you don't i'll make
> these changes myself to land this in time before the branching on tuesday.
> 
> (or if there is any reason we shouldn't land this + bug 745018 let me know.
> FWIW it's totally fine for me to leave the UI uninstall/discovery as
> follow-ups that do not hold the initial landing)

Perfect, I just didn't know if we could land this without the follow-ups.
It would be better if we can land also bug 702363 for Firefox 15, so that we have a basic way to remove applications.


> ::: browser/modules/WebappsInstaller.jsm
> @@ +654,5 @@
> > +    this.appNameAsFilename = this.appNameAsFilename.replace(filenameRE, "");
> > +    this.appNameAsFilename = this.appNameAsFilename.toLowerCase();
> > +
> > +    // TODO: DECIDE INSTALL AND CONFIG DIR (NOW THEY ARE THE SAME)
> > +    // TODO: NEED UNIQUE NAME
> 
> Need to remove these TODO comments.  We haven't decided what would be the
> best install dir name, but since it's gonna be an invisible folder, and
> install and config will be the same, I'm leaning towards using the same
> scheme as Windows (e.g. ".http;www.example.com") (see bug 758044), because
> this gets rid of the unique id problem.
> 
> What do you think about making this change, Marco?

I've modified the code to use the same scheme as Windows.

> @@ +740,5 @@
> > +    writer.setString("WebappRT", "InstallDir", this.processFolder.path);
> > +    writer.writeFile();
> > +
> > +    // $XDG_DATA_HOME/applications/<webappname>.desktop
> > +    this.desktopINI.create(Ci.nsIFile.NORMAL_FILE_TYPE, 0755);
> 
> does the actual name of this file matters, or the only thing that matters
> are the contents inside it? (since there's a "Name" entry inside it I'm
> guessing that's what is displayed in the UI)
> 
> If it doesn't matter, please use the easy-to-use createUnique here to avoid
> overriding other shortcuts
> 
> If it matters then we can use the getAvailableFile function defined in the
> helper functions below to have a better looking unique name

I've modified the code to use the same scheme for the installation directory and the desktop entry file. The name of this file should start with a vendor name (it's not an obligation, but it's better if an user wants to handle the desktop files with the freedesktop tools: http://portland.freedesktop.org/xdg-utils-1.0/xdg-desktop-menu.html), I've added "owa" as vendor name, let me know if you prefer another name (like "openwebapps" or "mozilla").

I've also removed all the unnecessary comments.

I'm not carrying r+ forward because of the changes in the desktop entry file.
Attachment #629422 - Attachment is obsolete: true
Attachment #629655 - Flags: review?(felipc)
Attachment #629655 - Flags: checkin?(felipc)
(In reply to Marco Castelluccio from comment #45)
> Perfect, I just didn't know if we could land this without the follow-ups.
> It would be better if we can land also bug 702363 for Firefox 15, so that we
> have a basic way to remove applications.

Landing bug 702363 would not solve the problem - the delete functionality provided there would delete from the registry, not natively uninstall the application. We currently do not support uninstalling apps natively at all via the mozapps API - although we are looking into this (I'm trying to get a discussion setup on Tuesday to talk about how we differentiate install vs. acquire in the mozapps API). More information to come on how to approach this.
Comment on attachment 629655 [details] [diff] [review]
Install webapps on Linux

> I've modified the code to use the same scheme for the installation directory
> and the desktop entry file. The name of this file should start with a vendor
> name (it's not an obligation, but it's better if an user wants to handle the
> desktop files with the freedesktop tools:
> http://portland.freedesktop.org/xdg-utils-1.0/xdg-desktop-menu.html), I've
> added "owa" as vendor name, let me know if you prefer another name (like
> "openwebapps" or "mozilla").

That sounds good.

Johnny, I'll land the two bugs soon.
Attachment #629655 - Flags: review?(felipc) → review+
Attachment #629655 - Flags: checkin?(felipc) → checkin+
https://hg.mozilla.org/mozilla-central/rev/b9de12c3aeda
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [qa+]
For testing - I'll do a quick check for verifying that this has landed for this bug and bug 745018 by doing proof of concept testing for Ubuntu 11. Then, I'll throw up some blog posts and notifications to try to crowd source some of the testing here. For formalized test cases, see the following doc for test cases currently under development:

https://docs.google.com/spreadsheet/ccc?key=0AiZoGR-iOAlUdDdfMHo5aTI2WjVIeWxnNWxvV0ZVOWc

And formalized ones are here if you filter by apps and Desktop Firefox 15:

https://moztrap.mozilla.org/manage/cases/

Feel free to enhance these test cases with your own ideas for general testing areas and test cases specific to the linux implementation. Ping me if you would like to help testing this feature and I'll get you access to the doc and moztrap. Marco - Do you need access to that doc and MozTrap? Anybody else interested in helping the testing here?
Verified that this indeed has landed on inbound. I did very bare bones testing to ensure that the feature has indeed landed (e.g. install apps, launch apps, use apps) using smoke tests from comment 50. At the smoke test level, the only major issue identified was bug 761496, although we can track this in a separate bug (I usually mark these verified if I confirm the implementation has landed and a proof of concept works).

When the nightly build containing the patch is ready, I'll throw up some blog posts and advertising to encourage testers to start hammering this build. Note that the testing done here is bare bones, not extensive, so there's still more testing to be done here.

An open question I think that needs to be addressed from a UX perspective - How would a linux user know how to remove their web apps from their machine? I didn't manage to find the location of where the app was installed after doing some searching, although I might be looking in the wrong spot. I'm fine with just relying on the user to do a direct deletion of the app, but we need to make sure that the user can easily find and remove the app if they want it removed. Another follow-up thing to think about is integration with existing services - such as the Ubuntu Software Center. Is is something to consider?

These are just ideas - Feel free to think about this more. But overall, nice job on this.
Status: RESOLVED → VERIFIED
Whiteboard: [qa+] → [qa!]
Blocks: 761806
blocking-kilimanjaro: --- → ?
Linux is not a blocker for k9o for desktop web runtime. See:

https://wiki.mozilla.org/Kilimanjaro/ProductDraft#You_will_be_able_to_install_and_use_your_apps_across_phones_and_PCs_where_WebRT_is_available

It's a P3. Although this has already landed and is verified, so it's good to be used now on nightly anyways.
blocking-kilimanjaro: ? → ---
Depends on: 763183
I've added Linux to the "Install a Free Native Application from Mozilla Marketplace" test case.
Flags: in-moztrap+
QA Contact: jsmith
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.