Last modified: 2012-12-21 15:03:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 9515 - Preference section index links do not work even though anchor names exist.
Preference section index links do not work even though anchor names exist.
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Lowest trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
: easy, javascript
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-07 04:31 UTC by Dan Jacobson
Modified: 2012-12-21 15:03 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2007-04-07 04:31:36 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.
Comment 1 Rob Church 2007-04-07 09:36:08 UTC
Confirmed in trunk; the links are pointing to nonexistent anchors...it might be
useful to add them.
Comment 2 Delirium 2007-08-17 09:54:07 UTC
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.
Comment 3 Delirium 2007-08-17 10:29:43 UTC
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.
Comment 4 Nicolas Dumazet 2008-10-20 06:36:51 UTC
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...
Comment 5 Diederik van Liere 2011-11-29 22:22:09 UTC
The bug is marked as EASY so we should have it OPEN :)
Comment 6 Andre Klapper 2012-12-21 14:28:39 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links