Nested lists with same parent text resolve to the same sub-page.

[dharrod]

Not sure if this has already been posted, but I couldn't find it.

I have a page with two list views. Each list view has an item with a nested list. The text of the parent item of the nested list is the same in each list view. The 'safe name' generated for the sub-page hash for both parent items resolves to the same name. So when viewing one of the sub-lists causes the wrong sub-list to be displayed. It looks like the sub-page hash is adding an index to help provide uniqueness for the sub-page hash, but the index is only for a given listview. When the next listview is encountered, the index resets and since the parent text is the same, the resulting sub-page hash conflicts with the sub-page list for the item in the previous list view.

Here is my example: (Not sure how to quote HTML source, but this looks the best...)

  <div data-role="page">
    <div data-role="header">
        <h1>Title</h1>
    </div><!-- /header -->

    <div data-role="content">   
        <ul data-role="listview" data-inset="true">
            <li>Item 1</li>
            <li>Item 2</li>
            <li>Parent Item<ul data-role="listview">
                    <li>Sub Item 10</li>
                    <li>Sub Item 11</li>
                    <li>Sub Item 12</li>
                </ul>
            </li>
        </ul>
        <ul data-role="listview" data-inset="true">
            <li>Item 3</li>
            <li>Item 4</li>
            <li>Parent Item<ul data-role="listview">
                    <li>Sub Item 20</li>
                    <li>Sub Item 21</li>
                    <li>Sub Item 22</li>
                </ul>
            </li>
        </ul>
    </div><!-- /content -->
</div><!-- /page -->

Note that when viewing the 'Parent Item' in the first list-view, the sub-list from the second 'Parent Item' is displayed. In looking at the link url, the hash values are the same: '#&ui-page=Parent-Item-0'.

Thanks

[StevenBlack]

Bug!

Here's a fiddle that illustrates this clearly. http://jsfiddle.net/stblack/z7nbj/

[StevenBlack]

Within this fiddle I note that the link's href attribute value contains "undefined".

http://gyazo.com/40b0eee055ac9643ad75bb9663a3f190.png

[toddparker]

Interesting. We'll definitely have to fix this.

[gseguin]

Keeping track of the number of lists per page through a hash in $.mobile and incorporating that count to the list id generation code might do the trick. In the test case above that would lead to the first "Parent Item" to have id: "#undefined&ui-page=Parent-Item-0-0" and the second one to have id: ""#undefined&ui-page=Parent-Item-1-0". Check out http://jsfiddle.net/ghislain/z7nbj/9/

[StevenBlack]

Ghislain, is the undefined not a bug? I'm guessing if what's undefined is resolved properly -- uniquely -- then would there be a need for the mangling?

[gseguin]

The undefined comes from parentPage.jqmData( "url" ), I don't know if it's a bug but it sure doesn't look good.
Even if it weren't undefined the problem would be the same since parentPage.jqmData( "url" ) would be the same for the current page resulting in the same id to be generated for both the "Parent Item" items.

[toddparker]

I just pulled in these tests. I think that @gseguin is right - don't these need unique parent item IDs in the hash for this to work?

[johnbender]

This appears to be broken as evidenced by the failing test in listview. More information here