Problem closing dialog after navigating to a page using its id in Beta2

[anpsince83]

Dialogs are not closing properly for me in Beta 2 after I navigate to a page using its id, ie. <a href="#home">. On the first click the dialog does not close, but does remove the "&ui-state=dialog" from the hash. Click close again and the dialog will close, but return you to second to last page in the history state. Steps to produce:

1. From homepage, navigate to another page
2. from the next page, navigate back to the homepage from a link like this: <a href="#home">
3. Open a dialog at the homepage
4. Click the close button to close dialog
   • Dialog will not close, but "&ui-state=dialog" is removed from the hash
5. Click the close button again and:
   • the dialog will close, but you are returned to the second to last page in the history state, not the homepage

This scenario worked fine for me in Beta 1. If you actually use the built-in back button provided by jQM in the header then the dialog closes as expected.

[toddparker]

What browser are you seeing this issue on? In this multi-page template, there is a dialog and the close button in the header seems to work as expected:
http://jquerymobile.com/demos/1.0b2/docs/pages/multipage-template.html

...is this is scenario you're describing?

[anpsince83]

I've been testing in Chrome and Mobile Safari.

Yes, in that multi-page template it is closing properly. I think the difference between my app is that I'm not using the multipage template. There are no other pages included in the DOM. So to update my steps:

1. From homepage, navigate to another page that jQM grabs through AJAX, ie. <a href="/some/page">
2. from the next page, navigate back to the homepage from a link like this: <a href="#home">
3. Open a dialog at the homepage, the dialog also is not in the DOM, ie. <a href="/dialog" data-rel="dialog" data-transition="pop">
4. Click the close button to close dialog
   • Dialog will not close, but "&ui-state=dialog" is removed from the hash
5. Click the close button again and:
   • the dialog will close, but you are returned to the second to last page in the history state, not the homepage

[toddparker]

In step 2, you shouldn't link to a page with an # anchor unless it's part of a multi-page setup. You'd link to index.html, not #home when navigating between separate pages pulled in via Ajax.

[anpsince83]

Well, if I link to index.html and not #home, jQM goes out and grabs another copy of index.html and adds it to the DOM, resulting in 2 copies of the same page in the DOM. I didn't necessarily want 2 copies of the same page in the DOM.

Is there anyway to link back to the homepage without having it added again to the DOM? It doesn't seem like jQM is recognizing index.html is already in the DOM. Or is there something I'm missing in my setup?

[anpsince83]

Sorry, hit the wrong comment button.

[toddparker]

Sure, you can add the dom-cache feature to keep it from being removed from the DOM cleanup
http://jquerymobile.com/test/docs/pages/page-cache.html

[anpsince83]

Hmm, I'll have to do some more testing tomorrow, but I don't think the first instance of index.html was actually being removed from the DOM. When I navigated to a new page, and then back to the homepage using index.html, the first copy of index.html was still in the DOM, and then another copy that jQM fetches is added.

And actually, wouldn't linking to #home fail if the homepage was actually removed from the DOM.

[viict]

I have a problem that looks like that one, from the first page I open the second page, them I open a dialog. If I hit the close button it works as expected and returns to the second page. In the second page if I hit the back button on the header (the automatic inserted one) I only see the hash changing from #/page/id to #/page/id&ui-state=dialog and I keep in this infinite loop. Also, if I use the back button on Chrome I get the same result: hash changing, and no first page is opened.

[anpsince83]

So after additional testing, I can confirm in fact the first page you start your app with is not removed from the DOM after navigating to another page. So if your app starts with index.html and you navigate to /second/page.html, index.html remains in the DOM. If you navigate to /third/page.html from the second page, the second page is removed from the DOM as expected, but index.html still remains. Is this intended?

It seems like index.html should be removed. I do not have the data-dom-cache="true" data attribute set. So it should be removing. This is definitely a separate issue from the dialog closing issue, which seems to be buggy in beta 2.

EDIT:
I went ahead and opened a new issue for the homepage caching dilemma. I can't imagine that being the intended behavior.

#2258

[toddparker]

The rule is that any pages added into the DOM via Ajax are flagged for cleanup when hidden. The starting page (index.html in your case) would not be removed so this seems to be working as expected. The DOM cleanup is just to keep things manageable and I think deleting the contents of the original page is probably going too far.

[toddparker]

Wait, I'm very confused about these two tickets. Re-rading this you started asking about dialog behavior then switch dover the first page cache so I think I need to re-open this and close the new ticket -- that right?

