Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Cannot launch multiple different native applications - All apps launched re-launch the 1st app launched

VERIFIED FIXED in Firefox 14

Status

Firefox Graveyard
Web Apps
--
critical
VERIFIED FIXED
5 years ago
2 years ago

People

(Reporter: jsmith, Assigned: TimAbraldes)

Tracking

unspecified
Firefox 14
x86_64
Windows 7
Bug Flags:
in-moztrap +

Details

(Whiteboard: [marketplace-beta+])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Steps:

1. Go to https://apps.mozillalabs.com/appdir/
2. Install 2 different applications
3. Launch each application from the desktop shortcut

Expected:

Each application should start-up separately and be different. For example, if I installed BarFight and Dave's Galaxy, launching both of them should start BarFight and Dave's Galaxy in separate windows.

Actual:

Launching any application after launching the first application will re-launch the 1st application. For example, if I launch BarFight, the BarFight application starts up. If I then launch Dave's Galaxy, another BarFight application starts up.
(Reporter)

Updated

5 years ago
Whiteboard: [marketplace-beta?]
After the stub calls XRE_main, code is hit that checks whether an instance of the app is already running.  On Windows, it checks for previous instances of the app by looking for a specifically-named window.

This is where the name of the window is built:
  https://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsNativeAppSupportWin.cpp#494

Note that the name of the window searched is "gAppData->name" + "MessageWindow".  The app data for our apps used to contain the name of the app, but now every app has the value "Webapp Runtime" as its "gAppData->name" value.
Assignee: nobody → tabraldes
Status: NEW → ASSIGNED
Created attachment 617127 [details] [diff] [review]
Patch v1 - Sets the name of the app in the gAppData structure

The attached patch fixes the issue in my local testing.  However, this won't work if two apps happen to have the same name.  Additionally, this patch doesn't check that the name contains only ASCII characters, which is a requirement according to this comment: https://mxr.mozilla.org/mozilla-central/source/xpcom/build/nsXREAppData.h?rev=a771e4924188#76

To fix the first issue, we could consider using the profile instead of the app name.  These are guaranteed to be unique (the profile dir is the same as the app's install dir).  I'm not yet sure how to approach the second issue.
Created attachment 617153 [details] [diff] [review]
Patch v2 - Set the "name" field of the nsXREAppData to the name of the profile dir (equivalent to the name of the webapp's install dir)

This patch sets the "name" of the nsXREAppData struct to be the name of the profile dir of the webapp (which is also the install dir of the app).

No two webapps will have the same value for this.  Also, this value is based on scheme (always ASCII?), port (always ASCII since it's a number), and domain (which, if we're not already, we will soon be using the ASCII version of).

One outstanding issue: What happens when the profile dir has a name that is really long?  The code that checks for existing windows uses this function, which uses a buffer of size 128 for the app name: https://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsNativeAppSupportWin.cpp?rev=e1bef8037d36#494
Attachment #617127 - Attachment is obsolete: true
Attachment #617153 - Flags: review?(myk)
Comment on attachment 617153 [details] [diff] [review]
Patch v2 - Set the "name" field of the nsXREAppData to the name of the profile dir (equivalent to the name of the webapp's install dir)

(In reply to Tim Abraldes from comment #3)
> This patch sets the "name" of the nsXREAppData struct to be the name of the
> profile dir of the webapp (which is also the install dir of the app).

This seems like a reasonable enough solution, although I'm worried about unintended side-effects.  But in any case it's an improvement over the current situation.  r=myk


> One outstanding issue: What happens when the profile dir has a name that is
> really long?  The code that checks for existing windows uses this function,
> which uses a buffer of size 128 for the app name:
> https://mxr.mozilla.org/mozilla-central/source/toolkit/xre/
> nsNativeAppSupportWin.cpp?rev=e1bef8037d36#494

The DNS spec limits domain names to 255 characters.  Given the schemes we accept (just http and https?) and the maximum size of a port number (5), we can determine the largest possible size of one of these identifying strings.  So we could update nsNativeAppSupportWin to use a large enough buffer.  But I'd want feedback from a toolkit peer on that change.
Attachment #617153 - Flags: review?(myk) → review+
(Reporter)

Updated

5 years ago
Blocks: 731054
Comment on attachment 617153 [details] [diff] [review]
Patch v2 - Set the "name" field of the nsXREAppData to the name of the profile dir (equivalent to the name of the webapp's install dir)

https://hg.mozilla.org/integration/mozilla-inbound/rev/4c1aa39b85a9
Attachment #617153 - Flags: checkin+
Target Milestone: --- → Firefox 14
(Reporter)

Updated

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

Updated

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

Comment 6

5 years ago
https://hg.mozilla.org/mozilla-central/rev/4c1aa39b85a9
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Reporter)

Updated

5 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Updated

5 years ago
No longer blocks: 731054
(Reporter)

Updated

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

Updated

5 years ago
QA Contact: jsmith
(Reporter)

Updated

5 years ago
Flags: in-moztrap?(jsmith) → in-moztrap+
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.