Last Comment Bug 746629 - Installing an Application on Windows reports DOMError - missing uninstaller from package
: Installing an Application on Windows reports DOMError - missing uninstaller f...
Status: VERIFIED FIXED
[marketplace-beta+]
: regression
Product: Firefox Graveyard
Classification: Graveyard
Component: Web Apps (show other bugs)
: unspecified
: All All
: -- blocker
: Firefox 14
Assigned To: Myk Melez [:myk] [@mykmelez]
: Jason Smith [:jsmith]
Mentors:
: 746647 (view as bug list)
Depends on:
Blocks: 757320
  Show dependency treegraph
 
Reported: 2012-04-18 09:55 PDT by Jason Smith [:jsmith]
Modified: 2016-02-04 15:00 PST (History)
13 users (show)
jsmith: in‑moztrap+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch v1-win: fixes problem on Windows (499 bytes, patch)
2012-04-19 14:49 PDT, Myk Melez [:myk] [@mykmelez]
felipc: review+
myk: checkin+
Details | Diff | Splinter Review

Description Jason Smith [:jsmith] 2012-04-18 09:55:22 PDT
Steps:

1. Install the latest Nightly
2. Go to apps.mozillalabs.com/appdir
3. Install an application

Expected:

The door hanger should appear prompting the user to install an application.

Actual:

A DOMError is thrown. This error also occurs if you install an application from the marketplace.
Comment 1 Jason Smith [:jsmith] 2012-04-18 10:07:38 PDT
Update - This issue happens after the doorhanger, should say:

Steps:

1. Install the latest Nightly
2. Go to apps.mozillalabs.com/appdir
3. Install an application
4. Door-hanger appears, click Install

Expected:

The application should be installed to the user's FF profile. Going to myapps.mozillalabs.com with the whitelisting config set should show the application installed.

Actual:

A DOMError is thrown. This error also occurs if you install an application from the marketplace.
Comment 2 Jason Smith [:jsmith] 2012-04-18 10:24:08 PDT
Error also occurs on Linux (Ubuntu 9.04 32-bit). Sounds like a regression.
Comment 3 Jason Smith [:jsmith] 2012-04-18 10:38:43 PDT
*** Bug 746647 has been marked as a duplicate of this bug. ***
Comment 4 [:fabrice] Fabrice Desré 2012-04-18 11:26:15 PDT
Having a regression range would help.
Comment 5 Jason Smith [:jsmith] 2012-04-18 11:27:06 PDT
(In reply to Fabrice Desré [:fabrice] from comment #4)
> Having a regression range would help.

I know it was working on yesterday's nightly, it's broken on today's nightly.
Comment 6 JStagner@Mozilla.com 2012-04-18 11:28:01 PDT
I can confirm - it still works on yesterday's nightly but not on today's.
Comment 7 Jason Smith [:jsmith] 2012-04-18 11:29:35 PDT
The issue likely involves one of the patches we submitted to mozilla central yesterday. Something that happens after clicking "Install" in the door hanger in the code.
Comment 8 Myk Melez [:myk] [@mykmelez] 2012-04-18 11:33:14 PDT
I think I see the typo that is causing this problem.  Will confirm and then submit patch...
Comment 9 Myk Melez [:myk] [@mykmelez] 2012-04-18 12:00:00 PDT
Erm, no, not a typo.  Rather, seems to be caused by this in WebappsInstaller.jsm:

    let WebappsInstaller = {
      /**
       * Creates a native installation of the web app in the OS
       *
       * @param aData the manifest data provided by the web app
       *
       * @returns bool true on success, false if an error was thrown
       */
      install: function(aData) {
    
    #ifdef XP_MACOSX
        let shell = new MacNativeApp(aData);
    #else
        return false;
    #endif


Felipe: this looks intentional, but the original behavior should continue to occur on Windows and Linux, at least until we land better behavior.
Comment 10 Jason Smith [:jsmith] 2012-04-18 12:03:34 PDT
(In reply to Myk Melez [:myk] [@mykmelez] from comment #9)
> Erm, no, not a typo.  Rather, seems to be caused by this in
> WebappsInstaller.jsm:
> 
>     let WebappsInstaller = {
>       /**
>        * Creates a native installation of the web app in the OS
>        *
>        * @param aData the manifest data provided by the web app
>        *
>        * @returns bool true on success, false if an error was thrown
>        */
>       install: function(aData) {
>     
>     #ifdef XP_MACOSX
>         let shell = new MacNativeApp(aData);
>     #else
>         return false;
>     #endif
> 
> 
> Felipe: this looks intentional, but the original behavior should continue to
> occur on Windows and Linux, at least until we land better behavior.

Right makes sense to do that. We'll want to make sure the fallback behavior still works correctly, especially if linux support comes down the line by Marco.
Comment 11 Marco Castelluccio [:marco] 2012-04-18 13:41:23 PDT
On Linux it is a different issue that I probably have to investigate.
For Linux support I obviously had to modify that code like this:
> #ifdef XP_WIN
>     let shell = new WinNativeApp(aData);
> #elifdef XP_MACOSX
>     let shell = new MacNativeApp(aData);
> #elifdef XP_UNIX
>     let shell = new LinuxNativeApp(aData);
> #else
>     return false;
> #endif
Comment 12 JStagner@Mozilla.com 2012-04-18 13:58:07 PDT
Installs still work on Ubuntu Linux for me with today's Nightly.
Comment 13 Jason Smith [:jsmith] 2012-04-18 15:33:46 PDT
An important note - If the OS is not supported, then the correct behavior I believe should follow in line with the HTML 5 shim. In other words, the behavior should be the same behavior you see in Chrome, Safari, etc. Jen should confirm here though on what the behavior should be.
Comment 14 JStagner@Mozilla.com 2012-04-18 15:38:16 PDT
On Linux (Ubuntu) Installing an App seems to work into the apps dashboard. There is no native install which is as expected. Feel free to email me if there any specific data I can share.
Comment 15 Jason Smith [:jsmith] 2012-04-18 16:06:03 PDT
(In reply to JStagner@Mozilla.com from comment #14)
> On Linux (Ubuntu) Installing an App seems to work into the apps dashboard.
> There is no native install which is as expected. Feel free to email me if
> there any specific data I can share.

Hmm okay. What happened when you installed an application on linux? Did the doorhanger appear? Did a HTML 5 dialog appear?

On the next mozilla in-bound or nightly build, I'll go retest. I believe Felipe stated the fix is in for windows. Flagging as qawanted.
Comment 16 Jason Smith [:jsmith] 2012-04-19 09:54:51 PDT
FYI - Still seeing this behavior on today's nightly build on Windows 7 64-bit.
Comment 17 Jason Smith [:jsmith] 2012-04-19 10:36:49 PDT
Also still occurring on the mozilla in-bound build on win 7 64-bit.
Comment 18 JStagner@Mozilla.com 2012-04-19 12:04:51 PDT
(In reply to Jason Smith from comment #15)
> (In reply to JStagner@Mozilla.com from comment #14)
> > On Linux (Ubuntu) Installing an App seems to work into the apps dashboard.
> > There is no native install which is as expected. Feel free to email me if
> > there any specific data I can share.
> 
> Hmm okay. What happened when you installed an application on linux? Did the
> doorhanger appear? Did a HTML 5 dialog appear?
> 
> On the next mozilla in-bound or nightly build, I'll go retest. I believe
> Felipe stated the fix is in for windows. Flagging as qawanted.

Jason - please disregard - apps do NOT install on current Linux nightly.
Comment 19 Ragavan S [:rags] 2012-04-19 13:59:58 PDT
Does this work against the marketplace-dev site? Just want to make sure the issue is not on the appdir side of the house.
Comment 20 Jason Smith [:jsmith] 2012-04-19 14:02:20 PDT
Removing qawanted given that we know this is still happening on the mozilla in-bound build.

(In reply to Ragavan S [:rags] from comment #19)
> Does this work against the marketplace-dev site? Just want to make sure the
> issue is not on the appdir side of the house.

Nope. I get an error saying "App installation not allowed."
Comment 21 Myk Melez [:myk] [@mykmelez] 2012-04-19 14:49:18 PDT
Created attachment 616756 [details] [diff] [review]
patch v1-win: fixes problem on Windows

The problem on Windows is simple: the installer relies on the presence of webapp-uninstaller.exe, which isn't listed in the installer's package manifest, so it isn't being packaged into the build.  Here's the obvious fix.
Comment 22 Myk Melez [:myk] [@mykmelez] 2012-04-19 15:03:48 PDT
Comment on attachment 616756 [details] [diff] [review]
patch v1-win: fixes problem on Windows

I landed this on mozilla-central to make sure it would make it into tomorrow's nightly build:

https://tbpl.mozilla.org/?rev=900945f9909a

Leaving this bug open pending resolution of the problem on Linux.
Comment 23 :Felipe Gomes (needinfo me!) 2012-04-19 15:34:12 PDT
Changing this bug to better reflect the problem it fixed. The problem on Linux (if it exists) would be different, so we can do it in a separate bug.

Note You need to log in before you can comment on or make changes to this bug.