Closed
Bug 747409
Opened 12 years ago
Closed 12 years ago
Cannot launch multiple different native applications - All apps launched re-launch the 1st app launched
Categories
(Firefox Graveyard :: Web Apps, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
Firefox 14
People
(Reporter: jsmith, Assigned: TimAbraldes)
Details
(Whiteboard: [marketplace-beta+])
Attachments
(1 file, 1 obsolete file)
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•12 years ago
|
Whiteboard: [marketplace-beta?]
Assignee | ||
Comment 1•12 years ago
|
||
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 | ||
Updated•12 years ago
|
Assignee: nobody → tabraldes
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•12 years ago
|
||
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.
Assignee | ||
Comment 3•12 years ago
|
||
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 4•12 years ago
|
||
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+
Assignee | ||
Comment 5•12 years ago
|
||
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+
Assignee | ||
Updated•12 years ago
|
Target Milestone: --- → Firefox 14
Reporter | ||
Updated•12 years ago
|
Whiteboard: [marketplace-beta?] → [marketplace-beta]
Reporter | ||
Updated•12 years ago
|
Whiteboard: [marketplace-beta] → [marketplace-beta+]
Comment 6•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/4c1aa39b85a9
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•12 years ago
|
Status: RESOLVED → VERIFIED
Reporter | ||
Updated•12 years ago
|
Flags: in-moztrap?(jsmith)
Reporter | ||
Updated•12 years ago
|
QA Contact: jsmith
Reporter | ||
Updated•12 years ago
|
Flags: in-moztrap?(jsmith) → in-moztrap+
Updated•8 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•