Closed Bug 777971 Opened 12 years ago Closed 12 years ago

window.navigator.mozApps.getInstalled() is prematurely reporting the app as installed

Categories

(Core Graveyard :: DOM: Apps, defect)

defect
Not set
normal

Tracking

(blocking-basecamp:-, firefox16 affected)

RESOLVED INCOMPLETE
blocking-basecamp -
Tracking Status
firefox16 --- affected

People

(Reporter: krupa.mozbugs, Unassigned)

References

Details

steps to reproduce: 1. Load https://marketplace.mozilla.org/en-US/app/galactians2/?src=mkt-ss 2. Install the app 3. Launch the app observed behavior: Looks like window.navigator.mozApps.getInstalled() is prematurely reporting that the app as installed. So the install button on Marketplace changes state to "Launch" but clicking on it doesn't launch the app as it is still installing.
Marking as a basecamp blocker since we plan to support packaged apps for b2g.
blocking-basecamp: --- → ?
(In reply to krupa raj 82[:krupa] from comment #1) > Marking as a basecamp blocker since we plan to support packaged apps for b2g. Wrong bug. This bug blocks basecamp since we want to allow launching an installed app from within the Marketplace app on our b2g phones.
I agree, this should be a blocker as it prevents users from launching an app that they've just purchased/installed from the Marketplace.
Just like justifying a ? or + please explain the discussion when you set to -. :)
(In reply to Wil Clouser [:clouserw] from comment #4) > Just like justifying a ? or + please explain the discussion when you set to > -. :) I know one of the reasons was cause the dependent bug (bug 710062) was not a blocker for basecamp. Jonas may be able to provide more context if needed.
Being installed or not isn't actually a binary state, but a tri-state: Not installed, installing, installed. We are already exposing state on the App object which indicates if we're in the installing vs. installed state. So the store should be able to use that to determine what UI to show.
(In reply to Jonas Sicking (:sicking) from comment #6) > Being installed or not isn't actually a binary state, but a tri-state: Not > installed, installing, installed. > > We are already exposing state on the App object which indicates if we're in > the installing vs. installed state. So the store should be able to use that > to determine what UI to show. So is this a worksforme then?
cvan adjusted the code to work with this, we'll land and see if it fixes stuff. thanks.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
See bug 790558 comment 0. When an app is first installed, it's .installState is "pending". This is the state it's in until we have downloaded the full package or appcache for the app. Once the download has been finished, the "ondownloadapplied" event will fire and the .installState will switch to "installed". If the app isn't packaged and doesn't have an appcache, the .installState is "installed" as soon as the onsuccess event from install/installPackage fires. It seems like the marketplace code you are pointing to isn't updated to use this new API. Which isn't surprising given that the API is brand new.
So I think this is effectively a "marketplace needs to update to new API" bug. Do you want a new bug filed on that? And then mark this one as WORKSFORME?
(In reply to Jonas Sicking (:sicking) from comment #11) > So I think this is effectively a "marketplace needs to update to new API" > bug. > > Do you want a new bug filed on that? And then mark this one as WORKSFORME? Yes please. Thanks
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.