Closed Bug 988062 Opened 6 years ago Closed 4 years ago

app isn't updated after changing resource and restarting app

Categories

(Firefox Graveyard :: Webapp Runtime, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: myk, Unassigned)

References

Details

Attachments

(2 files)

After making a change to a resource in a hosted app, restarting the app doesn't cause the runtime to load the updated resource.  Perhaps we're underaggressively invalidating the on-disk cache, or maybe we're using session restore to restore the state of the page as of the last time it was quit.

This is easy to see with a simple app comprising a single HTML page.  Install the app, start it, quit it, change the HTML page, and start the app again.  Your change will not be reflected in the app.
I have the same issue with a hosted app. If I install it once, then I change something in the code and close the app (quitting with command + Q) I get the old code. Even if I delete the app from the Applications folder and install it again from the browser, I still get the old code.

But if I go to ~/Library/Application Support/ and delete the profile folder that is created for the app and install again, I get the updated code. (I found the corresponding profile folder by opening the package contents in the created app in /Applications/ and looking at the Contents/Info.plist file)

Not that I want to do all that each time! But yes, confirming bug here, using Mac OS mavericks and Nightly 20140325.
(In reply to Soledad Penades [:sole] [:spenades] from comment #1)
> Even if I delete the app from the Applications folder and
> install it again from the browser, I still get the old code.

This is presumably because the runtime doesn't delete the app's data when you remove the app.  After reinstallation, the app reuses the existing data from the previous installation.
Priority: -- → P1
I think it is the cache, because removing the cache directory fixes the problem.
OS: Mac OS X → All
Hardware: x86 → All
Attached patch TestSplinter Review
This shows that the problem is related to the session history. I don't know anything about this yet, but I guess we shouldn't restore the session during a normal startup.
Actually I'm not sure what's the best way to fix this problem, because for apps maybe we should never restore the session?
In some cases it is useful to restore the session, but maybe in this case we should let the developers choose and implement their own session restore mechanism?

It would be useful to know what we do on b2g, to keep the behavior the same across platforms.
b2g doesn't currently use the session restore code. There was some discussion recently about whether it should start using it.

In the context of an app, my gut instinct is that we should not use it.
I can't reproduce this anymore :/
Can you?

If it still happens we could:
1) Reinitialize (or purge) the session history before setting the "src" attribute
2) Reload the page using nsIWebNavigation::reload with LOAD_FLAGS_BYPASS_CACHE
3) Instead of setting the "src" attribute, load the page using nsIWebNavigation::loadURI with LOAD_FLAGS_BYPASS_CACHE
Flags: needinfo?(myk)
I still see this.  My test is to install Mykzilla <http://www.mykzilla.org/app/>, launch it, change it (making some noticeable change to its launch page), push the change to the server, reload it in the browser to make sure the change was successfully pushed to the server, and then restart the app.

When I do this on my Mac OS X 10.9.3 machine with the latest Nightly build of Firefox as the runtime, restarting the app doesn't update its launch page.  I still see the old version of the launch page.  Pressing the "Reload" button in the app, which calls location.reload(), does update the page, however.
Flags: needinfo?(myk)
(In reply to Myk Melez [:myk] [@mykmelez] from comment #8)
> I still see this.  My test is to install Mykzilla
> <http://www.mykzilla.org/app/>, launch it, change it (making some noticeable
> change to its launch page), push the change to the server, reload it in the
> browser to make sure the change was successfully pushed to the server, and
> then restart the app.
> 
> When I do this on my Mac OS X 10.9.3 machine with the latest Nightly build
> of Firefox as the runtime, restarting the app doesn't update its launch
> page.  I still see the old version of the launch page.  Pressing the
> "Reload" button in the app, which calls location.reload(), does update the
> page, however.

I was able to reproduce this, but I can't now.
I'll try on Mac.

