Bugzilla – Bug 17181
Page titles and breadcrumbs cut off at ampersand
Last modified: 2011-05-09 15:59:32 UTC
Onebrowser branch. Artist names containing ampersands are sometimes cut off in the page title (the large text line displayed above the breadcrumbs) and in the breadcrumbs. To reproduce: 1. Browse My Music > Artists. 2. Find and browse into an artist name containing an ampersand. 3. At this point, both the page title and breadcrumbs correctly display the full name, including the ampersand. 4. Click the artist name in the album listing. 5. The subsequent artist page displays the name cut off at the ampersand.
== Auto-comment from SVN commit #32362 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=32362 == Fixed Bug: 17181 Description: need to replace html entities in crumblist
== Auto-comment from SVN commit #32363 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=32363 == Fixed Bug: 17181 Description: need to replace html entities in crumblist of Classic skin too; add labels to Classic songinfo page
(In reply to comment #2) > == Auto-comment from SVN commit #32363 to the slim repo by mherger == > == http://svn.slimdevices.com/slim?view=revision&revision=32363 == > > Fixed Bug: 17181 > Description: need to replace html entities in crumblist of Classic skin too; > add labels to Classic songinfo page Fix verified on Radio and Touch with r32364 Used: Bruce Hornsby & The Range and The Mamas & The Papas
No, this is still broken. This is in the web interface, both Default and Classic skins, not player interfaces.
Jim - where do you still see this?
(In reply to comment #5) > Jim - where do you still see this? AS explained above: Home > Artists > Artist > Album > Album Artist.
Alan/Andy - this issue is different from the ones I've fixed. Previous cases where & in the data which wasn't replaced by the corresponding HTML entity. But in this case we're passing the name in the URL. Unfortunately were un-escaping the path before we split it into separate parameters. Which means any value with a & in it would be considered a distinct parameter. By using the raw path value from the request object and un-escaping after the splitting, we could fix this. But I'm not sure it's the easiest/cleanest way to achieve this: Index: XMLBrowser.pm =================================================================== --- XMLBrowser.pm (revision 32369) +++ XMLBrowser.pm (working copy) @@ -1103,11 +1103,11 @@ my $allArgs = \@_; # get parameters and construct CLI command - my ($params) = ($args->{'path'} =~ m%clixmlbrowser/([^/]+)%); + my ($params) = ($allArgs->[4]->request->uri =~ m%clixmlbrowser/([^/]+)%); my %params; foreach (split(/\&/, $params)) { if (my ($k, $v) = /([^=]+)=(.*)/) { - $params{$k} = $v; + $params{$k} = Slim::Utils::Misc::unescape($v); } else { $log->warn("Unrecognized parameter syntax: $_"); }
== Auto-comment from SVN commit #32390 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=32390 == Fixed Bug: 17181 Description: use the request's URI instead of the already unescaped path value. Split URI into parameters before un-escaping to not accidentally split on a value with a & in it.
7.6.0 r.32390 Verified on IE , google chrome and Opera 11