[anpsince83]

Yes, this issue is about closing dialog behavior. I'm sorry for the confusion. And thanks for your help, btw.

I diverted a little bit because you mentioned that I shouldn't be linking to a page with an # anchor unless it's part of a multipage setup, which seemed like you were suggesting that that was causing the dialog close issue. So I was just trying to determine the correct way to link back to the starting page to prevent the dialog closing issue.

I don't see what is wrong with linking to the starting page via an # anchor if jQM is not removing it from the DOM. So to me this dialog closing behavior still seems like a bug.

[julien-lafont]

I have exactly the same problem, but with only 2 pages (so, the DOM cache is innocent).
I have a main html document with two embeded pages, and a dialog on a different document.
Memo : It works well with an embed dialog.

Tested on Chome, Firefox, Android with B2 and last release.

Scenario :

1. Open homepage
   2 pages in the DOM
2. Navigate to embeded Page 2 (href="#page2")
3. Open dialog
   I have now the 2 pages and the dialog in my DOM
4. Click on close
   Dom unchanged, "ui-state=dialog" removed from the hash
5. Re-click on close
6. Homepage is open
   Dialog removed from DOM

You can test this bug here :

• Main page : Try it : http://jsfiddle.net/yuYyC/show/ (source http://jsfiddle.net/yuYyC/)
• Dialog : http://jsfiddle.net/wL8Lr/show (source: http://jsfiddle.net/wL8Lr/)
• Click next, open dialog and try to close it !

I have no workaround yet.

Edit :the first click append some data to the link :
data-transition="pop" data-direction="reverse"

[toddparker]

@StudioDev - I tried to test out your page but it's not using latest and the links between pages is sort of broken. Is this still an issue? If so, maybe you can update to point to latest so we can re-test.

[julien-lafont]

This is the new test case :

Main page : http://jsfiddle.net/ByshU/show (launch test from here)
This issue is always present with B3, same workaround.

[jblas]

@anpsince83

The reason you can't just refer to the id of a div in the main application page, from an external page, is because it violates the rules of graceful degradation. By that, I mean ... if your application is loaded in a browser where we've had to disable the AJAX functionality for some reason, the external page will get loaded as a new document in the browser. If you click on a link with an @href="#home", the browser will try to resolve that against the URL of the external page that contains the link .. in other words it will try to find an element with an id of "home" in the external document.

[julien-lafont]

I understand perfectly your answer.

For you, "It's not a bug, it's a functionality" (which will be used in only 1% of cases)
For me, it's a bug (in the other 99%)

But it's not my product, it's yours, and I understand your choice (graceful degradation is a great goal).

[jblas]

@StudioDev

Thanks for the sample. I linked your sample against the HEAD js/css and things work properly. We've fixed several bugs related to pushstate and navigation problems from external pages back to embedded divs in the main application document.

Can you try out the latest js/css and let us know if you still see the problem? Reopen this bug if you still see the problem.

[anpsince83]

jblas, thanks for the explanation. We are deploying on iOS only, so graceful degradation wasn't really a concern for us.

However, I'm happy to say that I no longer have to link back to the starting page via "#home". I found that if you manually add the data-url attribute on your starting/home page, like data-url="/home", any links back to the starting page will return you to the original starting page without adding another copy of the starting page to the DOM.

[jblas]

@anpsince83

Assuming your 'home' is the first page in your main application document. We've added code to the HEAD that makes sure we can always resolve the document or base URL back to the first page in the application document, so you should be able to get to the first/page without duplicating it, even without your data-url workaround.

Your external page links just have to refer to the main application document and it should find it. So for example these urls should get you back to home:

/doc.html
/doc.html#home

[jblas]

@StudioDev

I just saw your last comment. I wasn't trying to state what was right or wrong, or tell anyone how they must implement their site. I was just trying to clarify what seemed to be some confusion in the discussion between @anpsince83 and @toddparker. I do realize that people have different use cases, goals, and implementations.

[anpsince83]

jblas, thanks for the info, that is good to know. Adding the data-url attribute was necessary to accomplish that in beta2. I haven't had a chance to upgrade to beta3 as of yet, but good to hear that this has been addressed.

[jblas]

@anpsince83

The fix was actually AFTER beta3. It will be in the upcoming 1.0rc1 release.

[anpsince83]

jblas, thank you for clarifying!

[julien-lafont]

My problem is well fixed in the head.
Thanks !