Bugzilla – Bug 8335
Infobrowser does not display query box for URLs with {QUERY}
Last modified: 2008-07-23 07:29:56 UTC
On SBC (r2448 with SC 7.0.1 20416) Infobrowser does not provide query enter box when an OPML entry such as below is used. This used to work in 7.0.0 and similar query OPML entry works with AlienBBC which also uses XMLbrowser. The query data entry works OK on WebUI and SB interface. <outline text="Enter city code" URL="http://feeds.bbc.co.uk/weather/feeds/rss/5day/world/{QUERY}.xml" type="search" />
The AlienBBC case is slightly different - it just uses type='search'. So it seems the bug requires both '{QUERY}' and type='search' in the OPML entry.
Triode, can you comment on this one?
Well infobrowser just uses xmlbrowser cli commands, so it is something you have changed in Slim::Buttons::XMLBrowser Ben??
adding Ben to the cc list so he sees my last comment...
I didn't change anything for this, but that doesn't mean someone else hasn't. I'll investigate.
Bryan, could you give me the URL for the XML feed to add to InfoBrowser so I can reproduce this please?
This is the opml file I use - the last entry is the problem one. I'm not certain but I think since reporting the bug - the web interface is now broken for this. Only SB now works. It's not a critical feature but ability for user input helps for some info URLs - and this was a demo of user input. <?xml version="1.0" encoding="UTF-8"?> <opml version="1.0"> <head title="BBC Weather feeds "> <expansionState></expansionState> </head> <body> <outline text="BBC Weather feed"> <outline text="London" URL="http://feeds.bbc.co.uk/weather/feeds/rss/5day/world/1769.xml" /> <outline text="Dublin" URL="http://feeds.bbc.co.uk/weather/feeds/rss/5day/world/0031.xml" /> <outline text="Enter city code" URL="http://feeds.bbc.co.uk/weather/feeds/rss/5day/world/{QUERY}.xml" type="search" /> </outline> </body> </opml>
thanks Bryan- FYI, the webUI still works for this. Entered 0005 and got Edinburgh's weather forecast...kinda chilly for summertime :) I'll see what I can do about controller support for this now that I have it effectively reproduced.
cc:ing Triode, who may have some insight on this one. my $menu = $request->getParam('menu'); # menu/jive mgmt my $menuMode = defined $menu; we use that little bit in queries all over SC to determine if the request is for jive, and XMLBrowser is no exception. Except, what I've found is that the InfoBrowser applet on jive is not sending menu:1 as a tagged param. So the bit of XMLBrowser where {QUERY} is handled as an input field is never reached because $menuMode is false. I'm actually kind of surprised the XMLBrowser is sending back data that's usable by jive at all when $menuMode is false.
I should note-- I went into the InfoBrowser and added menu:1 as a tagged param in the request, and that broke the response data to InfoBrowser completely... { 'infobrowser', 'items', start, gulp, index and ("item_id:" .. index), index and 'menu:1' }
So rereading this - yes its a limitation of infobrowser applet. (Which was actually written before all the xmlbrowser handling in jive was added and it does not support the query param.) It is also designed to work in cli rather than jive menu mode. Quess we could change it but thats what is there at present.
You're describing the issues as a limitation of infobrowser applet - but it used to work in 7.0 . I'm trying to figure out has the code been altered accidentally or did a rewrite break it. Similar "user-input" functionality works ok on SBC with opml "type=search" entries with AlienBBC so I think it is strange that it doesn't work in inforbrowser
Did it really work previously for infobrowser? This has its own relatively simple handler in the infobrowser applet which does not share any code with the main browsing code on jive - hence I don't think it ever worked. It may work if you bookmark an infobrowser entry in favorites and browse favorites?
I'm pretty sure it worked but I could be mistaken. Don't do any more work on it. I'll try to find a SC and Jive build which works. I'll report back either way.
From looking at the code, I'm in agreement with Triode: this has probably never worked for InfoBrowser. Bryan, if you find a version that this did work, report back on this bug. That said, I think it would be nice if this did work...it's an enhancement though. Triode, I'm going to assign this to you, but I'd be happy to take it back if need be. It's not going to make my priority list for quite some time though.
Looks to me as if it may be easier to integrate with SlimBrowser than redo the input dialog for infobrowser. Bryan - is this important for your applications?
This is not a major issue for me but it sort of niggled me that an application would work on WebUI and SB but not SBC. I'm also pretty sure (but could be wrong) it used to work but I haven't had time to rebuild an old version to be able to prove it. I wouldn't bother with it as I guess there are other bugs to solve or new feature to implement.