(inactive after 6/18) Alive Kuo [:alive] Reporter
	Description • 10 years ago

We are always resuming a suspended app with its origin launched url,
but if we could detect hashchange in AppWindow and restore by *only* the hashchanged url as it is resumed next time, it would be really good for some apps deal with hash correctly.

	Steve Chung [:steveck]
	Comment 1 • 10 years ago

Hi Alive,

The entry/exit point for window suspended seems like reviveBrowser/destroyBrowser method. For the destroy, maybe we need to cache hash of the iframe in somewhere. And in revive, should we:
1) Append the hash to iframe src directly after iframe set
2) Call reConfig to update the browser_config for BrowserFrame
3) Use navigate with proper url

Or any of above were wrong implementation. wdyt?

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 2 • 10 years ago

(In reply to Steve Chung [:steveck] from comment #1)
> Hi Alive,
> 
> The entry/exit point for window suspended seems like
> reviveBrowser/destroyBrowser method. For the destroy, maybe we need to cache
> hash of the iframe in somewhere. And in revive, should we:
> 1) Append the hash to iframe src directly after iframe set
> 2) Call reConfig to update the browser_config for BrowserFrame
> 3) Use navigate with proper url
> 
> Or any of above were wrong implementation. wdyt?

I think we should just set the stored url (with hash) to the iframe.
We should just update browser_config.url when destroyingBrowser or when locationchange happens;

if (LOCATIONCHANGE && HASHCHANGEONLY) {
  this.browser_config.url = new_url;
}

Then we don't need to change something else. Work for you?

	Steve Chung [:steveck]
	Comment 3 • 10 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #2)
> 
> I think we should just set the stored url (with hash) to the iframe.
> We should just update browser_config.url when destroyingBrowser or when
> locationchange happens;
> 
> if (LOCATIONCHANGE && HASHCHANGEONLY) {
>   this.browser_config.url = new_url;
> }
> 
> Then we don't need to change something else. Work for you?

Sounds reasonable, but just have a concern about the necessity for storing url. Currently there seems only one navigate method could trigger app hash change, and navigate will update browser_config in the meantime. I could still check and update browser_config.url if it's different from iframe url, but it seems unlikely happen. Please correct me if I'm wrong, thanks.

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 4 • 10 years ago

(In reply to Steve Chung [:steveck] from comment #3)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #2)
> > 
> > I think we should just set the stored url (with hash) to the iframe.
> > We should just update browser_config.url when destroyingBrowser or when
> > locationchange happens;
> > 
> > if (LOCATIONCHANGE && HASHCHANGEONLY) {
> >   this.browser_config.url = new_url;
> > }
> > 
> > Then we don't need to change something else. Work for you?
> 
> Sounds reasonable, but just have a concern about the necessity for storing
> url. Currently there seems only one navigate method could trigger app hash
> change, and navigate will update browser_config in the meantime. I could
> still check and update browser_config.url if it's different from iframe url,
> but it seems unlikely happen. Please correct me if I'm wrong, thanks.

Now we have no way to prevent an app to navigate outside the app.
For example, you could do |window.location.href = 'http://www.google.com'| in your own app; system will get mozbrowserlocationchange event after that.
That's why we need to store the url in another place.
the navigate method in AppWindow comes from the url typing in rocketbar which is not in the case.

	Steve Chung [:steveck]
	Comment 5 • 10 years ago

Hi Rob, sorry for the interruption, I think you might be the proper candidate for the general system behavior.

The scenario is when app is suspended at certain panel, the app window revive mechanism should resume the previous status(the original bug description said we didn't resume the proper url correctly, but actually we did). The question is if the app modified the url to other remote domain(like http://www.google.com), should we cache/resume the url as well when window suspended, or we should just resume the original app?

	Rob MacDonald [:robmac]
	Comment 6 • 10 years ago

Hi Steve - Thanks for flagging me. I think I'd need to get a better sense of the use cases for this and examples of why an app would want to do this. I'm thinking generally we want to restore the previous state but I'm sure there are cases where doing otherwise would be desirable. Are you able to provide me with real world examples or direct me to a link? Also NI'ing Wilfred for the product perspective. - Rob

	Julien Wajsberg [:julienw]
	Comment 7 • 10 years ago

A real-world use case is:

1. the user opens a thread in the SMS application
2. the user switches to other windows, the SMS application is killed
3. when the SMS application is resurrected we're in the inbox instead of the specific thread.

Note that even with the change in the System app we'd need to change also the SMS app, because we don't currently change the hash. This is bug 1011089.

	BMO Automation
	Comment 8 • 7 years ago

Firefox OS is not being worked on