Have you tested with a recent Nightly? A couple of days ago a new cache backend was landed, maybe that's what fixed the problem for me.
(In reply to Marco Castelluccio [:marco] from comment #9)
> Have you tested with a recent Nightly? A couple of days ago a new cache
> backend was landed, maybe that's what fixed the problem for me.

Yes, I tested this with yesterday's (Thursday's) nightly build: 32.0a1 (2014-05-22).
(In reply to Myk Melez [:myk] [@mykmelez] from comment #10)
> (In reply to Marco Castelluccio [:marco] from comment #9)
> > Have you tested with a recent Nightly? A couple of days ago a new cache
> > backend was landed, maybe that's what fixed the problem for me.
> 
> Yes, I tested this with yesterday's (Thursday's) nightly build: 32.0a1
> (2014-05-22).

I've just tested on Mac too, and I can't reproduce :(
Attached patch Test 2Splinter Review
Myk, could you try if this patch fixes your problem?
No, it doesn't make a difference. :-(
(In reply to Myk Melez [:myk] [@mykmelez] from comment #13)
> No, it doesn't make a difference. :-(

So option 3 crossed-off the list.
What about the first patch? It used to fix the problem (when I could reproduce it :D). If it works, we could go with option 1.
(In reply to Marco Castelluccio [:marco] from comment #14)
> (In reply to Myk Melez [:myk] [@mykmelez] from comment #13)
> > No, it doesn't make a difference. :-(
> 
> So option 3 crossed-off the list.
> What about the first patch? It used to fix the problem (when I could
> reproduce it :D). If it works, we could go with option 1.

It works!  Is it reasonable to do?
Comment on attachment 8405931 [details] [diff] [review]
Test

(In reply to Myk Melez [:myk] [@mykmelez] from comment #15)
> (In reply to Marco Castelluccio [:marco] from comment #14)
> > (In reply to Myk Melez [:myk] [@mykmelez] from comment #13)
> > > No, it doesn't make a difference. :-(
> > 
> > So option 3 crossed-off the list.
> > What about the first patch? It used to fix the problem (when I could
> > reproduce it :D). If it works, we could go with option 1.
> 
> It works!  Is it reasonable to do?

I don't know. It looks reasonable to me (but maybe it'd be better to re-initialize the session history at startup, instead of purging it).
Attachment #8405931 - Flags: feedback?(bzbarsky)
Comment on attachment 8405931 [details] [diff] [review]
Test

If the issue is that we're being session-restored but don't want to be, can we just prevent the saving of the session info to start with?  Or do we not know at that point whether it'll be needed?

If that's the case, this looks ok, with a nice comment explaining the goings on.  Even better would be not doing the restore, even if we have restore data, since it's just wasted effort in this case...
Attachment #8405931 - Flags: feedback?(bzbarsky) → feedback+
(In reply to Boris Zbarsky [:bz] from comment #17)
> Comment on attachment 8405931 [details] [diff] [review]
> Test
> 
> If the issue is that we're being session-restored but don't want to be, can
> we just prevent the saving of the session info to start with?  Or do we not
> know at that point whether it'll be needed?
> 
> If that's the case, this looks ok, with a nice comment explaining the goings
> on.  Even better would be not doing the restore, even if we have restore
> data, since it's just wasted effort in this case...

We don't want the session restore to happen. If we disabled session history altogether, would apps still be able to manipulate the history using window.history?
> If we disabled session history altogether

Session history and session restore are somewhat unrelated, at least in Firefox.

Session history is the thing that is used for back/forward/reload.  Session restore is the thing that saves session history and various other state across process startup/shotdown (in sessionstore.js).

Or put nanother way, why does your appBrowser.docShell have anything in its history to be purged?  If it shouldn't have anything, then fixing whatever stuck stuff in there seems like the way to go.
(In reply to Boris Zbarsky [:bz] from comment #19)
> > If we disabled session history altogether
> 
> Session history and session restore are somewhat unrelated, at least in
> Firefox.
> 
> Session history is the thing that is used for back/forward/reload.  Session
> restore is the thing that saves session history and various other state
> across process startup/shotdown (in sessionstore.js).
> 
> Or put nanother way, why does your appBrowser.docShell have anything in its
> history to be purged?  If it shouldn't have anything, then fixing whatever
> stuck stuff in there seems like the way to go.

We don't have a nsISessionStore or nsISessionStartup implementation in the
webapp runtime.
Is there another mechanism that may be restoring the session?
I thought the session history entry could be being loaded from the cache, but
the second patch, that tries to load the uri bypassing the cache, didn't work.
> Is there another mechanism that may be restoring the session?

I don't know offhand.

> I thought the session history entry could be being loaded from the cache

No.  If there is a session history then either that's due to actual navigations in that docshell or because someone went to the trouble of setting up a session history for that docshell.  In desktop Firefox, session restore will do that.  But some other sort of code could do that too.  You'd need to debug what's adding entries to the session history in this case.
(In reply to Boris Zbarsky [:bz] from comment #21)
> > Is there another mechanism that may be restoring the session?
> 
> I don't know offhand.
> 
> > I thought the session history entry could be being loaded from the cache
> 
> No.  If there is a session history then either that's due to actual
> navigations in that docshell or because someone went to the trouble of
> setting up a session history for that docshell.  In desktop Firefox, session
> restore will do that.  But some other sort of code could do that too.  You'd
> need to debug what's adding entries to the session history in this case.

The problem is that I can't reproduce the bug, so it is quite difficult to debug :D
Blocks: 1111077
We need to re-test this, a lot has changed since it was first reported.
Per bug 1238079, we're going to disable the desktop web runtime and remove it from the codebase, so we won't fix these bugs in it.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.