Last modified: 2012-12-21 15:03:45 UTC
Gentlemen, using firefox visit your Special:Preferences. Now type ALT v y n which means "no styles". This turns the HTML FIELDSET element helpful index rendering into * User profile * Skin * Files * Date and time * Editing * Recent changes * Watchlist * Search * Misc However clicking on them does nothing! Lynx, w3m etc. don't have this problem, as they don't attempt to make a helpful index. Bug seen in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061205 Iceweasel/2.0.0.1 (Debian-2.0.0.1+dfsg-1) I see you bend over backwards ([if lt IE 5.5000]...) for browser bugs. This is probably a firefox bug, if so kindly report it to them using terms they can understand. I have a zero batting average when reporting firefox bugs, therefore I hereby drop the ball. By the way, tell them to render the equal signs of 等=x=等==x==等===x=== equally, at least when viewed under monobook.
Confirmed in trunk; the links are pointing to nonexistent anchors...it might be useful to add them.
Looks like a bug in skins/common/wikibits.js. The function tabbedprefs() generates a table of contents by walking the fieldset elements, giving them numbered #prefsection-n internal links, but there's no code anywhere that generates the target anchors. With the normal style (showing the tabs as tabs), tabbedprefs() registers its own onclick=uncoversection handler within the TOC, so the TOC can basically take care of itself. With the anchor-based version, the TOC isn't standalone, so tabbedprefs() needs to modify the fieldsets to match the TOC it's generating. Basically the first loop in tabbedprefs() needs to add an anchor element inside of each fieldset it finds with target: '#' + sections[seci].secid. Unfortunately my JavaScript is too rusty to translate that into a patch.
Nevermind, it does do that, setting 'id=prefsection-n' in the fieldset tag (told you my Javascript was rusty), and that does work in a minimal testcase in Firefox, so something trickier must be going on here; apologies for the misdiagnosis.
I cannot see any proper way to fix this. ( note: functions have moved since to prefs.js ) The anchors do exist, they are inserted by tabbedprefs. However, when clicking on a link, the uncoversection() function is summoned instead of scrolling the window to the proper anchor, overriding the default behavior. Meaning that *if* we want to scroll down to the anchor after switching tab, we have to add in uncoversection() something like : window.location.hash = '#' + this.secid; I tried, this works greatly when CSS is disabled : it scrolls to the right section on clicks. However, when CSS is enabled, it *also* scrolls to the title of the section. And this is particularly annoying since it hides the tab switcher. You *can* fix it with the current interface, but it hinders usability for CSS users. If, one day, the Preferences page is redesigned, then we'll probably be able to enhance usability for both type of users; but until then...
The bug is marked as EASY so we should have it OPEN :)
(In reply to comment #0) > Gentlemen, using firefox visit your Special:Preferences. > Now type ALT v y n which means "no styles". > > This turns the HTML FIELDSET element helpful index rendering into > > * User profile > * Skin > * Files > * Date and time > * Editing > * Recent changes > * Watchlist > * Search > * Misc > > However clicking on them does nothing! Tried with 1.21wmf6 on test2.wikipedia.org with Firefox 17.0.1 and the links work correctly for me without a stylesheet. CLosing as WORKSFORME.
