The default bug view has changed. See this FAQ.

Installing an Application on Windows reports DOMError - missing uninstaller from package

VERIFIED FIXED in Firefox 14

Status

Firefox Graveyard
Web Apps
--
blocker
VERIFIED FIXED
5 years ago
a year ago

People

(Reporter: jsmith, Assigned: myk)

Tracking

({regression})

unspecified
Firefox 14
regression
Bug Flags:
in-moztrap +

Details

(Whiteboard: [marketplace-beta+])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
Keywords: regression
(Reporter)

Comment 1

5 years ago
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.
(Reporter)

Updated

5 years ago
Whiteboard: [marketplace-beta]
(Reporter)

Comment 2

5 years ago
Error also occurs on Linux (Ubuntu 9.04 32-bit). Sounds like a regression.
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: Installing an Application on Windows Always Reports DOMError - Cannot install to FF profile → Installing an Application on Windows/Linux Always Reports DOMError - Cannot install to FF profile
(Reporter)

Updated

5 years ago
Duplicate of this bug: 746647
Having a regression range would help.
(Reporter)

Comment 5

5 years ago
(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

5 years ago
I can confirm - it still works on yesterday's nightly but not on today's.
(Reporter)

Comment 7

5 years ago
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.
(Assignee)

Comment 8

5 years ago
I think I see the typo that is causing this problem.  Will confirm and then submit patch...
Assignee: nobody → myk
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 14
(Assignee)

Comment 9

5 years ago
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.
(Reporter)

Comment 10

5 years ago
(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.
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
Installs still work on Ubuntu Linux for me with today's Nightly.
(Reporter)

Comment 13

5 years ago
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.
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.
(Reporter)

Comment 15

5 years ago
(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.
(Reporter)

Updated

5 years ago
Keywords: qawanted
(Reporter)

Comment 16

5 years ago
FYI - Still seeing this behavior on today's nightly build on Windows 7 64-bit.
(Reporter)

Updated

5 years ago
tracking-firefox14: --- → ?
(Reporter)

Updated

5 years ago
status-firefox14: --- → affected
(Reporter)

Comment 17

5 years ago
Also still occurring on the mozilla in-bound build on win 7 64-bit.
(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

5 years ago
Does this work against the marketplace-dev site? Just want to make sure the issue is not on the appdir side of the house.
(Reporter)

Comment 20

5 years ago
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."
Keywords: qawanted
(Assignee)

Comment 21

5 years ago
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.
Attachment #616756 - Flags: review?(felipc)
Attachment #616756 - Flags: review?(felipc) → review+
(Assignee)

Comment 22

5 years ago
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.
Attachment #616756 - Flags: checkin+
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Summary: Installing an Application on Windows/Linux Always Reports DOMError - Cannot install to FF profile → Installing an Application on Windows reports DOMError - missing uninstaller from package

Updated

5 years ago
status-firefox14: affected → ---
(Reporter)

Updated

5 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Updated

5 years ago
Whiteboard: [marketplace-beta] → [marketplace-beta+]

Updated

5 years ago
tracking-firefox14: ? → -
(Reporter)

Updated

5 years ago
Flags: in-moztrap?(jsmith)
Blocks: 757320
(Reporter)

Updated

5 years ago
Flags: in-moztrap?(jsmith) → in-moztrap+
(Reporter)

Updated

5 years ago
QA Contact: jsmith
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.