...d in db)
This issue fixes trac http://trac.xbmc.org/ticket/13777
CGUIMediaWindow::SetHistoryForPath "recreates" a history for use by the back key in case we jump right into a given path. For example if we jump to videodb://2/2/7/-2/?tvshowid=7 (an actual example from my tests) then SetHistoryForPath is constructing a history like this: videodb://2/2/7/?tvshowid=7; videodb://2/2/?tvshowid=7; videodb://2/?tvshowid=7; videodb://?tvshowid=7. The option part (after the ?) is maintained since URIUtils::GetParentPath does only modify the middle part (file). The consequence of this is that when using back, we're looking for the wrong saved viewstate, hence the sort order changes from what was originally set.
The obvious solution is to clear the option part when getting the parent path (only in the condition of being called by SetHistoryForPath). This does not seem to be dangerous, for the reason that it only affects the "recreated history" when accessing a library path directly.
Looks alright to me. I tried to reproduce it but didn't really manage to and now I also know why. I always use the back key to navigate back to home so I never really jump right into a sub-directory of the library.
At first I was concerned about library nodes where we rely on those URL options but it seems like we don't jump directly into those nodes from the home menu so it's not really an issue.
@jmarshallnz - could you please weigh in, and
@davilla - if everyone ok, are you in agreement to pull this into Frodo?
if @jmarshallnz agrees, inject it
I'd prefer that the option clearing is done in SetHistoryForPath instea, as it is not applicable to getting the parent path in general.
fix wrong recreated history causing wrong sort order (because viewsta…
…te not found in db)
addressed @jmarshallnz 's comments. Injecting.