Last modified: 2005-01-12 23:20:43 UTC
BUG MIGRATED FROM SOURCEFORGE http://sourceforge.net/tracker/index.php?func=detail&aid=959317&group_id=34373&atid=411192 Originally submitted by Andre Engels (a_engels) 2004-05-24 11:02 The links on top ("content page" - "discussion" - "edit" etcetera) in the new skin go away from their correct places and jump to a vertical alignment over the top left corner of the actual page when I move the cursor over them. I am using Internet Explorer 6.0 under Windows XP. ------------------------- Additional comments ------------------------ Date: 2004-05-24 11:07 Sender: SF user a_engels Correction to this bug report: I now notice that this only happens to sysop-users, and only when one goes over "protect", "delete", "move" or "watch". ------------------------------------------------- Date: 2004-05-24 12:58 Sender: SF user gabrielwicke Can't reproduce this. Do you have any user styles applied? IE doesn't cope with things like bolding the tabs on hover for example. ------------------------------------------------- Date: 2004-05-24 18:03 Sender: SF user gabrielwicke I've just checked this with IE6 on winxp sp1 as well- no problems there as well. ------------------------------------------------- Date: 2004-05-24 19:16 Sender: SF user a_engels I did a check. It only happens if the screen is not wide enough to show all tabs, which for me was the case because I prefer to use a very large font. In this case, the remaining tabs are moved one line lower, and the specified bug appears. If the line is wide enough to include all tabs, there are no problems. ------------------------------------------------- Date: 2004-05-24 19:51 Sender: SF user gabrielwicke Thanks, that clarifies this. IE doesn't follow the white-space: nowrap setting in this case (which is a bug of course), not much we can do about it. On the other hand it's not too much of a problem- looks a bit weird but the tabs stay functional. Might be possible to do something about this using javascript (attached to the onresize event of the ul for example), you can try it in monobook.js. It won't affect most users because they have fewer tabs/ a better browser, so i think this is a minor problem. ------------------------------------------------- Date: 2004-05-31 09:36 Sender: SF user a_engels Moving this back up to standard priority: I know of two other users (sysops) on nl: with this same problem, and it will also happen to logged-in non-sysops if their window is too narrow. ------------------------------------------------- Date: 2004-06-22 22:28 Sender: SF user jrdioko I am a sysop on en: and I am having this same problem. I reduced the text size in IE and the "watch" tab moved back to the correct position, but with my standard text size the tab would still fit (there is enough room for it at the top). It's as if there is a block of white space that must be included at the end that is pushing the tabs down. I am also having the problem/issue where the tabs all line up vertically below the first tab if I move my mouse over one of them. I don't remember this all happening immediately after I was sysopped/gained the extra tabs, but I could be wrong. ------------------------------------------------- Date: 2004-06-22 23:03 Sender: SF user gabrielwicke The recent change from 'edit' to 'edit this page' on en made this problem worse of course. You can change it back in the MediaWiki ns, a note on this problem on that message's talk pagemight be a good idea as well. ------------------------------------------------- Date: 2004-06-22 23:41 Sender: SF user jrdioko Ah, I should have realized that. Thanks for the info.
*** Bug 307 has been marked as a duplicate of this bug. ***
Created attachment 60 [details] Patched IE60Fixes.css This is a modified IE60Fixes.css which uses a different method of displaying the tabs (uses display:inline-block, standard as of CSS 2.1), which fixes this problem.
Comment on attachment 60 [details] Patched IE60Fixes.css The patched IE60Fixes.css does work, but it gets in the way of a proposed fix I have for bug 119. Will fix it and make a new patch.
Created attachment 74 [details] Patch for IE60Fixes.css Here we go - this fixes the problem in IE6, and also fixes bug 119.