Closed Bug 1078797 Opened 10 years ago Closed 10 years ago

Editable apps don't reload after reinstall

Categories

(DevTools Graveyard :: WebIDE, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 35

People

(Reporter: jryans, Assigned: jryans)

References

Details

Attachments

(1 file, 1 obsolete file)

Can reproduce on 2.2 simulator.  Paul was using a 2.1 device.

STR:
- local app, certified or privileged
- push app
- app shows up
- change code
- try to reload, app is uploaded, but app is not reloaded
- in console, type window.location.reload()
- changes appear
Summary: Editable apps don't reload → Editable apps don't reload after reinstall
There's currently a race after reinstalling an app because the "appInstall" event signals completion of install, but then we make a request to "listRunningApps" in parallel to check if the new app is running.

I'm working around this by remembering whether the app was already running instead.

Try: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=37a4048b4433
Attachment #8500715 - Flags: review?(poirot.alex)
Comment on attachment 8500715 [details] [diff] [review]
Check running state before reinstalling app

Review of attachment 8500715 [details] [diff] [review]:
-----------------------------------------------------------------

Is there a race between two request over RDP and responses end up being mixed?
app.running should still be true, even during the install request,
unless we receive appClose event in the meantime.
Attachment #8500715 - Flags: review?(poirot.alex) → review+
(In reply to Alexandre Poirot [:ochameau] from comment #3)
> Comment on attachment 8500715 [details] [diff] [review]
> Check running state before reinstalling app
> 
> Review of attachment 8500715 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Is there a race between two request over RDP and responses end up being
> mixed?
> app.running should still be true, even during the install request,
> unless we receive appClose event in the meantime.

The race was created by |_clientListener|.  It deletes the app on re-install, and re-lists running apps, but never waits for an answer.

It's always better to just fix a race of course, so now I'm doing that in this new version.

Try: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=a546dfe90444
Attachment #8500715 - Attachment is obsolete: true
Attachment #8501264 - Flags: review?(poirot.alex)
Comment on attachment 8501264 [details] [diff] [review]
Wait for running state before emitting install

Review of attachment 8501264 [details] [diff] [review]:
-----------------------------------------------------------------

Oh great, thanks for figuring this out!!
Attachment #8501264 - Flags: review?(poirot.alex) → review+
https://hg.mozilla.org/mozilla-central/rev/9637293b166a
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 35
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.