LQ Javascript menus not working non-Gecko browsers

raskin · 10-23-2009, 01:02 AM

I use some obscure WebKit-based browser (uzbl) as my primary browser. I noted that JS menus (like Thread Tools) don't work correctly with it. More specifically, all webkit-based browsers and wine-run IE6 complain about undefined reference _gat.

And without JS the Thread Tools do not work at all (they used to work OK). That means that not only Midori users are locked out of part of fuctionality, but the users who are caught in the middle of X server configuration can't comfortably use ELinks/Lynx/Links in a spare console to search (forum-local search menu is also broken without JS) for the recommendations, which seems somewhat wrong.

If there is a way to fix it without big effort (maybe board engine just needs to be updated/reconfigured), I would be grateful if it got fixed.

jeremy · 10-23-2009, 09:34 AM

All JS items (including Thread Tools) degrade gracefully if Javascript isn't detected. If there's a case where it's detected but the implementation is broken, I'm not sure there's much we can do.

--jeremy

raskin · 10-23-2009, 04:43 PM

There is a lot that can be done.. I investigated a bit.

Problem 1.
JS items do not simply detect JS. JS items do not detect JS and AJAX. They detect JS and user-agent deemed to be compatible. So ELinks, Lynx and Uzbl get no-JS version of thread tools. Yes, adding "Gecko compatible" to useragent helps, but is it really a good idea to require this?

Problem 2.
You set <base href=> in <head>. This causes a problem with href="#threadtools" link. RFC explains that this is a link to fragment called #threadtools in the document at the base URL. Firefox behaves in another way, and works fine, but it seems to be in violation of RFC. So the current behavior relies on RFC violaion by the browser.

jeremy · 10-23-2009, 05:16 PM

Problem 2 would be a bug, put I don't see an href to #threadtools that doesn't include a full URI. Where are you seeing this?

--jeremy

raskin · 10-23-2009, 05:18 PM

And isn't problem 1 also a bug (although a lesser one) in modern days of spawning browsers?

jeremy · 10-23-2009, 05:22 PM

#1 is indeed the intended functionality. I'm not sure what you mean by "spawning browsers". The site works as expected for me in lynx.

--jeremy

raskin · 10-23-2009, 05:30 PM

I change browser identification string. Functionality changes. Nowadays you can never be sure what useragent string really means. On the one hand, there are numerous UIs around rendering engines, and these useragent strings may be unrecognized. On the other hand, sometimes browsers actively lie to match a known useragent filter. I guess ignoring useragent string altogether would be better.

DragonSlayer48DX · 10-24-2009, 07:41 AM

http://webaim.org/blog/user-agent-string-history/

http://www.junkbusters.com/cgi-bin/privacy

raskin · 10-30-2009, 01:56 AM

By the way, thanks for fixing #-fragment-links. Much nicer for keyboard-navigation now.