Wikipedia:Requests for comment/May 2010 skin change/Bug reports

From Wikipedia, the free encyclopedia

If you still notice any problems, however small, with the new interface, please report them here. This includes font issues, broken user scripts and gadgets, and anything that was working before the skin change that is not working anymore. Even if you have reported the problem elsewhere, if it hasn't been fixed, please report it here so it can be in a centralized location.

For quick resolution, please provide your web browser name and version number (e.g. Firefox 3.6.3) when making a report. Be sure to use a descriptive section name and provide as many details as possible. If the bug is with a user script or gadget and you have a web browser with an error console, please provide any error messages that may be relevant. Be sure to watchlist this page after reporting, or check back occasionally, as followup may be needed.

Delta differences[edit]

Resolved

I no longer have the delta button in the "Differences between revisions" display. FF 3.5.8. I realize it is not part of the core Wikipedia software but the result of an add-on, but for me it's a must have. ∴ Therefore cogito·sum 18:36, 19 May 2010 (UTC)[reply]

Let me add that I also have lost this valuable feature since the skin change and want to see it restored. I don't use the enhanced diff that often, but there are times when I really need it. --SteveMcCluskey (talk) 21:29, 30 May 2010 (UTC)[reply]
OK, I just solved this problem by following the procedures at the section #monobook.js, below. --SteveMcCluskey (talk) 21:38, 30 May 2010 (UTC)[reply]
Copy the contents of your monobook.js into your vector.js. This applies the scripts you had before (specifically wikEdDiff) to the new skin. Shubinator (talk) 21:37, 30 May 2010 (UTC)[reply]

Toolbar dropdown boxes occasionally open under the edit window[edit]

Observed in FF 3.6.3 and 2.0. If a toolbar section with a dropdown box (the headings one in "Advanced", or the one in the refToolbar gadget) is opened, closed, then re-opened, the dropdown appears behind the textarea. Mr.Z-man 22:41, 15 May 2010 (UTC)[reply]

Filed as bugzilla:23541. Mr.Z-man 00:36, 16 May 2010 (UTC)[reply]

Broken search window[edit]

Latest Firefox, Dell. I start typing the page I want to go to, such as wp:mosnum, hit enter, and it erases some random number of letters I typed and sends me off to the non-existent page. This happens fairly consistently, no matter what page. Also, I prefer the old location for the search box, it's closer to where my eye and my cursor are likely to be, so it's more efficient. - Dank (push to talk) 22:58, 15 May 2010 (UTC)[reply]

  • Nothing to add, just confirming I've also experienced this problem several times (using Firefox 3.6.3). --auburnpilot talk 23:13, 15 May 2010 (UTC)[reply]
While I am encountering this issue more rarely now, it seems to still be fairly consistent when using copy/paste to enter a search term and hitting enter. It appears to be related to search suggestions, as noted by Killiondude, as I don't have the problem if I wait for the suggestions to appear. --auburnpilot talk 04:45, 18 May 2010 (UTC)[reply]
  • Same here. I think it's a lag between what one types in the search bar and the suggestions. If it hasn't properly gotten the suggestions for how many characters one has typed in before pressing return/enter, then it snips the characters it couldn't process in time. I hope that made sense. This only happens in vector, from my experience, and only in the last week when the search bar was altered (I have vector enabled on Commons before enwiki changed to vector, and it worked fine then). The search bar also isn't long enough to properly display the titles of the suggestions. Killiondude (talk) 23:21, 15 May 2010 (UTC)[reply]
Text being cut off is bugzilla:23498. Mr.Z-man 00:43, 16 May 2010 (UTC)[reply]
  • I'll add that I'm also getting this problem. –MuZemike 14:51, 17 May 2010 (UTC)[reply]
  • I'm also experiencing this. Mike Allen 06:55, 19 May 2010 (UTC)[reply]
  • This truncation has happened to me; also, the placement of the search box in the upper right means that you cannot see the full suggested completions in the drop down if you're searching for anything longer than about 20 characters, as the dropdown is too small. The search widget is so bad I've gone back to Monobook. MattHucke(t) 15:22, 19 May 2010 (UTC)[reply]
  • Same for me on Firefox 3.6.3: search box sometimes removes the last several already-typed characters while the user is still typing. This is especially frustrating since (thanks to every suggestion line's anti-new-tab behavior described in other sections below) the only way to "Go" in a new tab now is to type the entire name of the article out in full rather than selecting it from a drop-down list. --Closeapple (talk)

Tabbed browsing[edit]

The editing/viewing buttons at the top of every page (edit, view history, discussion, etc) do not appear to allow you to open up tabs/tabbed browsing in Internet Explorer 7 anymore, though tabbed browsing with those buttons does seem to work in Firefox 3.6.2 (IE7 is my primary browser), and every other link I've tried since the skin change seem to allow tabbed browsing, and interestingly enough, the "delete", "move", and "protect" buttons at the top of each page do allow tabbed browsing. Acalamari 23:30, 15 May 2010 (UTC)[reply]

This is bugzilla:23490. Mr.Z-man 00:45, 16 May 2010 (UTC)[reply]
I use that a lot. This issue is one of the main reasons I went back to monobook. --Auntof6 (talk) 00:52, 16 May 2010 (UTC)[reply]
I agree, though I haven't (yet) switched back. YBG (talk) 06:44, 17 May 2010 (UTC)[reply]
Same here. No right click for the tabs at the top. ... (talk) 05:30, 19 May 2010 (UTC)[reply]
Me too, and that's an issue for me, because I want to have the article open at the same time so I can refer to it while I'm discussing it. There are ways around it, but they involve a lot of key-clicks. Scolaire (talk) 06:53, 19 May 2010 (UTC)[reply]

NOTE: to access tabbed browsing right click slightly below the target text. Tabbed browsing is one of the handiest gadgets on the browser. Flash has lacked it for a couple of years now it must be the biggest failing of the flash gadgets. ~ R.T.G 12:39, 24 May 2010 (UTC)[reply]

For convenience, is there any way that we can use to move it up into the target text? :| TelCoNaSpVe :| 04:40, 16 June 2010 (UTC)[reply]

Wider search box[edit]

This is more an annoyance than anything else, but the new Vector search box seems to be too narrow. Currently, article titles of any appreciable length are cut off, dramatically reducing its usefulness. Making the search box about 50% wider (150% of the current size) should rectify this. SchuminWeb (Talk) 23:36, 15 May 2010 (UTC)[reply]

Put this in your CSS file, courtesy of User:PleaseStand:
/* Make search box longer */
#simpleSearch input#searchInput { width: 20em; }
#simpleSearch { margin-top: 0.6em; }
BTW the default width is 9em. Maybe it had to be narrow before, because it was in the sidebar, but there's no real reason to be this narrow now. GregorB (talk) 23:47, 15 May 2010 (UTC)[reply]
I agree, it's unusually narrow given the amount of unused space between the page tabs. Jeffrey Mall (talkcontribs) - 00:00, 16 May 2010 (UTC)[reply]

This is being looked into by the Usability people. In the meantime, I've added that CSS as a gadget, so people can use it without needing to modify their CSS pages. Mr.Z-man 01:01, 16 May 2010 (UTC)[reply]

Added, how handy is that? Cheers Mr.Z-man, Jeffrey Mall (talkcontribs) - 01:37, 16 May 2010 (UTC)[reply]
Thanks for adding that as a gadget, as someone who knows nothing about adding code but was really unhappy with the absurdly narrow window. Shawn in Montreal (talk) 21:56, 16 May 2010 (UTC)[reply]

Had the same complaint. The fact that the search box is top right inevitably leads to that. Pichpich (talk) 13:44, 16 May 2010 (UTC) 2 ideas for a permanent fix:[reply]

  • Make it so that the size of the search bar varies with the size of the window, so that if you have the window maximized on a widescreen monitor, it will take up more space (maybe at least another 1/3 of what you get with the gadget) than if you only have the window take up 1/5 of the screen (where it will eventually shrink down to the size of the box without the gadget). I'd say try to make it so that when the window is maximized completely on a widescreen the distance between the Discussion tab and the Read and Edit tabs should take up approximately 1/2 of the bar, and as the size grows smaller that ratio will shrink accordingly.
  • Make it so that the suggestions list aligns to the right of the search box instead of the left. That way, long page names don't push on the window boundaries, so you don't have to scroll to see the rest of the entry.

Also, a bug I found, at least in Safari 4.0.5 and SeaMonkey 2.0.4 is that if you type something into the search bar and then resize the window, the suggestions box stays in the same place instead of moving with the search bar.--vgmddg (look | talk | do) 20:32, 18 May 2010 (UTC)[reply]

Comment moved here from a (roughly) duplicate bug listing: --Tagishsimon (talk) 12:31, 2 June 2010 (UTC)[reply]
Apart from cutting characters off, there's another problem with the search box. When I type something into it, in the drop-down list that appears, the right half of some long titles are hidden whether there is a vertical scrollbar or not. If I point at some very long titles, a tooltip shows up, but for titles of medium length, there is none and I can't find out except by clicking them. -- Karunyan, 08:31, 17 May 2010 (UTC)[reply]

Font size issues[edit]

Some fonts on some pages are smaller than they used to be, and I find them a bit difficult/uncomfortable to read as a result. For example, when comparing edits in the edit history of a page, the text is now smaller than it was before. Another example: the monospaced text (Courier font?) used in the tables on this page is much smaller than it used to be, which makes it difficult to read. I'm using the latest version of Firefox with Windows XP SP3. I reported this issue several months ago when I was trying out the beta, but I don't know if anyone ever looked into it. –BMRR (talk) 00:24, 16 May 2010 (UTC)[reply]

I agree. One more example: last edit times in the leftmost column in the watchlist.
The sizes are slightly smaller, but as a netbook user the one thing that is really hard is the Twinkle interface, which is minuscule. Is that to do with Vector at all? {{Sonia|talk|simple}} 10:28, 16 May 2010 (UTC)[reply]
In addition, the bold attribute of the smaller font sizes is often imperceptible. It'd be nice to be able to tweak the font size as a UI option. JohnInDC (talk) 13:32, 16 May 2010 (UTC)[reply]
The monospaced font referred to is in the {{tltts}} template, which uses <span style="font-family:monospace;"></span> to achieve it. I noticed similar issues with the {{tlsx}} template, which were fixed by changing the span to <tt></tt>. --Redrose64 (talk) 12:35, 17 May 2010 (UTC)[reply]

google search broken[edit]

Resolved
 – By stealing some code from a Mr.Z-man fix, below.

See User_talk:Henrik#google-search_in_Vector Smkolins (talk) 00:40, 16 May 2010 (UTC)[reply]

In more detail, there's a useful monobook compatible wikipedia google search box facility at User:Henrik/sandbox/google-search. User:Henrik appears to be AWOL. It would be great to get this working in Vector, even if it means pushing the page down by one row to insert space for the new search box. thanks --Tagishsimon (talk) 01:26, 24 May 2010 (UTC)[reply]
Resolved

Is there a replacement for User:Zocky/PicturePopups.js that is compatible with the new skin? Thanks. 96.15.58.199 (talk) 02:38, 16 May 2010 (UTC)[reply]

  • Custom CSS and Custom JS probably won't work with non-logged users - you need to add them to the account's CSS and/or JS pages and I don't think that can be done for IP accounts. kcylsnavS {screech} 12:13, 16 May 2010 (UTC)[reply]
  • Meanwhile, I went and wrote a new version of picture popups for vector. Maybe it even works in IE7 and IE8, somebody should try. See the picture popups page for installation instructions. Zocky | picture popups 12:44, 18 May 2010 (UTC)[reply]
    • It works in IE7, but not IE6. I haven't tried IE8. Zocky | picture popups 13:10, 18 May 2010 (UTC)[reply]
    • Thanks! (Btw, ips can also use scripts through tools such as Greasemonkey) 96.15.47.28 (talk) 15:15, 18 May 2010 (UTC)[reply]

Expanding left menu does note expand in Opera Mini[edit]

When I read Wikipedia on the Opera Mini 5.0 browser for mobile devices, as I frequently do, the new skin does not expand the expandable sections in the left menu of the new Wikipedia skin on click. Actually the expandable elements are not clickable at all. Most of all I miss the languages section, as I frequently change between languages or check if another language version have more information. Mortenoslash (talk) 06:01, 16 May 2010 (UTC)[reply]

Reported as bugzilla:23552. Mr.Z-man 19:15, 16 May 2010 (UTC)[reply]

Template for references[edit]

Firefox 3.6.3. Windows 7. I don't know if this is a bug or not, but when editing I used to click on the references button in the editing toolbar & get options of book, web, journal, news etc. I don't know if this was a gadget or the default. Now I just get a blank bar with enter text & have to go & get the cite web, cite book or similar template & paste it in. I feel this change will discourage people from adding full details of references & is therefore a retrograde step.— Rod talk 08:54, 16 May 2010 (UTC)[reply]

  • That was the refTools gadget. It is working intermittently for me. Sometimes it appears, but usually it does not. I'm using Firefox 3.6.3 on XP Pro SP3. I have tried both using it as a gadget and manual installation. --GW 11:08, 16 May 2010 (UTC)[reply]
    • When it doesn't appear, can you check your JavaScript error console for errors? Ctrl-Shift-J, then select "Errors". The ones on the bottom are the most recent. Mr.Z-man 14:16, 16 May 2010 (UTC)[reply]
      • I haven't had a problem with it since I posted my report, but I have got another issue now. Sometimes the dropdown menu appears behind the edit box. I checked the console, but it was not displaying any errors. Also, whenever I click on the button to insert today's date into the accessdate field, it scrolls up to the top of the page. --GW 16:53, 17 May 2010 (UTC)[reply]
        Agree with GW: I have had the dropdown menu go behind the edit box, and so not be usable (some kind of z-order problem? Firefox 3.5.9 on Ubuntu with Compiz) I also find the 'insert today's date' button causing a scroll to the top of the page irritating. --Nigelj (talk) 16:46, 27 May 2010 (UTC)[reply]
This second bug is already reported at #Toolbar dropdown boxes occasionally open under the edit window and filed as bugzilla:23541. It's fixed, we're told, but I'm not sure if the fix has been released. --Tagishsimon (talk) 19:15, 14 June 2010 (UTC)[reply]

Hidden comment button[edit]

Resolved
 – The function is still available from the Insert menu, below the Save button.

The button to add a <!-- hidden comment --> which used to be in the toolbar above the edit window doesn't seem to be there any more. Unless I just haven't found it yet. (Firefox 3.5.9) cheers, Struway2 (talk) 11:47, 16 May 2010 (UTC)[reply]

Yes! That was the dealbreaker for me. I couldn't see that or anything else I usually grab from there, and I needed to make something hidden. Yngvadottir (talk) 15:00, 16 May 2010 (UTC)[reply]
I can't find it either. Armbrust Talk Contribs 23:37, 16 May 2010 (UTC)[reply]
It wasn't there when I last looked. Jared Preston (talk) 12:54, 17 May 2010 (UTC)[reply]
Please bring this button back ASAP! Wizard191 (talk) 15:29, 26 May 2010 (UTC)[reply]

I can't find it. I looked at my insert menu and there is nothing saying comment or hidden comment.TCO (talk) 23:56, 13 December 2010 (UTC)[reply]

It's under the Wiki markup section of the Insert menu, on the third row of the wikimarkup it offers to you, second from the right. --Tagishsimon (talk) 09:00, 14 December 2010 (UTC)[reply]

Wow there is all kinds of good stuff in there! I thought each one of those was a single heading, not a whole category. Very cool and thanks. P.s. Edit do see what I wrote in the hidden comment.

We need the line break thingie in the toolbar also please. TCO (talk) 11:13, 14 December 2010 (UTC)[reply]
I don't think the request will get much attention from this page. I suggest Wikipedia:Bug reports and feature requests and its pointer to bugzilla.wikimedia.org. I presume you're meaning the <br /> markup? --Tagishsimon (talk) 11:49, 14 December 2010 (UTC)[reply]

That's the critter.TCO (talk) 11:52, 14 December 2010 (UTC)[reply]

monobook.js[edit]

Resolved
 – vector.js created Shubinator (talk) 05:25, 18 May 2010 (UTC)[reply]

I don't know what it's called, but the yellow floating box of tools is off in the new skin. I'm using FF3.6.3 (although it's also the same in Chrome) Totnesmartin (talk) 11:56, 16 May 2010 (UTC)[reply]

  • If it is in your monobook.js file, then that only affects the old skin. You need to configure your vector.js file instead. --GW 14:06, 16 May 2010 (UTC)[reply]
can I just copy over the content or will ther be a vector version? Sorry for the noob questions but this behind-the-scenes stuff is beyond me. Totnesmartin (talk) 17:54, 17 May 2010 (UTC)[reply]
You can copy everything from your monobook.js to your vector.js. Shubinator (talk) 17:58, 17 May 2010 (UTC)[reply]
Excelent. Cheers guys! Totnesmartin (talk) 18:34, 17 May 2010 (UTC)[reply]

refTools[edit]

Resolved
 – Mr.Z-man fixed it. Shubinator (talk) 05:26, 18 May 2010 (UTC)[reply]

refTools gadget button seems to have disappeared, I have the box checked at My preferences/Gadgets. Anna Lincoln 14:12, 16 May 2010 (UTC)[reply]

What browser are you using? Mr.Z-man 14:24, 16 May 2010 (UTC)[reply]
Firefox 3.6.3 on Windows 7 64-bit: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 Anna Lincoln 14:42, 16 May 2010 (UTC)[reply]
Is there anything in the error console? Mr.Z-man 14:52, 16 May 2010 (UTC)[reply]
Error "mw.usability is undefined" at MediaWiki:RefToolbarLocal.js.
At: mw.usability.addMessages( { "cite-section-label" : "Cite",

"cite-template-list" : "Templates", "cite-named-refs-label" : "Named refs", "cite-named-refs-title" : "Insert a named reference", ... Anna Lincoln 15:01, 16 May 2010 (UTC)[reply]

I'm guessing you've tried this already, but ... WP:BYPASS your cache? Make sure to do it on an edit page, or it may not bypass it properly. Mr.Z-man 19:09, 16 May 2010 (UTC)[reply]
Same issue here, no "cite" button despite gadget enabled. Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729).  Sandstein  15:59, 16 May 2010 (UTC)[reply]
However, manually installing the script, by adding "importScript('User:Mr.Z-man/refToolbar 2.0.js');" to the vector.js, does work.  Sandstein  16:03, 16 May 2010 (UTC)[reply]

(FF 3.6.3 on Win7) The Cite button in the new edit tool bar has disappeared again. It's been working fine the past few days, but this morning it's gone. I cleared my browser cache but it's still not showing. The java error console shows this error:

Error: CiteTB is not defined
Source File: http://en.wikipedia.org/w/index.php?title=User:Mr.Z-man/refToolbar_2.0.js&action=raw&ctype=text/javascript Line: 18

In my preferences I have new toolbar with dialogs ticked; refTools in gadgets unticked; and importScript('User:Mr.Z-man/refToolbar 2.0.js'); in my vector.js file. Thanks. --Bruce1eetalk 06:32, 17 May 2010 (UTC)[reply]

It's working again and the CiteTB error has gone. Thanks Mr.Z-man. --Bruce1eetalk 05:19, 18 May 2010 (UTC)[reply]
I haven't got a "cite" button. I'm in the latest version of Google Chrome, Windows Vista. HJ Mitchell | Penny for your thoughts? 16:55, 19 May 2010 (UTC)[reply]
I don't have the "cite" button either. I am using Firefox 3.6.3 on Windows XP and am not manually installing the script. However, after visiting the refTools article on another PC the "cite" button appeared, but when I tried it on this PC I reverted to the old edit toolbar. Both only appeared immediately after visiting refTools and did not persist. It may of course have just been a coincidence. - Scribble Monkey (talk) 10:01, 25 May 2010 (UTC)[reply]

Contents of edit box appear duplicated outside of edit box[edit]

Using IEtab in Google Chrome, and the Modern skin; when editing an existing page, the last few characters in the edit box will appear, duplicated, in monospaced font underneath the edit box. The length of the string that appears is not consistent, it seems to be approximately proportional to the total length of the text in the edit box. The text is positioned directly beneath the edit box and is flush with the left-hand side of the screen. When it appears, the toolbar on the left hand side stops underneath the last menu item, rather than continuing to the bottom of the page. This seems to only occur when editing an existing page; if a new section is added and previewed, then normal performance is experienced.

Martin (Smith609 – Talk) 14:23, 16 May 2010 (UTC)[reply]

I also saw this. --Auntof6 (talk) 22:34, 17 May 2010 (UTC)[reply]
More information, if helpful; in certain instances (cannot work out how to replicate), the text that appears outside of the box is modified as one edits. Thus when adding new characters to the end of the edit box, any changes will also appear in the duplicated line of text. Is this the proper place to report such errors, or would a bugzilla report be more appropriate? Martin (Smith609 – Talk) 22:20, 22 May 2010 (UTC)[reply]
I'd take it to bugzilla. I think in part this page is about getting bugs from users who are unfamiliar with bugzilla. Some of the bugs have been cured directly from this page without recourse to bugzilla. Many others prompt a bugzilla report. --Tagishsimon (talk) 19:17, 14 June 2010 (UTC)[reply]

Padding about tabs[edit]

I'm not sure if this is on purpose or not but there is too much padding between the userbar and the tabs. This makes a big difference on netbooks. Vertical space is in high demand. Jack (talk) 14:58, 16 May 2010 (UTC)[reply]

Also between lines in the edit box. I can understand wanting to space the text out more to improve readability, but I'd prefer to be able to see more at a time on the screen. --Auntof6 (talk) 08:46, 17 May 2010 (UTC)[reply]
I completely agree with you. Jason Quinn (talk) 19:32, 18 May 2010 (UTC)[reply]
See also duplicate bug listing at #Unnecessary white space at top? --Tagishsimon (talk) 12:35, 2 June 2010 (UTC)[reply]
I also don’t like this, so I hacked it in my user stylesheet. I reduced the height of the divs id=mw-page-base and mw-head-base, and set the vertical position of left-navigation and the top margin of right-navigation. (I went the other extreme; for general use a compromise might be found.) Also the fade to white is harsh on my eyes, so I override the background images. MJ (tc) 14:57, 16 June 2010 (UTC)[reply]

User contributions[edit]

Resolved
 – Shubinator (talk) 05:26, 18 May 2010 (UTC)[reply]

Until recently, when I went to somebody's user page (or talk page), there was a link at the left which brought me to that user's contributions. Now if I want to see somebody's contributions, I have to go to the history of a page that person has just edited in order to find such a link quickly. Am I missing an easier way? Girlwithgreeneyes (talk) 16:51, 16 May 2010 (UTC)[reply]

You might just have to expand the Toolbox in your sidebar, by clicking on it (or by making the sections uncollapsible in your preferences), but you should still find a contributions link there. Amalthea 17:36, 16 May 2010 (UTC)[reply]
Thank you. I didn't realize that. It's working fine now. Girlwithgreeneyes (talk) 19:29, 16 May 2010 (UTC)[reply]
Just wanted to say that making it easier to find things, especially for new users, was supposed to be on of the benefits of the new interface change. Yet here is an example were the change confused even an experienced editor. The point is that a lot of the talk about "making things easier" is just smoke and mirrors. Jason Quinn (talk) 19:34, 18 May 2010 (UTC)[reply]

Cite book does not work[edit]

Resolved
 – Unless otherwise advised

In the vector skin, when I press the references button in the toolbar, it gives a dropdown containing "Cite web", Cite News" and "Cite book". While the first two give usable forms to fill out, Cite book only gives me a blank box, with no fields in it. Brambleclawx 17:51, 16 May 2010 (UTC) Add I am using Internet Explorer 7.0. Brambleclawx 18:09, 16 May 2010 (UTC)[reply]

This should be fixed now, you'll have to bypass your cache. Mr.Z-man 19:07, 16 May 2010 (UTC)[reply]

Hotcat stopped working[edit]

Resolved
 – vector.js created. Shubinator (talk) 05:33, 18 May 2010 (UTC)[reply]

Have been using hotcat and up until a few days ago, it stopped working. I checked the settings and nothing has changed. Totally baffling.--Hourick (talk) 18:45, 16 May 2010 (UTC)[reply]

You need to add hotcat into your vector.js. An easy way to transfer scripts from the previous skin is to create Special:MyPage/vector.js with the line importScript('Special:MyPage/monobook.js');. Shubinator (talk) 18:56, 16 May 2010 (UTC)[reply]
Is it not technically possible just to move custom pages? Jeffrey Mall (talkcontribs) - 00:48, 17 May 2010 (UTC)[reply]
Hadn't thought of that...I'm pretty sure you can, but then if you choose to go back to the monobook skin you'd have to move your js page again. Shubinator (talk) 02:49, 17 May 2010 (UTC)[reply]

Unwatch script not working[edit]

Resolved
 – Technical issue resolved. Documentation issue is not vector specific

In the new version, I can no longer get the "x" to rapidly unwatch things in my watchlist. The monobook.js script I was using was importScript('user:js/watchlist.js'). --Elonka 20:28, 16 May 2010 (UTC)[reply]

Try moving the entire contents of your monobook.js to your vector.js. NotAnonymous0 did I err?|Contribs 20:36, 16 May 2010 (UTC)[reply]
That did the trick, thanks! Perhaps this should be documented somewhere? The first I heard of this "vector.js" was reading this bug report page. I'd recommend:
  • Adding a mention about vector.js to Special:UsabilityInitiativePrefSwitch
  • Adding a link to this Bug report page to the Special page
  • Adding a link to a Wikipedia-accessible discussion page, to the Special page. For example, there are typos on the Special page ("make easier" should be "make it easier", and "tables easier and find and a replace feature" needs to be rewritten), but it's not clear where errors can be reported or fixed.
--Elonka 20:55, 16 May 2010 (UTC)[reply]

Special characters "undefined"[edit]

When editing and using the "Special characters" option, all of the categories have "undefinedundefinedundefined" at the end of their character lists. I'm using Firefox 3.6.3, and have not tested it on other browsers. – VisionHolder « talk » 22:04, 16 May 2010 (UTC)[reply]

I have noticed this too. I would have thought a dev would have noticed this. I can't work out what in the JS is causing this. — This, that, and the other (talk) 10:52, 24 May 2010 (UTC)[reply]
It's now reported as bugzilla:23962 --Tagishsimon (talk) 19:28, 14 June 2010 (UTC)[reply]

Strike button[edit]

Resolved

I can't find the strike button, which produces the <s> striked text</s>. Armbrust Talk Contribs 23:28, 16 May 2010 (UTC)[reply]

The strike button doesn't appear in the new toolbar by default. You will have to add it in manually. Just add

if ( typeof $j != 'undefined' && typeof $j.fn.wikiEditor != 'undefined' ) { $j(document).ready( function() { $j( '#wpTextbox1' ).wikiEditor( 'addToToolbar', { 'section': 'advanced', 'group': 'format', 'tools': { 'strikethrough': { label: 'Strike', type: 'button', icon: 'http://upload.wikimedia.org/wikipedia/commons/9/95/Toolbaricon_strike_s.png', action: { type: 'encapsulate', options: { pre: "<s>", post: "</s>" } } } } } ); } ); }

to Special:MyPage/skin.js. ~NerdyScienceDude () 23:14, 21 May 2010 (UTC)[reply]

Thanks, it works now. Armbrust Talk Contribs 23:20, 21 May 2010 (UTC)[reply]

Random reloads[edit]

I'm not sure if it's a bug in the Javascript (I've since gone back to Monobook as this bug was just too annoying) but sometimes while typing, especially on a larger page, the text in the box would randomly reload, meaning that all the changes I had made were lost. I am using Mozilla 3.6.3 on Windows XP.

Non-responsiveness to keyboard shortcuts[edit]

Standard keyboard shortcuts such as Ctrl-C, Ctrl-V, Shift-Ins and Shift-Del work unpredictably, and using Ctrl-left then Ctrl-right to return to a window (e.g. to check what was on a previous screen) almost always causes any altered information to be lost. Orderinchaos 03:55, 17 May 2010 (UTC)[reply]

Reflist template[edit]

It appears that when using {{reflist}} under Vector, the font size is still 100%. Reflist is supposed to size down the font size for the references list, and this is currently not happening. I have a feeling it's related to the CSS class "references-small", which is either undefined in Vector, or the desired behavior is defined differently in Vector. See also Template talk:Reflist#Font size in Vector. SchuminWeb (Talk) 03:57, 17 May 2010 (UTC)[reply]

I have noticed this too, and I find it annoying. I use Firefox 3.6.3. --Tryptofish (talk) 18:38, 29 May 2010 (UTC)[reply]

The first line is standard text, the second is spanned with class="references-small":

  • The Quick Brown Fox Jumps Over The Lazy Dog
  • The Quick Brown Fox Jumps Over The Lazy Dog

Here is what I see:

  • With FireFox and monoboox, the second line ends in the middle of the "a" in "Lazy".
  • With FireFox and Vector, the second line ends in the middle of "D" in "Dog".
  • With IE8 and Vector, the second line ends a bit into "D" in "Dog".

I am getting some reports that with FF/Vector, the references-small line is only marginally smaller than the standard line. If anyone see this, please view and copy the HTML output here for analysis. ---— Gadget850 (Ed) talk 18:41, 2 June 2010 (UTC)[reply]

Sorry, but how does one view and copy HTML output? It just occurred to me that my edit summary, "dumb question" could be misunderstood: I meant that my question here is a novice one. --Tryptofish (talk) 18:47, 2 June 2010 (UTC)[reply]
Well, yes, what you said, but the HTML source of that text is the same. For me, the normal text is 281px wide with both FF/monobook and FF/vector. The references-small text however:
  • FF/monobook: 236px wide, computed font-size 11.433px
  • FF/vector: 261px wide, computed font-size 11.516px
That tiny difference in the computed font size (which results from a slight difference in the content font size, x-small/127% in Monobook vs. 0.8em in Vector) results in a significant size difference when the font is actually being rendered, I presume just because they are rounded differently in the font render system.
If I set the references-small to 89% instead, the Vector text looks the same as in Monobook (Windows/Firefox, without any text zoom). Didn't check how that would affect rendering in other browsers.
The exact result can always vary, depending on the font used, dpi settings, and browser/OS. If we want Vector and Monobook to look the same, we'd need to align those base skin font sizes. Amalthea 19:13, 2 June 2010 (UTC)[reply]
I have to admit that I don't entirely understand what everyone is saying here, because I'm just not that tech-savvy, but I can say that when I look at this talk thread on my system (Vector, Firefox 3.6.3), everything that Gadget and Amalthea have written in this talk thread looks the same to me, all regular Wikipedia font size, and only the part of my comment above that I put in small font looks noticeably smaller to me. --Tryptofish (talk) 19:32, 2 June 2010 (UTC)[reply]
You say that the following two lines are of exactly the same length:
  • The Quick Brown Fox Jumps Over The Lazy Dog
  • The Quick Brown Fox Jumps Over The Lazy Dog
Or is one a bit shorter? Amalthea 19:42, 2 June 2010 (UTC)[reply]
OK, actually, the second one is very slightly shorter, maybe by around 5% or so, but not anywhere near as much smaller as references were in reflist under the monobook skin. --Tryptofish (talk) 19:45, 2 June 2010 (UTC)[reply]
Let's try another test:
  • The Quick Brown Fox Jumps Over The Lazy Dog (plain)
  • The Quick Brown Fox Jumps Over The Lazy Dog (references-small)
  • The Quick Brown Fox Jumps Over The Lazy Dog (90%)
  • The Quick Brown Fox Jumps Over The Lazy Dog (88%)
What does that look like? ---— Gadget850 (Ed) talk 23:48, 2 June 2010 (UTC)[reply]
Ah, now this is looking better! First line, indeed, is plain. Second and third lines look identical to me, just like Amalthea's second line above. The fourth line looks like what I remember from reflist in monobook, and is a lot smaller looking than lines 2 and 3. Thanks! --Tryptofish (talk) 23:57, 2 June 2010 (UTC)[reply]
We haven't fixed anything yet, not have we figured out why only some people have this trouble. references-small is defined at MediaWiki:Common.css as 90%; there have been proposals to go to 88% because it did not work in IE but they all get stalled. You can fix this individually by editing your CSS:
/* Set the font size for {{reflist}} */
.references-small { font-size: 88%;}
---— Gadget850 (Ed) talk 20:36, 3 June 2010 (UTC)[reply]

Thank you very much. I did that, and it works fine for me now. For what it's worth, it's one thing to fix this for individual editors like me, but it does nothing for the experience of our real customers: the people who read Wikipedia but who do not necessarily edit it. Just my opinion, but the un-fixed display looks less professional than in monobook or after this fix. But thanks for your help to me. --Tryptofish (talk) 20:54, 3 June 2010 (UTC)[reply]

Something occurred to me (and sorry if this is technically naive). When I look at image captions in images that are formatted on pages as thumbnails, the font size in vector looks the same as it always has, without putting any kind of fix into my configuration files, and it looks the same as what the font in reflist should look like. Does that (ie, do it the same way as in thumbnails) provide a general solution? --Tryptofish (talk) 14:20, 4 June 2010 (UTC)[reply]

The simple way to fix this is to edit MediaWiki:Common.css and change references-small to 88%. This has been proposed in the past and shot down. IE currently does not show references-small at a smaller size due to rounding and there are objections to making the reference list smaller. As best I see it,references-small will work with IE9.
The other way would be to delete references-small and add a gadget to the preferences to set the size to 88%. Thus, it would be 100% by default, but can be set small. ---— Gadget850 (Ed) talk 21:15, 7 June 2010 (UTC)[reply]

Lost rollback[edit]

Resolved

Using Firefox 3.6.3 - lost rollback. Makana Chai (talk) 08:21, 17 May 2010 (UTC)[reply]

Really? Using 3.6.3 too, and I just used rollback. {{Sonia|talk|simple}} 08:32, 17 May 2010 (UTC)[reply]
Well, I have rollback in the sense that there is a button for "rollback" - but I lost AGF rollback, vandal rollback, and I am no longer taken automatically to the user's page where I have a menu of comments to leave. Makana Chai (talk) 17:04, 17 May 2010 (UTC)[reply]
That's Twinkle, then. Make sure that you've copied Twinkle from your monobook.js file to your vector.js file. SchuminWeb (Talk) 23:53, 17 May 2010 (UTC)[reply]

Search Box AutoComplete is half hidden[edit]

Resolved
 – Duplicate / extension of / caused is the same as for #Wider search box

Apart from cutting characters off, there's another problem with the search box. When I type something into it, in the drop-down list that appears, the right half of some long titles are hidden whether there is a vertical scrollbar or not. If I point at some very long titles, a tooltip shows up, but for titles of medium length, there is none and I can't find out except by clicking them. -- Karunyan, 08:31, 17 May 2010 (UTC)[reply]

See discussion above. GregorB (talk) 09:41, 17 May 2010 (UTC)[reply]

Completely blank pages[edit]

Very frequently when I access a page, it turns up completely blank. For example this just happened when I pressed "new section" to enter this report. It happens especially when requesting a "differences" page, or going back to a previous page. The same does not happen in the Monobook style. Sometimes a "refresh" will still bring up the page content, but often this has no effect. Just now pressing "preview" showed a fully blank page. Needless to say the interface is unusable this way. I have Windows7 with Google Chrome 4.1.249.1064. −Woodstone (talk) 09:56, 17 May 2010 (UTC)[reply]

More observations on this. On the blank page, the cursor shape shows that loading has finished. Sometimes I have the impression that the page shows for a fraction of a second and is then blanked over. Also, right clicking "view page source" shows the full page data. There is just something that blanks the page or suppresses rendering. It is almost consistent in the vector skin and never seen in monobook. I tried another computer with Windows XP and Chrome with the same results. It does not happen in IE8. −Woodstone (talk) 09:14, 18 May 2010 (UTC)[reply]
Please anyone comment? Am I the only one? It keeps happening very often. −Woodstone (talk) 15:35, 25 May 2010 (UTC)[reply]
It's fine on Chrome 4.1.249.1064 (45376) on XP, fwiw, based on a sample of about 50 pages. --Tagishsimon (talk) 20:06, 25 May 2010 (UTC)[reply]
It doesn't happen to me on straight page access from the main page or links. Mostly it happens on "edit", "preview" and especially on "previous page" (the back button of the browser). The latter I often use to jump back from "differences" to "history" to "watchlist". −Woodstone (talk) 20:49, 25 May 2010 (UTC)[reply]

One click revert/submit in Navigation Popups in Chrome[edit]

Resolved
 – underlying issue solved, local caching issue solved

In Chrome, I noticed that in Wikipedia:Tools/Navigation popups, when you go to actions-->revert, it's not the one step process that you expect. When you click revert, it should bring up a screen that shows the diff of your revert and says it is submitting the form automatically. This works in Firefox in vector, but it stopped working in Chrome. It still does the undo, but it doesn't submit the form on its own. If you have any questions let me know on my talk page. Thanks. --Omarcheeseboro (talk) 14:00, 17 May 2010 (UTC)[reply]

Can you bypass your Browser cache on Chrome and try again? Chrome caches pretty aggressively, so it might be that you simply haven't received the change TheDJ made in that regard. I just tried it with Chrome here and it worked for me. 93.104.73.184 (talk) 12:45, 18 May 2010 (UTC)[reply]
Thanks, seems to be working fine now. --Omarcheeseboro (talk) 12:32, 19 May 2010 (UTC)[reply]

Insert link[edit]

When I click on the chain link, the current third button from the left, it brings up the two boxes to add a target page/URL and the text to display. Something in the formatting appears to be missing here because you can't press enter, you have to manually click on "insert link" at the bottom right of the window. And a couple of times when I've done this quickly, a wikilink was created for the penultimate text which was highlighted. It's not very easy to use and I don't like how the background goes dark grey; even though that's just a matter of taste. Jared Preston (talk) 14:12, 17 May 2010 (UTC)[reply]

Or the other thing which happens, which I just had a look at in the sandbox, is when you highlight text you want to wikify, then click on insert link, which previous to the skin change simply added the square brackets around the word, you now have the same word in both boxes: 1) the word to link to, and 2) the text to show; however, when I click OK I get a pop-up warning me "You did not enter anything to link to." which isn't the case, as the chosen word is in both boxes... Seems strange to me. Jared Preston (talk) 14:18, 17 May 2010 (UTC)[reply]
Mmm. Very sucky interface. Why does the target page URL copy to the anchor line for a link to an external website? Why when external website has been selected does the thing give useless autosuggestions? Why does pressing enter twice return you to the edit screen without inserting the links? A sort of 2/10 could do much better sort of implementation. --Tagishsimon (talk) 19:35, 14 June 2010 (UTC)[reply]

Find and replace[edit]

Thanks for adding this function, which I can envisage making plenty of use of. However, I'd expect it to find an occurrence of the search string, then let me choose whether to replace that occurrence or not, like the "replace" button in Notepad or MSWord does. Apart from the background screen going so dark that I struggle to see what it's doing anyway, it seems that pressing "replace next" replaces a subsequent occurrence of the search string, which may be out of sight several screens further down the page. Is this how it's meant to work? cheers, Struway2 (talk) 14:37, 17 May 2010 (UTC)[reply]

I agree! The behavior described by Struway2 is also the default for Kate: when a occurrence is selected we expect that occurrence to be replaced, not the next one (which we don't even know if exists or where is...). The current behavior is annoying! Helder (talk) 19:37, 24 May 2010 (UTC)[reply]
Good grief. Like #Insert link, above, the UI is very poor. In addition to not being able to find then replace, the UI greys out the underlying text, making it difficult to tell whether this is an occurrence that I want to change, even did I have the choice to do that. Search & Replace is a standard function in any number of applications. It's disappointing that we've released a version which doesn't follow any of the de facto models. --Tagishsimon (talk) 19:39, 14 June 2010 (UTC)[reply]
And this is filed as bugzilla:20919, sadly from October 2009. --Tagishsimon (talk) 20:13, 14 June 2010 (UTC)[reply]

Special characters can't be inserted in subject or edit summary[edit]

Resolved
 – Reported as bugzilla:23571 - the bug listing links to a fix in MediaWiki:Edittools.js. A bug with similar symptoms but different causes, and affecting only IE, is posted below at #Edittools do not work in Internet Explorer

If I click on the subject or edit summary, so the focus is off the wikitext body, and click one of the special character buttons, the special character is inserted in the wikitext, not in the subject/edit summary. I'm using Firefox 3.6.3. Shubinator (talk) 14:55, 17 May 2010 (UTC)[reply]

I'm having the same problem (FF 3.6.3 on Win7). --Bruce1eetalk 15:03, 17 May 2010 (UTC)[reply]
By way of comparison: with Windows XP, Firefox 3.6.3 & Monobook, these buttons insert into whichever input item the cursor is currently in. Therefore it's a Vector change. --Redrose64 (talk) 15:09, 17 May 2010 (UTC)[reply]
Also an issue in IE8. Filed as bugzilla:23571. Shubinator (talk) 19:20, 17 May 2010 (UTC)[reply]
I doubt that that is a change. It has always been like that for me with Windows XP, Firefox and Monobook. Hans Adler 19:44, 17 May 2010 (UTC)[reply]
I remember inserting "→" before in edit summaries using the Monobook skin. Though now I just took a look and Monobook also has the new insert/editing toolbar and the same issue. Shubinator (talk) 19:53, 17 May 2010 (UTC)[reply]
I've had that issue as long as I can remember- but then, I've been using Vector beta since it first came out. And I wasn't a user for very long before that. {{Sonia|talk|simple}} 01:55, 18 May 2010 (UTC)[reply]
Fixed. Amalthea 12:05, 18 May 2010 (UTC)[reply]
Still having the same issue. Shubinator (talk) 02:41, 19 May 2010 (UTC)[reply]

Sonia says he's "had that issue as long as I can remember." Not me, only since the vew version of the site went up. Not being able to include arrows into edit summaries is particularly troublesome and space occupying, and I'm sure we all know that space is quite limited in there. --Tbrittreid (talk) 20:41, 27 May 2010 (UTC)[reply]

Let's make sure to explain what exactly we are all talking about.
  • The new menu bar at the top of the edit window. Whatever you choose in it will be inserted in the edit window, even if the focus is currently on the edit summary. (Some editors may have had something similar as a gadget under Monobook, but it was not a standard feature. Perhaps this non-standard feature inserted into the edit summary when the focus was there.)
  • The rectangular area below the "Save page" etc. buttons. For me it used to be the case under Monobook that whatever I entered with this function appeared in the text window, even if the focus was on the edit summary. For me nothing changed with the change to Vector. Since Amalthea's fix everything I enter from that area while in the edit summary lands in the edit summary. I am very happy about this. I never use the new menu bar anyway, and being able to use the ather function in this way is very convenient. Hans Adler 21:07, 27 May 2010 (UTC)[reply]
Excuse me, but the rest of us do indeed seem to be talking about "The rectangular area below...." which still works for the main edit window, BTW. Note Shubinator's reference to arrows in "edit summaries". The menu thing you are talking about does not work for the edit summary field either, and I wouldn't expect it to have been intended to. --Tbrittreid (talk) 21:58, 27 May 2010 (UTC)[reply]
I'm also experiencing problems with adding arrows and other characters to the edit summary from the menu displayed below the "save page" button. This has been an issue for me ever since Vector was rolled out as the default Wikipedia skin and had never been a problem before that. I'm using Internet Explorer 8 with Windows XP Home Edition (Service Pack 3) and whenever I attempt to add a character from this menu I get a pop up asking me "Are you sure you want to navigate away from this page?" So presumably instead of adding the desired character to my edit summary, clicking on this menu is having the effect of redirecting me away from the edit page. It's not a biggie but it is a little annoying and could really do with being sorted out. --Kohoutek1138 (talk) 18:53, 3 June 2010 (UTC)[reply]

My take is: fine in Firefox, borked in IE8. In IE8, I can insert a single character from the insert line into the main edit window. Trying to add a second one invokes the "are you sure you want to navigate away" message. But clicking OK on this message inserts the second character. Third & greater inserts also go through the "are you sure" message but if OK'd, do turn up in the window. With focus on the edit summary line, if I have not inserted characters into the main edit window, then nothing happens - no insertion, no message. If I have inserted a character into the main edit window, then with focus on the edit summary line, I get the "Are you sure" message and no insertion into the line. --Tagishsimon (talk) 19:33, 3 June 2010 (UTC)[reply]

Take another look at this thread. The problem being primarily discussed is that "special characters" (such as arrows) cannot be inserted into the edit summary field, not the main edit one. (BTW, the navigate away thing happens on first or second insertion.) Hans Alber can deny until judgement day that it happens to him, but it clearly happens to many of us. This is not the only thread where it has been reported. Now is somebody there will actually deal with this instead of posting either evasions or nothing.... --Tbrittreid (talk) 19:43, 3 June 2010 (UTC)[reply]
As I've just posted a message stating that I've found problems inserting into the edit summary line, I'm baffled by your contribution, Tbrittreid. --Tagishsimon (talk) 19:53, 3 June 2010 (UTC)[reply]
This section was about the problem that you could insert text from the edittools (the thing below the text area) into the main text area, but not into the edit summary. That is fixed, and works fine in Firefox/Chrome/Opera/Safari.
Internet Explorer is, as Tagishsimon says, still borked. See the section directly below for that. It's a different issue. Related, but different. Amalthea 20:05, 3 June 2010 (UTC)[reply]
I'm good with that, having tested it in FF and Chrome. This bug should be marked as resolved. The bug below, as you say, deals with the IE8 issues that neither the main edit window nor the edit summary line work correctly. --Tagishsimon (talk) 20:11, 3 June 2010 (UTC)[reply]
First post here, by Shubinator: "...the special character is inserted in the wikitext, not in the subject/edit summary." So from the beginning THIS was and is about the edit summary window problem, which remains unresolved. I was referring to the people who are supposed to reply to the reports and do something about the problems. They evade, like Amalthea, or say nothing, and the problem persists. "Check" is again deleted as inappropriate. --Tbrittreid (talk) 21:28, 3 June 2010 (UTC)[reply]
There is a perfectly fine bug report about just this behavior one section below. Why do you find it a bad idea to collect the problems with IE and edittools in one dedicated section? Lumping it in with the issue described in this section is not helping, it's confusing.
And for what it's worth, I am no more "supposed" to fix this than you are. I am here voluntarily, respond to the queries I have input for, and fix those I want. Your comment has not increased my motivation to look into problems with a browser I do not use. Amalthea 21:42, 3 June 2010 (UTC)[reply]
Tbrittreid, you're not - to my mind - helping. The bug which you yourself have highlighted - "...the special character is inserted in the wikitext, not in the subject/edit summary." - is fixed. There is another bug, in which the special character is NOT inserted in the wikitext, and that is the subject of the bug listing below.
If you have any evidence that the bug in which "...the special character is inserted in the wikitext, not in the subject/edit summary." is happening in browsers other than IE, you should reopen this bug listing. If "...the special character is inserted in the wikitext, not in the subject/edit summary." is happening in IE, I would strongly advocate centralising discussion in the bug listing below and adding a note about it there. If the bug is not happening at all, this listing should remain closed. Bug tracking systems - even ad hoc affairs like this - work much better if we can see the woods for the trees. None of this has to do with evasion, &c., and as Amalthea notes, it is a little depressing to be repeatedly beaten up when trying to help. --Tagishsimon (talk) 22:09, 3 June 2010 (UTC)[reply]

I can interpret these most recent posts only as deliberate lies. I have demonstrated conclusively that this report was from its start specifically about the edit summary field, and it appears to have been deliberately steered away from that, presumably because the authorities cannot fix it nor want to admit to that inability. It remains unresolved, Amalthea, and somebody is "supposed to fix this." If that somebody is not you, then shut up and bug off. Shubinator brought up IE in his second post here, at which point all that had been said further was to indicate even other browsers similarly "borked". IE is an issue in this thread. And Tagishsimon, absolutely nobody is helping, which is my problem. Amalthea initially put up her check by the single word "fixed" well down the thread, which was immediately followed by denials of it being fixed, and I see nothing further down to the contrary here. Lies, lies, lies. --Tbrittreid (talk) 22:32, 3 June 2010 (UTC)[reply]

Why can you not see that the was a bug which affected all browsers, and now there is a bug which affects only IE. That the current IE bug varies slightly but importantly from the one reported here. That the bug reported here is not reproducible (at least for me) in IE8, IE7, FF or Chrome nor, so far as we know, in any other browser. Why can you not see that the bug listing below covers perfectly well the remaining existing IE bug (i.e. no evasion or avoidance, merely filed elsewhere as it has a distinctive character and is in any event clearly singular to IE and not common to all browsers as this bug as). So here's the challenge: can you reproduce this bug - the one in which a special character intended for the edit summary is instead placed in the main edit window, now, in any browser? Or can you only get the IE-only bug, in which the "are you sure you want to navigate away" message gets prompted improperly, and where special characters intended for the edit summary line do not get placed in the edit summary line nor in the main edit window. --Tagishsimon (talk) 22:46, 3 June 2010 (UTC)[reply]
Because that's not what is here to see. Obviously, I am not able to do jack stuff about your interference, evasions and lies, and will have to hope I can get somewhere with the following bug report you mention. One other thing: It damned well does happen in IE8 because that's my browser and I do still have the problem. Liar. --Tbrittreid (talk) 20:31, 4 June 2010 (UTC)[reply]
Could you reassure me that you understand the difference between the two bugs, and that you have actually tested again for the bug in which a special character destined for the edit summary line ends up in the main edit window (as distinguished from the bug where the special character destined for the edit summary line just plain does not appear anywhere.) --Tagishsimon (talk) 23:50, 4 June 2010 (UTC)[reply]

Edittools do not work in Internet Explorer[edit]

split off from the above section, since this appears to be a different problem. Amalthea 21:41, 18 May 2010 (UTC)[reply]

Not resolved – This is still not working for me (using IE 7.0.6001.18000 on Vista Home Premium, SP1). I often use an en-dash in edit summaries, and it is a pain to work around. ~ Ningauble (talk) 21:27, 18 May 2010 (UTC)[reply]

This appears to be a different issue: Edittools apparently don't work at all using Internet Explorer. I note that this has been mentioned previously at the VPT.
Just tried it with IE 8.0.7600.16385, not compatibility view. Logged out, I can insert one character into the edit textarea (and only there), trying to add a second triggers the "Are you sure you want to navigate away" nuisance dialog (there is nothing more annoying than popups/dialogs triggered by laving a page, but that's a topic for a different section). Logged in, I get a javascript error:
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...])
Timestamp: Tue, 18 May 2010 21:38:07 UTC


Message: Object doesn't support this property or method
Line: 628
Char: 1
Code: 0
URI: http://en.wikipedia.org/w/index.php?title=User:Animum/easyblock.js&action=raw&ctype=text/javascript


Message: 'context.fn' is null or not an object
Line: 421
Char: 137
Code: 0
URI: http://bits.wikimedia.org/w/extensions/UsabilityInitiative/js/plugins.combined.min.js?281z63
The easyblock error is already there after page load and appears unrelated. With every call to insertTags I get a context.fn is null exception. Amalthea 21:41, 18 May 2010 (UTC)[reply]
If I confirm the "Are you sure you want to navigate away" dialog, I get the same context.fn is null error as mentioned above. Logged into a different account with no gadgets and no personal scripts, I get the same behavior as logged out (I'm just skipping the dialog since I deactivated it with my main account). Amalthea 21:50, 18 May 2010 (UTC)[reply]
To clarify(?): I am seeing two sets of tools (on my platform described above), the new ones above the main edit box (hereinafter referred to as "toolbar"), and the old ones below the save/preview buttons (hereinafter referred to as "toolbox").
  1. So, the first oddity is that both are being displayed even though they appear to be redundant: is that intentional? (BTW, I find the toolbox easier to use, fewer clicks to git 'er done; but I can see that the toolbar is more intuitive for the uninitiated.)
  2. In the context of the main edit box: both tools are working, even after multiple insertions. Only the toolbox throws the spurious navigation message.
  3. In context of the edit summary field: the toolbox throws the spurious navigation message but does not insert any text anywhere; and the toolbar inserts into the main edit box as follows: at the beginning if the last click was in the edit summary, but at a seemingly random location if the last click was on the toolbar (i.e. switching between "Advanced" and "Special characters").
I hope this helps to narrow down the problem(s). ~ Ningauble (talk) 00:38, 19 May 2010 (UTC)[reply]
Still not working. Even after disabling the message in prefs and clearing cache, a new edit window has the same problem. Whether I click on <ref></ref> below the edit box or the equivalent icon above, the only thing that happens is that focus moves to the edit cursor in the edit box. Nothing is pasted there. In effect, I'm reduced to manually typing the wikicode. LeadSongDog come howl! 16:10, 2 June 2010 (UTC)[reply]
In IE8, I can insert a single character from the insert line into the main edit window. Trying to add a second one invokes the "are you sure you want to navigate away" message. But clicking OK on this message inserts the second character. Third & greater inserts also go through the "are you sure" message but if OK'd, do turn up in the window. With focus on the edit summary line, if I have not inserted characters into the main edit window, then nothing happens - no insertion, no message. If I have inserted a character into the main edit window, then with focus on the edit summary line, I get the "Are you sure" message and no insertion into the line. --Tagishsimon (talk) 20:14, 3 June 2010 (UTC)[reply]

Well, well, well, Tagishsimon is here, too, and he's not talking about what he told me above that this bug report/thread is about.

Fact: My browser is IE8.

Fact: The "navigate away" box is annoying, but no more than that.

Fact: I have that box/message/warning with every single attempt to put a special character in the edit field, not this "not with first but with second" BS.

Fact: Every time I do anything with it or the edit summary field, the entire edit field jerks upward (via the vertical scroll bar), unless I'm working at the top, of course.

Fact: The problem Tagishsimon told me above that I'd find being dealt with here is the inability to put special characters, such as arrows, in the edit summary field. Doesn't look like it. --Tbrittreid (talk) 20:44, 4 June 2010 (UTC)[reply]

Let me quote what I said about that in my posting, above: "With focus on the edit summary line, if I have not inserted characters into the main edit window, then nothing happens - no insertion, no message. If I have inserted a character into the main edit window, then with focus on the edit summary line, I get the "Are you sure" message and no insertion into the line." That, to me, suggests that I have described a bug in which there "is the inability to put special characters, such as arrows, in the edit summary field.". I've been quite patient with you, Tbrittreid, but I must now make clear that I am finding you to be a little less than civil and a little less than rational. Your inability to see that I am reporting the bug from which you are suffering baffles me almost as much as it amuses me. --Tagishsimon (talk) 23:58, 4 June 2010 (UTC)[reply]
If it does actually add up to what I just described—and I do not see more than some similarity, nor do I see any acknowledgement of my denial of your claim of the "navigate away" warning not appearing on first special character insertion (it happened with the emdash at the beginning of this aside, and I'm sure it will happen when I close it now—(it did) then fine; let's get it dealt with, rather than everybody disagreeing about just what is and is not happening. As far as "civility" is concerned, I am sick and tired of seeing people bring it up to evade dealing with what somebody—and by no means just me—has brought up of someone's less than fair and reasonable participation in the discussion at hand. Of course, there's no reason to expect better from the other party in the dispute himself (as here), but when another party (implicitly, and sometimes expressly, an administrator) does so, that is an act or irrationality, highly detrimental to the encyclopedia. --Tbrittreid (talk) 20:27, 5 June 2010 (UTC)[reply]

Misplaced edit box on new page creation[edit]

Using Internet Explorer (as IEtab in Google Chrome).

When creating a new page, the edit box is offset so as to appear flush with the left margin, with the top of the box aligned with where the bottom of the box should be. A blue rectangle occupies the location that the edit box should appear.

Martin (Smith609 – Talk) 16:54, 17 May 2010 (UTC)[reply]

White bars on PS3[edit]

Two thick white vertical bars appear obscuring large portions of the text, the white bars come under the toolbars at the top and run all the way down the page, but they are not on special pages —Preceding unsigned comment added by Adam4267 (talkcontribs) 19:53, 17 May 2010 (UTC)[reply]

I believe this is bugzilla:23553. Shubinator (talk) 19:55, 17 May 2010 (UTC)[reply]

Missing item from toolbar[edit]

Resolved
 – Both items are available from the Insert function, sited just below the Save button.

This is a fairly minor issue, but the LaTeX <math>...</math> syntax button seems to have gone missing in the new toolbar. Is this intentional? Intelligentsium 23:40, 17 May 2010 (UTC)[reply]

And so has the button for blockquote. I guess that was intended as a simplification, but I miss it. JohnCD (talk) 17:30, 18 May 2010 (UTC)[reply]

toolbar[edit]

Resolved

Why is there a vector toolbar when editing in monobook? :( —Dark 08:05, 18 May 2010 (UTC)[reply]

You can go back to the old toolbar by unchecking the two options in Preferences → Editing → Beta features. Amalthea 12:31, 18 May 2010 (UTC)[reply]

Wider search box, again[edit]

Mr Z-man's brilliant gadget removes one of my main problems with the new interface, and has the side benefit that the EasyBlock script becomes usable again, now being anchored far enough left for its pop-out menus to be visible.

But the casual reader will not know about the gadget, and the drop-down list of suggestions that appears as you type in the search box is much less useful than before, because the suggestions are curtailed. Could the wider search box be made standard? I think that would be an improvement anyway, but if it is not possible perhaps the drop-down list could be made to expand to the left? JohnCD (talk) 19:13, 18 May 2010 (UTC)[reply]

I would second this, and urge that it be given top priority as the most blatant degradation of usability associated with this usability "enhancement". The vast majority of Wikipedia's readers are unregistered, have no intention of registering and have no wish to try to understand any technobabble about using a gadget. Let's remember who our target audience are. Phil Bridger (talk) 19:37, 18 May 2010 (UTC)[reply]
I would third this. Searching is a core facility for encyclopedia readers, which IMO ought to be given more space and greater usability than the discrete little widget that is fashionable on other types of websites. Search is a big deal in this context—give it room to work! How about adding a link to Advanced search as well, at least in the toolbox?

Also, it may just be me, but I used the old "Search" button far more often than the "Go" button, and I really miss it. I only discovered by accident that you can bring up the search page directly by clicking the icon without filling in the text field—an extra step—but even that "feature" cannot be used to open it in a new tab/window—necessitating another extra step to avoid losing one's place. (In Google's parlance, I'm usually not feeling lucky, and strongly prefer to see a list of potential candidates for what I am seeking, and/or related mentions, rather than jump directly to a page that may not be relevant.) ~ Ningauble (talk) 21:09, 18 May 2010 (UTC)[reply]

Yes, I agree absolutely with everything Phil Bridger said! This is particularly true of long names from antiquity shared by many people, or titles of European royalty: you need to see enough to glimpse the disambiguating bits at the end. I would also like to repeat loudly but politely what Ningauble said: 'I used the old "Search" button far more often than the "Go" button, and I really miss it.' Boo to the extra step. This is particularly frustrating with misguided redirects, which affect all users — that is, when an editor has decided that a term should redirect to a particular page, and maybe it shouldn't or has additional uses, and what you want to see are the other pages it appears on. Or often as an editor you're looking for what pages should (but currently don't) link to a new or existing article. Cynwolfe (talk) 15:28, 19 May 2010 (UTC)[reply]

Unnecessary white space at top?[edit]

Resolved
 – Duplicate of #Padding_about_tabs

There seems to be unnecessary white space at the top of the page; it looks spacious, but the result is noticeably less usable screen. On my 768-pixel screen {Firefox 3.5.9) the distance from the top of the screen to the line below the page header is a full 15 mm. extra in Vector. Looking at it another way, the visible height of a page, measuring from the line below the header, is 165 mm in Monobook, and only 150 mm. in Vector. Ten percent is a lot of screen real-estate to give up. JohnCD (talk) 19:39, 18 May 2010 (UTC)[reply]

I noticed that too and thought it was problematic. Karanacs (talk) 19:41, 21 May 2010 (UTC)[reply]
Same 128.232.240.137 (talk) 14:37, 29 May 2010 (UTC)[reply]

Warning message when navigating away[edit]

Resolved
 – Option to suppress warning exists in My Preferences/Editing

In the new skin, when I try to navigate away from a page with an open edit window, I get a warning message asking me to confirm that that's what I want to do. While I understand that people may do that accidentally, I for one know quite well what I'm doing when, and having to click "OK" every time is getting really old. Can't we at least add a checkbox for "Don't show this message again" or something? +Angr 21:03, 18 May 2010 (UTC)[reply]

That drove me mad at first too, but you can fix it: under My Preferences/Editing, uncheck the box marked "Warn me when I leave an edit page with unsaved changes". JohnCD (talk) 21:05, 18 May 2010 (UTC)[reply]
Thank you. It worked! +Angr 21:09, 18 May 2010 (UTC)[reply]

Cite templates again[edit]

The cite templates now work for me, but they seem to insert themselves in seemingly random locations. Brambleclawx 00:38, 19 May 2010 (UTC)[reply]

Might I also add, when I press the watchlist button, the message about adding/removing from my watchlist pushes the page down, but certain items do not move with the page, such as the Semi-wikibreak template currently on my talk page. This covers some of the content. Brambleclawx 01:36, 19 May 2010 (UTC)[reply]
I'm also having this problem, when I went to add a reference to Lucy Beale and Melissa Suffield yesterday it either wouldn't add the reference or when it did it added them in a totally random place!
If it helps, just now I am using Internet Explorer, I think version 8 --5 albert square (talk) 21:37, 31 May 2010 (UTC)[reply]

Older versions of Firefox[edit]

Resolved

In Firefox 1.0.7 (which I still use), the "Interaction" and "Toolbox" menus are only open when the edit window is. Otherwise you can't use them. Daniel Case (talk) 02:01, 19 May 2010 (UTC)[reply]

Update: This appears to have been addressed satisfactorily. But I'm still not getting the drop-down autocomplete menus. Is this a preference one has to enable now? Daniel Case (talk) 21:36, 7 June 2010 (UTC)[reply]
No longer a problem. Thanks. Daniel Case (talk) 01:19, 11 June 2010 (UTC)[reply]

Assessment script[edit]

User:WhatamIdoing/Temp.js, which I've used to assess more than ten thousand articles for WikiProject Medicine, seems to have broken during the transition. Half of it (which duplicates the assessment gadget) should go away (and any script-savvy editor is invited to do that for me), but none it seems to exist/be installed/show up/work. I have been waffling about whether I should go back to the old style to keep the script. WhatamIdoing (talk) 04:53, 19 May 2010 (UTC)[reply]

Navigation Popups no longer working[edit]

Nav Pops have stopped working since these changes. Browser: konqueror 4.2.4. Thu (talk) 09:16, 19 May 2010 (UTC)[reply]

Search box[edit]

I don't know if it's because I use a low resolution, but on some pages, like when I'm editing right now, the search box floats in weird places. It's below the "read edit view history" tabs right now for me. I'm also using one of the newer builds of Chrome, if that matters. - Peregrine Fisher (talk) 15:49, 19 May 2010 (UTC)[reply]

Drop-down menus[edit]

Resolved
 – Support for Vector has been added to both the gadget and stand-alone scripts

I use the User:Haza-w/Drop-down menus script but it din't seem to be working in the new skin. It's only enabled via my preferences, I haven't added it to a .js page and I'm in the latest version of Chrome, running on windows Vista. HJ Mitchell | Penny for your thoughts? 17:03, 19 May 2010 (UTC)[reply]

Support for Vector has been added to both the gadget and stand-alone scripts. Apologies for the delay. haz (talk) 22:15, 31 May 2010 (UTC)[reply]

Unusable under MacOS 9[edit]

With Classilla 9.1 (2010) the navigation on the left is no more acessable. So the languages cannot be reached at all! One of the most important features of Wikipedia. With iCab (2008) the languages are expanded by default, but therefore the page is completely unusable! It takes up to one minute before a page is shown at all @ G4 1,4 GHz! None of the links works correctly, you cannot access the search field etc. To me it seems like a batch of ugly JavaScripts is confusing iCAB. So Wikipedia became useless for MacOS 9 at all! 1:30, 20 May 2010 (CET) —Preceding unsigned comment added by 78.142.164.65 (talk)

Iceweasel Black lines[edit]

I posted this elsewhere, but apprently the discussion is centralising here? Black lines across top of all wiki pages [1], (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100308 Iceweasel/3.5.8 (like Firefox/3.5.8)) 129.67.86.189 (talk) 10:43, 20 May 2010 (UTC)[reply]

The image you point to is no longer available. This bug report is less useful in its absence. --Tagishsimon (talk) 12:38, 2 June 2010 (UTC)[reply]
Someone else has the same problem further down [2]. For me the lines extend across the whole page 129.67.86.189 (talk) 16:12, 2 June 2010 (UTC)[reply]
So it's the black lines around Main page, Discussion, View Source, View History in the second example, and you get some more besides? thanks. --Tagishsimon (talk) 16:16, 2 June 2010 (UTC)[reply]
More info. This also happens under firefox ( Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100317 SUSE/3.5.9-0.1.1 Firefox/3.5.9) if (and only if) I use CTRL + scroll to zoom in, however the positioning for the black lines is dependant upon zoom level, but is usually highlighting one of the borders of the tabs. I think this is to do with screen size, as the full width black line only happens at very high zoom levels on a big dell monitor, but the black lines happen at the default zoom in iceweasel on my netbook. 129.67.86.189 (talk) 19:05, 13 June 2010 (UTC)[reply]

Missing cursor in edit boxes[edit]

Resolved
 – As probable firefox bug

Hello, I am using Firefox 3.6.3 and when I edit an article, the cursor does not show up at all. This makes it really tricky to perform multiple edits on long articles. But this problem does not happen when I edit Project or User Talk pages. - S Masters (talk) 15:07, 20 May 2010 (UTC)[reply]

That's almost certainly a Firefox bug. I have that in Monobook as well, from time to time. For me, it's always enough to task switch to some other application and back to get the text cursor to reappear. Amalthea 15:13, 20 May 2010 (UTC)[reply]
Thanks, that solved my problem (switching to another program and returning). Cheers. - S Masters (talk) 02:39, 22 May 2010 (UTC)[reply]

IE 6 freeze[edit]

Every time Internet Explorer 6 loads a page with Vector skin, it freezes for nearly ten seconds. That doesn't happen with Monobook. Is there any way to find out what causes this? 88.85.134.42 (talk) 22:31, 20 May 2010 (UTC)[reply]

QuickEdit 2.4 tab to summary[edit]

Pressing tab from the edit box used to go to the edit summary box when using QuickEdit, but now it doesn't (goes to search box instead). Rjwilmsi 11:02, 21 May 2010 (UTC)[reply]

Tools that don't work which haven't been listed so far[edit]

The peer reviewer tool doesn't work User:AndyZ/peerreviewer.js neither does, User:GregU/dashes.js or User:Pyrospirit/metadata/projectbanners.js, which normally has drop down list of all project banners which can be opened on article page rather than talk page, thanks Tom B (talk) 11:25, 21 May 2010 (UTC)[reply]

I have the same issue - however it was working after I moved the script to the Vector page. It stopped working for me a couple of weeks later. --Jeremy (blah blahI did it!) 17:53, 19 June 2010 (UTC)[reply]

Revert via nav popup does not prompt for edit summary[edit]

Resolved

Under the old skin, when selecting an old version from the history page and reverting to it, the script would prompt you for an edit summary. Under Vector, the prompt no longer appears. Instead, it goes straight to "the save button has been pressed automatically." —C.Fred (talk) 12:58, 21 May 2010 (UTC)[reply]

That's because you haven't copied the configuration option that does that from User:C.Fred/monobook.js to User:C.Fred/vector.js.
You should throw out the document.write line, by the way, if you have activated popups in your Gadgets. Amalthea 13:43, 21 May 2010 (UTC)[reply]

Bug concerning opening search result in new tab in Safari[edit]

I'm using Safari 4.0.5 under MacOS X 10.6.3. When I type a search term into the search box, I can no longer hit command-shift-return to accept the search and open a new tab in the browser. Instead, it pauses briefly and opens the results of the search in the current tab. Command-shift-clicking links still opens in a new tab. Using Command-option-return to open it in a new window in the background, or Command-option-shift-return to open in a new window in front, are both affected as well. The only way I've found that works to open the search result in a new tab is to command-click (or the other variants) the magnifying glass icon. Imzadi 1979  14:24, 21 May 2010 (UTC)[reply]

I'm experiencing this same problem, except that it's opening a new tab from a search window using command click (or command return), and it affects both Safari and Firefox. Vector only - this works if I go back to monobook. --Ludwigs2 00:05, 6 June 2010 (UTC)[reply]
I have this problem in both Firefox and Google Chrome: see #Anti-new-tab behavior in suggestions below. Almost certainly to do with what JavaScript function is being used to choose a new page. --Closeapple (talk) 19:12, 14 June 2010 (UTC)[reply]
Regarding the pause before opening the page, for me in Safari I get nothing for as long as I keep holding the Command key. When I let go, it goes. So the JavaScript is trapping my keystroke the wrong way. MJ (tc) 15:13, 16 June 2010 (UTC)[reply]

Two other problems[edit]

I have two problems which began immediately upon the appearance of the new version.

  1. And less important: Navigation popups have become quite sluggish. On many occasions I have to pull my cursor off the link and return it multiple times before I can see more than the title and headers.
  2. I have real problems with Wiki markup and insert. I invariably get a popup asking me if I want to navigate from the page, which is patently irrelevant. When I click on cancel and the popup disappears, I never know if the intended mark will appear, or if in the proper place; sometimes it goes to the starting corner of the edit window. Furthermore, such things wil not appear in the edit summary field at all. I never use arrows in an article, but frequently have in edit summaries, to demonstrate before and after my edit. --Tbrittreid (talk) 20:13, 21 May 2010 (UTC)[reply]

Search unusable in Palm Blazer[edit]

There is no more search button, so there is nothing to click when using Palm Blazer. I'm guessing older browsers and other phones have similar problems. The Palm Treo enter button seems to do nothing. ▫ JohnnyMrNinja 09:28, 22 May 2010 (UTC)[reply]

Invalid HTML code[edit]

According to the W3C Markup Validation Service, the new design causes invalid HTML code, as you can see at http://validator.w3.org/check?uri=http://en.wikipedia.org/wiki/Main_Page TootsieStanford (talk) 00:57, 23 May 2010 (UTC)[reply]

Search bar does not allow pasting from right-click[edit]

The new search bar does not let you right-click where it says "search" to paste (at least in Firefox), instead it brings up normal page navigation options. You have to left-click for the word "search" to disappear, and then right-click. You could also just click further to the right (in the whitespace) and it works normally, but it's a little counter-intuitive. ▫ JohnnyMrNinja 10:16, 23 May 2010 (UTC)[reply]

Not just Firefox: this was also reported using IE7 (item 3). It actually does work eventually, but is inconsistent. If you wait long enough after the page renders (and/or right click repeatedly, which amounts to the same thing) then the text box will respond to a right-click. It apparently takes a while for the JavaScript to enter a state where it will listen to this mouse event. One user suggests a possible program fix here. (Note to programmers: Try testing this over a dialup connection. I think the client-side JS is making too many demands on server-side data to be responsive.) ~ Ningauble (talk) 12:43, 23 May 2010 (UTC)[reply]
For me in Firefox 3.6.3, when I right-click on the white area of the search box, I see the expected "Cut, Copy, Paste" context menu. However, the generic "Back, Forward" context menu appears for me when I right-click on the word "Search". This is a bug, but it has a simpler workaround. — This, that, and the other (talk) 10:49, 24 May 2010 (UTC)[reply]
This may help: First left click the box so that "Search" is gone and the cursor can be seen in the box and then right click and paste. That was what you had to do in IE8 anyway. ~ R.T.G 12:25, 24 May 2010 (UTC)[reply]
Ah ha, in IE7 I see the same thing "This, that" describes. So I was mistaken: it does not depend on when you click the search box, but where you click within the box. Knowing this, I can now work around the problem without an extra click; and knowing what causes it, the programmers should now be able to fix the bug. ~ Ningauble (talk) 12:37, 24 May 2010 (UTC)[reply]
This has been reported as bugzilla:24096. ~ Ningauble (talk) 18:40, 23 June 2010 (UTC)[reply]

Widen the edit box to fill the entire screen[edit]

Doesn't work - edit box is limited to right side, does not extend into the sidebar. kcylsnavS{screechharrass} 15:51, 23 May 2010 (UTC)[reply]

Yeah, it's not supposed to (and not a vector issue). If we can come up with a better text for that option, we could place it in MediaWiki:Tog-editwidth and ask for a dev to change it in MediaWiki. I can only come up with "Widen the edit box to fill the available space". Alternatives? Amalthea 12:18, 25 May 2010 (UTC)[reply]

Bottom tabs not working[edit]

Help:User style/bottom tabs are not working. A fix would be excellent. Providing bottom tabs by default would be better still. thanks. --Tagishsimon (talk) 23:30, 23 May 2010 (UTC)[reply]

Sample image - broken link in IE8[edit]

In the new edit toolbar, under Help > Files, the sample image fails to appear in Internet Explorer 8 (a broken link icon appears in its place). The correct URI is http://en.wikipedia.org/w/extensions/UsabilityInitiative/images/wikiEditor/toolbar/example-image.png, but IE is referencing http://en.wikipedia.org/wiki/extensions/UsabilityInitiative/images/wikiEditor/toolbar/example-image.png, for some reason. — This, that, and the other (talk) 10:57, 24 May 2010 (UTC)[reply]

I have reported this as bugzilla:23645. —TheDJ (talkcontribs) 23:14, 25 May 2010 (UTC)[reply]
Problem cannot be reproduced. 130.89.112.183 (talk) 18:28, 15 June 2010 (UTC)[reply]

Incompatible with IE5.5 browser (and other legacy browsers) – why no backwards compatibility?[edit]

Vector results in very slow loading, with a microscopic 2pt screen font. Pages seemingly freeze for more than two minutes over a 56k dial-up connection. This was worked around by reverting Vector to MonoBook.css in "My Preferences", but for unregistered users with older browsers who do not have this workaround option, Vector is terrible. For registered users, style changes should not override settings which the user prefers and has previously selected/saved.  JGHowes  talk 11:37, 24 May 2010 (UTC)[reply]

You can try to use the mobile version instead. It is much simpler HTML. FYI, IE 5.5 is specifically NO longer supported. IE 6 is the minimum browser version that is supported for Wikipedia. Full functionality is only supported for latest generation browsers. —TheDJ (talkcontribs) 20:40, 25 May 2010 (UTC)[reply]
The "mobile" version is a joke, there is no way to login (using IE6). Q Science (talk) 20:22, 28 May 2010 (UTC)[reply]
The current version of IE is, and for quite some time has been, "8" which works fine. Wake up and upgrade. --Tbrittreid (talk) 20:54, 28 May 2010 (UTC)[reply]
It also does not work with IE8 or Firefox 3.5.9. I was testing in IE6 because that is what we claim to support. Q Science (talk) 21:09, 28 May 2010 (UTC)[reply]
I was under the impression that "Vector" is simply the term for the new version of Wikipedia (the earlier being Monobook). If so, it works with my IE8; if not, what is it? --Tbrittreid (talk) 21:21, 28 May 2010 (UTC)[reply]
How difficult can it be to tell me whether I'm right or wrong about what Monobook and Vector mean? Could it be that I am indeed correct and Q Science simply doesn't want to be confronted with being wrong about it not working in IE8 at all? I'll concede that the new version functions in a less than totally perfect manner in my IE8, but I am certainly getting along. --Tbrittreid (talk) 22:53, 29 May 2010 (UTC)[reply]
It's a new look, see WP:Skin. Amalthea 23:10, 29 May 2010 (UTC)[reply]

Sorry, but the page you linked in is beyond my comprehension. Are Monobook and Vector the respective names for the old and new versions of Wikipedia, yes or no? --Tbrittreid (talk) 23:24, 29 May 2010 (UTC)[reply]

Version is too broad. Monobook and Vector are the names of the old and new default looks (=skins) of Wikipedia. Wikipedia is still more or less the same (although there are made changes to the underlying software every day, which are put live here from time to time), and you can choose which look it has in your preferences. Amalthea 23:52, 29 May 2010 (UTC)[reply]
Tbrittreid, your "wake up and upgrade" jab misses the point—not everyone can upgrade to IE8, such as those folks who have older, less rebust PC's or OS that can't use IE8 (pre-Windows XP). Not everyone is using Windows Vista with the latest browsers/monitors, you know. My concern is that Wikipedia is supposed to be accessible to the widest possible global readership. As a registered user, I've already reverted to monobook (as I said at the outset), but the concern remains valid for anon IP's and those who aren't that technically savvy, and can't go back to the monobook interface. Because the WMF got a grant for the Usability Initiative to develop and implement Vector, it seems contradictory that Vector's end result is less usability. There should be more attention given to backwards compatibility.  JGHowes  talk 00:31, 30 May 2010 (UTC)[reply]
IE 5.5 is nearly 10 years old and hasn't been supported by MS for years. Many other sites have begun dropping IE6 support already (Gmail, Youtube, Amazon, Digg). Only about 0.09% of Wikimedia users use IE 5.5, so the extra work and testing required to make the new skin compatible with it was likely deemed to be not worth it (it could also result in fewer changes for everyone else to reduce incompatible changes or worse performance for everyone else due to additional code for compatibility checks). Mr.Z-man 01:59, 30 May 2010 (UTC)[reply]
Bottom line: I was correct to contradict Q Science's flat statement that Vector "...doesn't work with IE8...." There is certainly room for improvement, but that falls far short of "not working." There must be something else in his computer causing additional problems with it, unless he is vocabularily challenged (speaking strictly hypothetically and covering all possibilities, not trying to be insulting). Thanks.
Note to JGHowes: Anybody who can't upgrade to the current version of their chosen browser should chose another one. --Tbrittreid (talk) 21:35, 30 May 2010 (UTC)[reply]
And how on earth does a user of a locked down business or educational machine do that. I have IE7 on my business laptop with no possibility whatsoever of upgrade or loading firefox. It is not ever good enough to say "the client must change to suit our shortcomings". --Tagishsimon (talk) 13:54, 1 June 2010 (UTC)[reply]
User:Mr.Z-man, as noted elsewhere on this page, there are also issues with using Vector with IE6 and older Firefox browsers, as well. I've tested IE6, too, and found very slow page loading, unresponsive cursors, font size issues, etc., with that as well. Including IE6 jumps the number of affected Wikipedia users to more than 8%. Since Wikimedia already uses browser detection, as your reference demonstrates, it would seem to be a relatively straightforward step to simply add a line of metacode so that if IE6 and below and older Firefox browsers are detected, the monobook interface is loaded instead of Vector.  JGHowes  talk 13:36, 1 June 2010 (UTC)[reply]
It is not that simple. For one, the browser detection is done by parsing server logs, not in real-time. It also results in cache fragmentation and could, theoretically, double the size of the cache. IE6 is supposed to be supported, any bugs with it should be reported to Bugzilla (or reported here with sufficient detail). I'm not sure what the oldest version of Firefox supported is. Mr.Z-man 21:53, 1 June 2010 (UTC)[reply]

There used to be 2 search buttons now there is only 1[edit]

Resolved
 – UI change

There used to be a "Search" button and a "Go" button so you could go to the page or you could search for the text. This was a very handy and simple feature. Now to access the search I must enter something in the search box that doesn't have an article. Please give us back the two search options thanks. ~ R.T.G 12:28, 24 May 2010 (UTC)[reply]

If you look at the bottom of the autosuggestion dropdown list that appears when you type into the search box, you'll se the last entry is preceded by the word "containing". The idea seems to be that if you want to do a free text search for the search string (i.e. the old "Search" button behaviour) you select this; otherwise select one of the other terms to be taken to the article page (i.e. the "Go" button behaviour. --
Also, is it just me or is the text much smaller? I am using a 1920 x 1080 screen and IE8. I have put the text size to largest in the last few days. Now my wiki signature is larger than the other text but before it was smaller and other sigs here look bigger too. ~ R.T.G 12:32, 24 May 2010 (UTC)[reply]

Tiny font for times of entries in Watchlist[edit]

When I go to my Watchlist I usually know roughly what time I last looked and so need to be able to quickly read the time in the left-hand column to see where to start reading for new changes. But it's now a strain to read it - using Mozilla Firefox, a laptop, and 50-something eyes with varifocal glasses. Could the time go back to a sensible size of font, please? PamD (talk) 13:05, 24 May 2010 (UTC)[reply]

This was also mentioned further up the page in the font size issues section. I, too, find it difficult to read, even with my 30-year-old 20/20 eyes. –BMRR (talk) 15:27, 24 May 2010 (UTC)[reply]
On Commons watchlist, not-yet-seen changes are bolded. I think this would be useful here too. Derlay (talk) 11:04, 25 May 2010 (UTC)[reply]
IMO the HTML formatting of Watchlists is a very poor use of tables. This is not new with Vector, of course. Where should I go to discuss this sort of thing? This is something that can’t be hacked with user style. MJ (tc) 15:23, 16 June 2010 (UTC)[reply]

Visited link colour[edit]

The dark blue for a visited link seems very easy to confuse with black nowadays, and I don't remember this problem with the old setup. If the colour has been changed, I'd vote for changing it back. Using Mozilla Firefox on a laptop. PamD (talk) 13:10, 24 May 2010 (UTC)[reply]

The color in monobook is purple, and in vector it is dark blue (slightly edging towards purple). —TheDJ (talkcontribs) 13:43, 24 May 2010 (UTC)[reply]
I've noticed that the new colors for visited links and unvisited links are difficult to tell apart. The difference is noticeable, but not as easily noticeable as it was before the changeover. I find this particularly annoying when viewing page histories and trying to determine which diffs I've looked at and which ones I haven't. –BMRR (talk) 15:31, 24 May 2010 (UTC)[reply]
I use the black/green skin and the Main Page link goes dark blue after I visit it which makes it more difficult to see against the black background. Other links in the body of the text are still a sort of indigo colour that they always were. I think the dark skin is very useful if you have a large screen and you want to keep the heat level down when spending a long time looking at pages of text. ~ R.T.G 18:15, 24 May 2010 (UTC)[reply]

Picture format[edit]

Hi, I was just looking at the article Roxann Dawson and the first break line under the title "Career" goes right through the portrait. I am using IE8 with text set to largest resolution 1920 x 1080 and monobook (green and black) skin. Don't know if that is because of the new skin or what. Will report if I see it on any other pages. ~ R.T.G 16:41, 24 May 2010 (UTC)[reply]

Yes on National Lampoon's Animal House the break line of the first heading also goes right through the infobox but on most articles it is just normal. ~ R.T.G 16:43, 24 May 2010 (UTC)[reply]
I'm seeing the same thing on IE7. --Tagishsimon (talk) 12:42, 2 June 2010 (UTC)[reply]

Signature & Timestamp inserted in wrong place[edit]

When I want to place a signature & timestamp at the end of my posts, I put my cursor to the end of the sentence, and click on the Signature & Timestamp icon, then press the "Save page" button. However, if I use my browsers scroll slide to bring the icon into view, the cursor moves from end of the sentence to the top of the edit area. In short, I think the editing page looses focus when you click outside of the Wikipedia to your browser (I have IE 7.0). Is this an issue anyone else is having? --Gavin Collins (talk|contribs) 13:39, 25 May 2010 (UTC)[reply]

It's not just the signature button. The new tools seem to lose track of the cursor in other situations too, as described above. ~ Ningauble (talk) 14:35, 25 May 2010 (UTC)[reply]

Revision History issues for admins[edit]

Using IE6 browser and upon selecting radio buttons to compare two page versions, clicking Compare selected versions produces only "Invalid target revision" error message. Please note: this bug manifests itself only for those with admin tools, causing a conflict with the newly added RVDL function added May 18. When I logout (thus removing my admin buttons and Rev/Del from the History page), page history version comparison functions normally. Because this problem also manifests using monobook, it may be a RVDL implementation issue instead of Vector-related, so I've reported this problem there as well. JGHowes  talk 15:52, 26 May 2010 (UTC)[reply]

Spurious monobook pages[edit]

Very occasionally, when editing, reverting, etc, a page will show up in monobook skin - a refresh is enough to redisplay it as vector. I've been trying to get a handle on when and how it happens, but I have no idea - it only started happening a couple of days ago (I think), and has not happened yet today. (Using Mac OSX 10.5.8, Firefox 3.6.3) -- Boing! said Zebedee 18:07, 26 May 2010 (UTC)[reply]

See WP:VPT#Halfway between vector and monobook?. Brambleclawx 22:59, 26 May 2010 (UTC)[reply]
Ah, great, thanks -- Boing! said Zebedee 23:10, 26 May 2010 (UTC)[reply]

Cite templates behaving oddly[edit]

Using Firefox 3.6.3, with "reftools" ticked under Gadgets in Preferences, the citation templates behave oddly. When I click the calendar for the accessdate, the screen behind the citation box goes almost black. Under some circumstances the templates drop-down has refused to drop - eg if I've clicked on "Cite" a second time so that the bar including the drop-down menu has disappeared, then I've clicked it a third time to retrieve it and the dropdown doesn't drop. Seems a bit fragile. PamD (talk) 22:51, 26 May 2010 (UTC)[reply]

I can't replicate the first bug. Note that, by default there should be a dark background all the time when using the cite dialogs, or any dialog in the toolbar (link, search & replace). The second bug is bugzilla:23541. Mr.Z-man 23:47, 26 May 2010 (UTC)[reply]

Inserting special characters[edit]

When I insert special characters using the toolbar under the edit window, I receive the "Are you sure you want to navigate away from this page?" message. Clicking "OK" will simply insert the special character without any change, but it would be nice to not encounter this message each time. -- Black Falcon (talk) 01:00, 27 May 2010 (UTC)[reply]

I don't get that message and the characters are inserting correctly. I'm using FireFox 3.6.3 on Windows 7. --Bruce1eetalk 07:58, 27 May 2010 (UTC)[reply]
See also #Edittools do not work in Internet Explorer. You can disable the "navigate away" message in your Preferences → Editing → "[ ] Warn me when I leave an edit page with unsaved changes", FWIW. Amalthea 10:36, 27 May 2010 (UTC)[reply]
Thanks for the link (and, yes, I'm using IE). I don't want to disable the "navigate away" notice altogether since I've found it to be quite useful under normal circumstances. (Who hasn't accidentally navigated away from an edit window and lost all their changes...?) I'll follow the discussion to which you linked, since it seems to be virtually the same issue. -- Black Falcon (talk) 20:00, 27 May 2010 (UTC)[reply]
Also using IE. Agree with all of Black Falcon's comments here. Hordaland (talk) 07:21, 30 May 2010 (UTC)[reply]

The GUI for adding links[edit]

  1. When I try to add a link to user page with a (.) in the user name, the GUI reads the link as an external link. For example, try adding a link to User:Pascal.Tesson's page using the GUI.
  2. I have to always manually add links to the Subject/headline, when starting a new topic in a talk page. In the main box where you enter text, you can add a link by selecting the text and clicking on the link button. This is when the GUI appears with the selected text entered by default in both the "Target page or URL" field and "Text to display" field. In case of the Subject/headline field, this feature does not work, i.e. the selected text does not appear on the fields of the GUI.--Nilotpal42 14:04, 27 May 2010 (UTC)[reply]

Lupin's anti vandal tool[edit]

Lupin's anti vandal tool does not work in vector.--EvilFlyingMonkey (talk) 03:59, 28 May 2010 (UTC)[reply]

Doesn't work for me either. Kayau Voting IS evil 10:16, 13 June 2010 (UTC)[reply]

My particular problem ...[edit]

Resolved
 – Problems are outwith the scope of this RfC

... evidently exists between chair and keyboard, as I have no understanding as to what this message means: "If you are still experiencing any problems related to the change from Monobook to Vector, such as broken gadgets or interface glitches, please report them." I suppose it means something to somebody, but why I received it, I'll never know. I even looked up "monobook" and was redirected to a totally unhelpful Help page. I think I know what a vector is (a mathematical quantity having both magnitude and direction), but the only broken gadget I have is a ceiling fan on the chain of which my wife pulled too hard, reducing its function to that of a ceiling light.--BillFlis (talk) 19:09, 28 May 2010 (UTC)[reply]

See WP:Skin. But if you didn't notice any regressions, just don't worry about it. Amalthea 10:09, 29 May 2010 (UTC)[reply]

Monobook Edit Problem[edit]

Monobook in IE6 no longer works. When editing text, pressing Show Preview used to allow me to continue editing without having to relocate the last item I typed. However, now it places the edit cursor to the second line of text. When there is a long section, it takes a while to find where I was editing. Q Science (talk) 20:36, 28 May 2010 (UTC)[reply]

prosesize.js[edit]

Resolved
 – Add it to your vector.js

I can't find the prose size tool any more. It used to appear in the bar on the left, if you installed it by adding importScript('User:Dr_pda/prosesize.js'); // User:Dr_pda/prosesize.js to your monobook.js, and was recommended at WP:FAC as a tool to determine an article's prose size. --JN466 00:07, 29 May 2010 (UTC)[reply]

If you now use Vector, you'll need to add it to your vector.js. Did that for you. Amalthea 10:00, 29 May 2010 (UTC)[reply]
Thank you. --JN466 15:46, 29 May 2010 (UTC)[reply]

Adds pages to watchlist despite unchecked box[edit]

Resolved

In my preferences, under "Watchlist", the box for "Add pages I edit to my watchlist" is definitely unchecked, yet pages are being added. - Special-T (talk) 02:08, 29 May 2010 (UTC)[reply]

Not a vector issue. But which pages, for example? Amalthea 10:04, 29 May 2010 (UTC)[reply]

I keep removing them manually, so I can only see the most recent one - Espresso machine, which I edited yesterday. Before that, it seemed that all pages I edited made it to my watchlist (user talk pages and articles). I just edited Nueva Era, but it didn't show up on my watchlist, though, so it's not consistent, and maybe has been resolved. I have no idea what the issue is, but it started when the new look took effect. - Special-T (talk) 14:22, 30 May 2010 (UTC)[reply]

Seems to only happen when using Twinkle. - Special-T (talk) 19:54, 31 May 2010 (UTC)[reply]

Twinkle by default watchlists most pages you edit. You configured it not to in your monobook.js, but not in the script file of the new skin, your vector.js. I copied it over, should work for you now (might need a browser cache bypass, but probably not). Amalthea 20:09, 31 May 2010 (UTC)[reply]

Wow, thanks! That's all a bit over my head, so I appreciate the assist. - Special-T (talk) 20:03, 1 June 2010 (UTC)[reply]

Hate vector skin[edit]

Resolved
 – "I hate it" is not a bug. Take it to usability.wikimedia.org/wiki/Your_Opinion

I hate this. I went back to monobook, the vector reftools are broken and I have to go back to the old one, and I don't like the way vector looks. Basically, it sucks. What's the whole reason for this misguided change anyway? RlevseTalk 02:39, 29 May 2010 (UTC)[reply]

Do you have a specific bug to report? Shubinator (talk) 00:24, 30 May 2010 (UTC)[reply]
His bug is that he think Vector is inferior to Monobook. Just because it's a general assessment doesn't mean it's worthless. I also agree with him. The look and feel of Vector is not as good as with Monobook. It feels too cold. Too sterile. Jason Quinn (talk) 01:08, 30 May 2010 (UTC)[reply]
No, it's not worthless. But this is a page for bug reports, and from a dev point of view, just saying "I hate it" is not actionable. Take it to a policy page where such things are discussed. Shubinator (talk) 02:01, 30 May 2010 (UTC)[reply]
"It feels too cold" is a descriptive complaint – something that can (potentially) be fixed. "It sucks" is a purely subjective note with no description attached. "reftools are broken" is a bug report, but without more information is just as unactionable. Mr.Z-man 02:12, 30 May 2010 (UTC)[reply]
I reported the reftool thing. Cite journal was missing from it. Why? I hate the overall look, feel, and navigation of vector. For example, I'm forced to use it when I first hit wiki before I log in and the search box is in the upper right. I like it where it was. And yes, it has a cold feel to it. Anbd with all the bug reports on it, it was obviously rushed into release before it was ready. Was MicroSoft part of this ;-) RlevseTalk 11:12, 30 May 2010 (UTC)[reply]
Note that I added cite journal to the script for the new toolbar a few days ago. Mr.Z-man 14:55, 30 May 2010 (UTC)[reply]
I think GUI design flaws, such as a layout looking much cleaner at first glance but lacking in navigation ease and feel (seeming empty, "cold," "sterile") for some users, can be taken and talked about as a bug. It's way actionable. Voting with my preferences tab, I also went back to monobook within hours of vector showing up. Gwen Gale (talk) 11:52, 30 May 2010 (UTC)[reply]
Go Gwen Go!RlevseTalk 15:43, 30 May 2010 (UTC)[reply]
Been there; done that. It's not as if usability initiatives have not run into serious push back in the real world before. I don't like a lot of vector and certainly don't use it for more than brief experiments. Lot of this is buggy and a lot is about giving undue weight to n00bie fumbling at the expense of robust functionality being on-offer to experienced hands. I'm not sayin' no-weight to such concerns, just to not fuck things up for the rest of us. Cheers, Jack Merridew 16:55, 30 May 2010 (UTC)[reply]
Go Jack Go!RlevseTalk 19:07, 30 May 2010 (UTC)[reply]
I didn't realize Arbcom turned into a cheerleading squad...a bug perhaps? Shubinator (talk) 20:58, 30 May 2010 (UTC)[reply]

I liken this to the new coke fiasco, its my belief that many are unhappy with the change despite the belief in some minds that it will be "new skin or no skin" for Wikipedia. TomStar81 (Talk) 08:33, 31 May 2010 (UTC)[reply]

Another search box issue: missing redirects[edit]

I use Firefox 3.6.3. I've noticed that when I start typing into the new search box the name of a page I am searching for, the names of common redirects that used to come up in the past do not appear. If I type out the name of the redirect and click the magnifying glass search icon, it acts as though there is no such page, but then displays the correct target page. In the past, the redirect would display in the search box, and going ahead to it would go directly to the target page, which I think was easier. --Tryptofish (talk) 18:45, 29 May 2010 (UTC)[reply]

Message over-writes text[edit]

When I add a page to my watchlist, or remove one, the message that this act has been accomplished overwrites the top of the article. Annoying -- looks sloppy. --Hordaland (talk) 05:01, 30 May 2010 (UTC)[reply]

Using IE. --Hordaland (talk) 07:30, 30 May 2010 (UTC)[reply]
Yup. IE7 has this issue. --Tagishsimon (talk) 12:43, 2 June 2010 (UTC)[reply]
I have the same issue using XP and IE8. No problem with Chrome, Firefox, Opera or Safari. Regards, Lynbarn (talk) 22:57, 3 June 2010 (UTC)[reply]

Are you sure that you want to navigate away from this page?[edit]

Resolved
 – Duplicate of #Inserting_special_characters, above

Below the edit box is a box of symbols on which one can click to insert a symbol into one's message. It used to work without any "error" message. Now I get the message you see in the title of this comment. The insert works, but a message like that is a bit scary and wholly unnecessary. Using IE. --Hordaland (talk) 05:07, 30 May 2010 (UTC)[reply]

See the discussion above at this heading. Orderinchaos 05:34, 30 May 2010 (UTC)[reply]
I pitched in there, thanks. --Hordaland (talk) 07:29, 30 May 2010 (UTC)[reply]

Preview of diff[edit]

Resolved

Used to be I could see a preview of a diff by mouse-over the word diff on my watchlist. Saved many a click and many a wait. Doesn't work anymore. Using IE. --Hordaland (talk) 05:11, 30 May 2010 (UTC)[reply]

Copy and paste the contents of your monobook.js into your your vector.js. Shubinator (talk) 05:30, 30 May 2010 (UTC)[reply]
Tried that, with fingers crossed, and it worked! Thank you. --Hordaland (talk) 07:28, 30 May 2010 (UTC)[reply]

Calling attention to an old one[edit]

Resolved
 – Duplicate of #Non-responsiveness to keyboard shortcuts. It is not helpful to have two sections for a single bug.

As far as I know, #Non-responsiveness_to_keyboard shortcuts remains unactioned. Has any work been done on this? (I forgot to note I use Firefox 3.6.3.) Orderinchaos 05:36, 30 May 2010 (UTC)[reply]

Page load time is now horrid[edit]

I am running an extremely fast computer on a fast DSL server and before these changes wiki used to load in a fraction of a second. Almost instantanous. Now I find myself staring at a blank screen forever before the pages load wondering if I got kicked off line or if my web browser crashed. There is nothing to indicate any activity (as all I see is a blank white area in my browser workspace) until the page shows up. For example a preview of this comment took about 14 seconds to appear, whereas before these recent changes, I would hit preview and boom there it was.Davidtfull (talk) 05:53, 30 May 2010 (UTC)[reply]

Logout error[edit]

I've set up my computer for automatic login. In the last couple of days, I consistently find myself having been logged out every time that I bring up the browser when it's been closed for a while. Not sure if this is a skin transition issue, but it's never happened before. I'm still running Monobook, simply because I like it better, and my browser is IE 8.0.6001.18904 running on a Windows Vista computer. Nyttend (talk) 13:42, 30 May 2010 (UTC)[reply]

Not sure if this is to blame, but...[edit]

Resolved
 – Skin-specific code

...ever since the switch my three picto-buttons have been misaligned. I though it may just be the announcements at the top of article pages (that has been the cause previously), but the problem persists. The code I'm using to display the picto-buttons is listed below, if that helps. Anything you can do to shed some light on this would be appreciated. TomStar81 (Talk) 08:16, 31 May 2010 (UTC)[reply]

<div style="position:absolute; z-index:100; right:40px; top:0px;" class="metadata"> {| style="background-color:transparent;border: 0px" |- |{{click|link=Wikipedia:WikiProject Military history|image=Triplechevron gold.png|width=30|height=30|title=This user is a member of the Military history WikiProject.}} |{{click|link=Wikipedia:WikiProject Military history/Coordinators|image=US-O12 insignia.svg|width=30|height=30|title=This user is the Lead Coordinator for the Military history WikiProject.}} |{{click|link=Wikipedia:Administrator|image=Admin logo.gif|width=30|height=30|title=This user is an Administrator.}} |- |} </div>

Please see the documentation of {{top icon}}. —TheDJ (talkcontribs) 20:03, 31 May 2010 (UTC)[reply]
If this wasn't important enough to be dealt with before the switch then I feel no reason to alter my code to handle your failure to check on this ahead of time. I've switched back to the old version since it actually works without my having to go through the trouble of retooling everything. Thanks anyway. TomStar81 (Talk) 01:34, 1 June 2010 (UTC)[reply]
You are using code in your page that is skin specific. It will only ever work for users that are using monobook. You cannot blame that on developers. The top icon templates were created by English Wikipedia editors to support such icons in multiple skins. If you don't want your icons to work in multiple skins, then that is your perogative, but don't complain because you are too lazy to convert them into something that works in multiple skins. —TheDJ (talkcontribs) 23:39, 1 June 2010 (UTC)[reply]

Hidden comments[edit]

Resolved
 – Duplicate of #Hidden comment button

The hidden comment button has disappeared, making it quite difficult to insert them without remembering things like where the exclamation mark is and how many hyphen there are. Please put it back into the toolbar. Brambleclawx 23:17, 31 May 2010 (UTC)[reply]

As a minor note, I've temporarily switched back to the old toolbar until this is fixed. Brambleclawx 00:34, 1 June 2010 (UTC)[reply]
See User:NerdyScienceDude/Scripts#Extra Toolbar Buttons. The hidden comment is included with the script. ~NerdyScienceDude () 13:05, 17 June 2010 (UTC)[reply]

Buttons, generally[edit]

This occurred to me upon reading the new section #Hidden comments, immediately above. I'd expand that observation to suggest that all editing buttons that were available in monobook be made available again in vector. (Some, of course, are in other forms, and do not necessarily need to be repeated in the old form.) For example, there is the strike-through button. I've manually added the fix for that, described above in #Strike button, and that works just fine, but it really should not be necessary for every user to have to do that manually for every feature (or any feature, for that matter!). The ones that were there before should not have been left out. --Tryptofish (talk) 23:32, 31 May 2010 (UTC)[reply]

I highly doubt that will happen, it is very confusing to novice editors I suspect. I think it is more likely that someone will develop a gadget at some point that allows you to easily add hundreds of advanced-advanced buttons. Perhaps you should try to develop one yourself ? —TheDJ (talkcontribs) 23:42, 1 June 2010 (UTC)[reply]
I'm not a software developer, and I'm not aware that I was required to be one in order to be an editor here. I'm not talking about anything that would be confusing to novice editors. I'm talking about the same row of buttons that were across the top of the edit box in the old version of the skin. If that didn't confuse novice editors before, it won't now, at least not any more than it used to. I'm just saying that the old edit box had a row of buttons across the top. Some of them have been retained in the new version, sometimes in new-and-improved versions, but some have been left out. Why not bring some of the missing ones back? --Tryptofish (talk) 23:49, 1 June 2010 (UTC)[reply]
IIRC vector was designed expressly to be less confusing for newbies. It is a reasonable presumption that the designers have omitted the buttons for precisely the reason that they adjudge them to be "confusing to novice editors". As TheDJ remarks - and since none of us are software developers bound to respond to irate users - we live in hope that someone will devise a gadget to re-introduce the missing buttons such that those who wish for their return can avail themselves of it. --Tagishsimon (talk) 23:54, 1 June 2010 (UTC)[reply]
I'm not "irate" at all. And neither are many of the other editors giving input on this page. But I do think the length of this page reflects the fact that many editors are concerned that developers made these decisions about what is or is not confusing, without enough consultation with the editor community. --Tryptofish (talk) 23:58, 1 June 2010 (UTC)[reply]
I think you are confusing this world with one where there is ever a time where all people will be satisfied. Different people have different needs and limitations. You cannot serve them all. Catering to the most advanced users, will in the end loose us an influx of new editors, thus bleeding the community to death. In my opinion our experienced users are not considerate enough towards the novice editors when it comes to issues of interface design. —TheDJ (talkcontribs) 00:06, 2 June 2010 (UTC)[reply]
I'm not confused, and I really do not see why there has been such a defensive reaction to my suggestion in this talk section. You have your opinion about experienced users, and I have my opinion about the interface. It appears that my bug is your feature. And I still think my suggestion was a useful one. --Tryptofish (talk) 00:12, 2 June 2010 (UTC)[reply]
It would be useful to compile a list of missing buttons. --Tagishsimon (talk) 00:47, 2 June 2010 (UTC)[reply]
See above sections Hidden comment button and Missing item from toolbar. These are not refinements that confuse anyone. They are things that it is next to impossible to produce without a button. By removing them, the redesign has not only been condescending toward all editors - new and continuing - it's made things harder for new editors. I do resent the implication that we should all meekly accept the decisions of our betters even when they increase our problems, especially since we have all been new editors and are perfectly well able to remember what was hard and what wasn't. Plus, there are IPs jumping through considerable hoops to say that no, this change does not make their lives easier. Yngvadottir (talk) 05:20, 2 June 2010 (UTC)[reply]
I dunno. How to weigh a staffed and professionally organised usability initative against the carping of a few disgruntled users. Not an easy one to call. I noted above that we can make the assumption that buttons were removed since they were, in fact, "refinements that confuse". Equally, we can agree that there should be continuity of access - through the new toolbar - to functions currently missing from it, such as the insertion of hidden comments, &c. And to that end, again as noted, what would be most useful now, should anyone want to go beyond repeating the same general point, is for someone to list the functions that are missing. --Tagishsimon (talk) 11:34, 2 June 2010 (UTC)[reply]

Can I note btw, that most of these elements are still accessible from the insert bar below the save buttons ? Just saying. —TheDJ (talkcontribs) 12:08, 2 June 2010 (UTC)[reply]

It would have been helpful to know that. But it would have been even more helpful not to remove functions from where they were easy to find. i.e.: This is a confusing change! I wouldn't know whether the things I need to use are now hidden away in some clever place - because I hit "take me back" as soon as I couldn't find something. (In my case the "no-wiki" button, but hiding the interwiki links also did no service to me personally). Professional = paid to change things. Which does not at all mean the changes will always be improvements. Rather the opposite. The beta testing was clearly inadequate and this page and several others, including as I say comments from IPs, indicate it was overwhelmingly a negative. People should not have to register an account to go back to the format that worked for them just because developers are being paid to change things willy nilly. Yngvadottir (talk) 14:46, 2 June 2010 (UTC)[reply]
Developers are not changing things willy nilly, but after months of study. This & other pages do not even closely resemble "overwhelmingly a negative" response. Professional in this instance means trained and experienced in assessing usability. You can denigrate these people all you like, but it does not add to your argument. That argument, indeed, could be rephrased "someone moved the interface widget that performs this action and I can't find it, therefore it's all bad". That's a fairly reactionary stance, unhelpful, and in the wrong place. It would be more useful, as I think I've said a couple of times now, if you want to see change, to list those widgets that are missing - if any. And perhaps to ask for the creation of a gadget which gives you the widgets back as buttons. Though what programmer would wish to do this voluntarily, in the knowledge of your predilection for denigration of those who try to change/improve things, is beyond me. Now. Is there anything actually missing or not? If not, can we close this bug listing and get on with real issues? --Tagishsimon (talk) 15:05, 2 June 2010 (UTC)[reply]
Yes: blockquote, strikethrough, hidden comment and underline are missing, or if they are there I can't find them. Speaking for myself, I don't miss underline, I can put up with typing <s> and </s> by hand if I have to, but doing <!-- --> and <blockquote> </blockquote> by hand when they used to be one click is a real pain. JohnCD (talk) 15:49, 2 June 2010 (UTC)[reply]
Blockquote, strikethrough and hidden comment are available via the "Insert" option found beneath the Save button. Select "Wiki markup" from the "Insert" menu (once selected, it appears to be persistent across sessions, which is handy.) Can't see underline - was it available under monobook?. --Tagishsimon (talk) 15:56, 2 June 2010 (UTC)[reply]
So they are, thank you; and now that I look again, underline wasn't a button in Monobook. So my complaint reduces to a grumble that having to scroll up and down because some buttons are at the top of the edit window and some now at the bottom is not a usability improvement, but that is only a grumble. JohnCD (talk) 16:15, 2 June 2010 (UTC)[reply]
Feedback on issues such as the disparity / illogic of the placement of toolbars around the edit box is probably best posted at usability.wikimedia.org/wiki/Your_Opinion or usability.wikimedia.org/wiki/Toolbar. Ditto arguments that buttons should be restored. They're both completely valid arguments, but out of scope for this page. --Tagishsimon (talk) 16:23, 2 June 2010 (UTC)[reply]

I'm pleased to see that other users have commented here, agreeing with some of the concerns that I have raised. Thank you. I take the point of those who have said that, as a design logic issue rather that specifically a software bug, the issue should be taken to other pages. Believe me, it will be. Wikipedia is built on the underlying belief system that it is run by the community, that volunteer editors working together are what makes a Wiki-based system run. The attitude that has come back here is that, instead, a few "developers" know better than the rest of us, and that the rest of us should just salute and obey our superiors. That is not going to fly. --Tryptofish (talk) 17:03, 2 June 2010 (UTC)[reply]

Continued at Wikipedia:Village pump (policy)#New Vector Skin development: policy issue (not a bug). --Tryptofish (talk) 19:24, 2 June 2010 (UTC)[reply]

Right clicking on Page, Edit, History, Discussion etc. No longer allows multi-tab editing/reading, Why?[edit]

Being worked on: Already reported as bugzilla:23490. Amalthea 16:57, 2 June 2010 (UTC) - and listed above as #Tabbed browsing[reply]

(Moved from Usability project page)

Right clicking any of the header tabs, i.e. history, talk, etc.,used to allow you to open those pages in a new browser tab (or window for that matter). So you could quickly switch back an forth between a talk page and the article under discussion for example. Now you can no longer do that. Is there a reasonable justification for this obvious loss of functionality?

I am using Internet explorer v8.0 (and please refrain from telling me to install a new browser that will load up a bunch of new services at my start up, I.E. has the most market share of any web browser and MediaWiki needs to understand that) and win7 64bit. When I right click on the Page, Discussion, Edit, History etc. tabs I get the "back, forward, save background, etc" menu instead of the link menu to open up in new tabs or whatever. This happens on IE 7 on my other system as well. I know that others have reported this issue also as some people mentioned it in the "retention rate" spreadsheet linked above.

I have checked on my Win XP system and I get the same problem in IE 8.0 on that OS as well. So it seems that you still have some work cut out for you. Colincbn (talk) 12:44, 2 June 2010 (UTC)[reply]

Yup. Most bizarre. I confirm this problem on IE7. --Tagishsimon (talk) 12:51, 2 June 2010 (UTC)[reply]
That seems to be bugzilla:23490. Amalthea 16:57, 2 June 2010 (UTC)[reply]
Yes it has been reported and is being worked on but that does not mean it is "resolved", it means it is "Being worked on". Colincbn (talk) 12:51, 7 June 2010 (UTC)[reply]

Much bouncing-about of text during editing[edit]

Hard to describe, but the text bounces up or down during a big edit (e.g. a long addition a talk page), in particular when there's text below the insertion point (it's not happening now because I'm inserting text at "the bottom". When the text "hops up" it forces me to scroll down and find the insertion-point, and this can happen many times in the course of an edit. Am using IE8 on both computers (Vista, WIN7), and both do it. BillWvbailey (talk) 14:53, 2 June 2010 (UTC)[reply]

I'm experiencing the same issue, though I don't believe that it is related to the skin change. It was identified at least as early as March (here and here) and bugzilla:22983 was filed. The bug has been marked as a duplicate of bugzilla:19334, which is marked as "fixed"; however, the issue obviously persists... -- Black Falcon (talk) 20:02, 2 June 2010 (UTC)[reply]
I reopened it. Shubinator (talk) 04:59, 3 June 2010 (UTC)[reply]
Thanks! I was under the impression only the devs could do that... -- Black Falcon (talk) 21:17, 3 June 2010 (UTC)[reply]
Nope, anyone with a bugzilla account can (and anyone can create a bugzilla account if they have an email address). Shubinator (talk) 05:45, 5 June 2010 (UTC)[reply]
This happened to me today, too, but I'm not using the new skin: I'm using Monobook. At the same time that started happening, the background color of the edit window started displaying as white, instead of using my Windows preferences. --Auntof6 (talk) 05:34, 3 June 2010 (UTC)[reply]
I noticed a new wrinkle in this today. The edit box text sometimes jumps when the cursor moves over a link outside the edit box. Curiouser and curiouser. --Auntof6 (talk) 10:09, 6 June 2010 (UTC)[reply]

The devs have tweaked the software and say this problem is now fixed, so I'm marking this thread as resolved. Feel free to unresolve if you still see the issue. Shubinator (talk) 23:59, 6 June 2010 (UTC)[reply]

Bug fixed. This was an IE8-specific bug, which was marked as "fixed" after a workaround was added to MediaWiki's core CSS. However, the enhanced toolbar CSS was overriding this workaround. --Catrope (talk) 09:19, 7 June 2010 (UTC)[reply]

Not fixed. I'm still seeing this. Is there something I need to do to get the fix to take effect for me? --Auntof6 (talk) 00:12, 8 June 2010 (UTC)[reply]

I'm having the same problem, when I click on any of the tools below the edit summary, it just makes the text box jump around, and when you display "show changes", nothing has been added, like a "Redirect" symbol or the includeonly tags, etc. I swear it was working earlier today, I noticed it stopped working for me about 3-4 hours ago. Another note, when I click on the "sign" button on the enhanced toolbar (the one above the text box), it puts the --~~~~ signature stuff up at the top of the text box, instead of where I'm entering the new text at the bottom. I'm using IE8 with the compatability button turned on. --Funandtrvl (talk) 00:25, 8 June 2010 (UTC)[reply]
Have you tried clearing your browser's cache? Shubinator (talk) 06:34, 8 June 2010 (UTC)[reply]
Wait, is this with the insertion tools BELOW the save button ? In that case this is a different problem I think. And you said it was working several hours earlier ? I have an idea what that might be then. I change was made to those tools to make them work with IE8. It might be this now shows a similar problem as the editwindow toolbar showed before. I'll try to pinpoint the problem by going to the library and try there with IE8 later today. —TheDJ (talkcontribs) 10:30, 8 June 2010 (UTC)[reply]
Yes, problem #1 is with the insertion tools below the save button. I tried to use them this morning and they're still not working when I'm signed in or when I'm not signed in. Bypassing the cache doesn't do anything, and they're not working no matter if I have them set on any one of the ten drop-down choices. All it does is to make the pg flip up to the top of the pg without adding any characters, and yes, those insert tools were working earlier yesterday. Problem #2: When I use the enhanced edit toolbar (I have Mr. Zman's 'User:Mr.Z-man/refToolbar 2.0.js' code installed), it doesn't place the characters (for example, the sign button ones) where the cursor is blinking. Instead, it also jumps to the top of pg and inserts it within another word. (Using IE8 with W7). Any help is always appreciated! --Funandtrvl (talk) 14:15, 8 June 2010 (UTC)[reply]
Well, this is getting stranger by the minute! In "my preferences", I have "Prompt me when entering a blank edit summary" checked, however, when I make an edit to my user page and save the page without leaving an edit summary, it's not giving me the warning and is just saving the page with no edit summary. (see: [3]) I've noticed that there are several posts on this page about edit summary problems, is this related to one of those? --Funandtrvl (talk) 14:31, 8 June 2010 (UTC)[reply]

The jumping around issue when using a textinsertion tool and IE8 is still not fixed, I have confirmed this problem today in the library. The problem still exists for the wikieditor toolbar and the insertion tools below the save button. The insertion systems DO all insert characters now. This indicates that most likely you, Funandtrvl, have installed a userscript or gadget that is generating an error on the editpage, preventing other scripts from running. This might also indicate as to why the "blank edit summary" warning is not given to you. —TheDJ (talkcontribs) 15:46, 8 June 2010 (UTC)[reply]

After resetting "my preferences" back to default, removing all gadgets and custom js and css scripts, then checking "blank edit summary" in "my preferences" and clearing my cache and browsing history, I'm still not getting the prompt warning to not leave a blank edit summary. (see: [4]) Is there a script I'm missing somewhere? --Funandtrvl (talk) 16:16, 8 June 2010 (UTC)[reply]
For what it's worth, I am no longer encountering the issue, including when I insert a special character from the insertion tools below the save button (for me the most bothersome aspect was movement in the text box while typing). I see that there are still some unresolved issues, but I want to say "thank you" to those involved in fixing the original issue. -- Black Falcon (talk) 16:15, 8 June 2010 (UTC)[reply]
Update - The insertion tools (below the save page) are working now in IE8 regular mode, but not in the "compatability" mode. Also, the edit summary warning is now working in both regular and compatibility modes. --Funandtrvl (talk) 16:30, 8 June 2010 (UTC)[reply]
Well with IE6/XP Pro (yeah, I know!) it still isn't fixed. The "Wiki markup" tools below the "Save page" still bounce to the top of the page without inserting anything, while the icons above the edit box seem to do absolutely nothing. LeadSongDog come howl! 18:24, 8 June 2010 (UTC)[reply]
Me too. IE8 still kaput whether in compatibility more or not (at least, as far as I can understand their compatibility more UI). --Tagishsimon (talk) 18:33, 8 June 2010 (UTC)[reply]
Ah ha! This is a discussion of one of the two "Problems" that I posted together (#109 in the contents box at this writing; the other is the inability--at least in IE8--to insert special characters in the edit summary field, the already existing thread for that one seemingly abandoned with no results). They started simultaneously, with each other and with the installation of the new skin, at least for me. Despite prior bug reports indicated here for this one, it definitely began for me with the new skin. I had it once before (and I mean the exact same thing), but that proved to be because I installed IE8 before it was ready for consumers (the download being available on the internet with no indication that it wasn't ready notwithstanding). Downgraded back to 7 and it went away until the new skin went up here. Does that suggest anything to you people who are more tech savvy than I? On the other hand, to Tagishsimon and with all due respect, I must say that I don't understand what he means by "compatibility mode UI," let alone his not understanding that of IE8. --Tbrittreid (talk) 23:07, 8 June 2010 (UTC)[reply]
I beg your pardon, Tag. You obviously meant "mode" as previously used by Funandtrvl. I still have no understanding of the distinction or how to accomplish a change from one to the other. But then, you also say it doesn't help. Again, my apologies for not seeing "mode" before making my previous post. --Tbrittreid (talk) 23:14, 8 June 2010 (UTC)[reply]
No probs. Thanks for pointing out the typo, which I've now fixed. And yup, even after a second look, I still can't (be bothered) to get my head around IE8's compatibility mode UI. I'm only using it to test for this & other IE bugs & am otherwise not hugely familiar with it. --Tagishsimon (talk) 23:17, 8 June 2010 (UTC)[reply]
Found a site that explains (somewhat for a lay person like me) the differences between IE7-"like" compatibility mode (in IE8) and IE8: http://www.evotech.net/blog/?s=hacks#uxa (Section is about halfway down the page) --Funandtrvl (talk) 23:39, 8 June 2010 (UTC)[reply]
Tag, you fixed my repetition of your typo in my post, but not the actual typo in your post. Funandtrvl, sorry but we were talking about the difference/distinction/transition between regular and compatibility modes for the same version of IE (specifically 8), not compatibility modes of two different versions. Thanks for nothing. And in case it hasn't been made clear yet (and some people here do indeed seem to not understand this), this problem often results in the cursor being someplace in the edit field other than where expected/intended. --Tbrittreid (talk) 22:13, 9 June 2010 (UTC)[reply]
You may have misunderstood my previous post, so I've edited my comments to make them more clear (hopefully). Please note the following quote from the article that I referenced above: "Important to know is that IE8 has a button that allows users to render your page in IE7." In other words, the problem on WP that I'm experiencing is that the insertion tools below the "save page" button don't work in IE8's compatibility view (i.e., "IE7-like compatibility mode/view"), but they do work (for me, at least) in IE8 with the compatibility view turned off. Thus, I'm not referencing the two different IE browser versions (IE7 or IE8) and neither is the article, but the two different "versions-views-modes" of specifically, IE8. Also, on Microsoft's website, there is a fairly decent article describing IE8's two views at: "Just The Facts: Recap of Compatibility View", if you want to read more about it. Since the insertion tools do work in IE8, I just have to figure out how to override the automatic changing to the compabilitiy view for the WP website. --Funandtrvl (talk) 17:06, 11 June 2010 (UTC)[reply]
If by "the insertion tools do work in IE8" you mean insertion into the edit summary field, then no they do not work in IE8. In any event, that is not the problem that is the topic of this thread, nor do I see any relevancy to the problem at hand since, as Tag said, despite earlier claims changing these modes doesn't have any effect on it. So can we get back on topic? --Tbrittreid (talk) 21:05, 11 June 2010 (UTC)[reply]
The insertion tools are working for me in IE8, including in the edit summary box, only if the compatibility view (the blue-lit "broken page" tab at top) is not lit up. However, using those insertion tools to add a "wiki markup" character, for example, into the text box area still makes the page bounce and jump down about an inch. That doesn't seem to be fixed as of yet. But, since bugzilla:19334 has been marked as "resolved" since 2010-6-6, this problem may not be fixed until someone re-opens the bug. --Funandtrvl (talk) 05:07, 13 June 2010 (UTC)[reply]

The tools do not work for me, and I still get the full jerk--taking the line with my cursor to the bottom of the window or as close to it as the amount of text beneath the cursor's line allows. There's been no improvement of this situation for me at all. --Tbrittreid (talk) 22:49, 13 June 2010 (UTC)[reply]

bugzilla:19334 is reopened. --Tbrittreid (talk) 22:55, 13 June 2010 (UTC)[reply]
Terrific, thx. Funandtrvl (talk) 02:09, 14 June 2010 (UTC)[reply]
In My Preferences/Editing, change Columns to a very high number (I did 900) and that ahould do it, yet leave the edit window at a reasonable and usable size; at least it did it for my IE8, and as I suspected, also restored the insertion of special characters into the edit summary field. If some other IE8 users do not complain that it doesn't work for them (and I highly recommend giving them a chance to do so), we can put a resolved check on this, and the insertion bug report as well. Hooray! Oops! In Preview I saw that "highly" should have been "highly" and when I went to delete the "ly" you guessed it: She jumped down! The above is obviously on the right track, but not entirely there. I'll go update the bugzilla. --Tbrittreid (talk) 21:49, 14 June 2010 (UTC)[reply]

Blank Page[edit]

Special:Watchlist/edit just shows up as a blank page. I tried it in both Google Chrome and Firefox, and it's the same for both browsers.

Americanfreedom (talk) 17:02, 2 June 2010 (UTC)[reply]

Works for me in FF on XP. NO blank page. --Tagishsimon (talk) 22:52, 2 June 2010 (UTC)[reply]
Could this be the same as #Completely blank pages up here? −Woodstone (talk) 23:02, 2 June 2010 (UTC)[reply]
Dunno. That one was Chrome specific and "mostly it happens on "edit", "preview" and especially on "previous page" (the back button of the browser)..". But it's worth noting. Meanwhile I've just tried Special:Watchlist/edit in Chrome on XP, and all was good. --Tagishsimon (talk) 23:49, 2 June 2010 (UTC)[reply]

Edit section not found[edit]

Resolved
 – not a Vector issue

While trying to edit an ANI section I get the following message: Cannot find section. Dr.K. λogosπraxis 22:40, 2 June 2010 (UTC)[reply]

Details: Link and I get the message: You tried to edit a section that does not exist. Because there is no section 50, there is no place to save your edit. Sections may have been removed after you loaded the page; try to purge the page or bypass your browser cache.Return to Wikipedia:Administrators' noticeboard/Incidents

By the looks of it, I think that you most likely crossed paths with this edit which removed four sections, rendering your "edit section 50" useless as there are now only 48 sections. Not a Vector issue, just life. --Tagishsimon (talk) 22:51, 2 June 2010 (UTC)[reply]
Thank you very much. Must have been the archiving robot again. Take care. Dr.K. λogosπraxis 23:02, 2 June 2010 (UTC)[reply]

Animated text is green colored[edit]

In Firefox 3.6.3 on Windows 7, while the word "Search" fades away after the search box is clicked on, the word "Search" is green colored. This same problem happens (to the sidebar's text rather than the search box) when the sidebar is collapsed or expanded using MediaWiki:Gadget-sidebarToggle.js. PleaseStand (talk) 23:33, 2 June 2010 (UTC)[reply]

Anti-new-tab behavior in suggestions[edit]

In Firefox 3.6.3 (and also in Google Chrome 5.0.375), search suggestions force themselves into replacing the current page when I click on them, no matter what my browser settings, no matter whether I use ctrl-click, and even despite my having Tab Mix Plus set to "freeze" the page I'm on. Even right-clicking on a suggestion causes the page to get replaced before I can even choose anything from my browser's own menus. (Why are right-clicks even being intercepted?) The result of this is that one can no longer perform a "Go" to a specific existing page anymore without destroying the (edit/watchlist/whatever) page one is already on, unless one types out the entire name of the article by hand and then ctrl-clicks the magnifying glass icon. (And right-arrow doesn't work on Vector suggestions like it did on Monobook, so there is now no way at all to insert the full article name in the search box, without typing it in full by hand, even when you're seeing the name right below it. And thanks to the behavior in #Broken search window above, being a speed-typist won't save you.) I haven't tested IE. --Closeapple (talk) 01:53, 3 June 2010 (UTC)[reply]

Couple of extra notes on this:

  1. It's probably related to #Bug concerning opening search result in new tab in Safari above, and is most likely is caused by whether the JavaScript does a location replace or what. (Can JavaScript do it any other way?)
  2. I should have pointed out before that I also have the Firefox extension SubmitToTab 0.3.5, forcibly overridden to work in Firefox 3.6, which is why I can ctrl-click to get a new tab from buttons (like the magnifying glass) in addition to plain links in the first place. Google Chrome allows ctrl-click on submit buttons natively, however, and suffers from the same problem with the new search box.

Hope this helps. --Closeapple (talk) 19:10, 14 June 2010 (UTC)[reply]

"Help" link on user contribution page positioned too high[edit]

This is an untidiness rather than a serious problem: on user contribution screens, the main title has a horizontal line beneath it; links to the user and talk pages etc are positioned just below that line, but the link "Help: User contributions" at the right of the screen is positioned a little higher, so that the horizontal line actually runs through it. I am using Firefox 3.5.9 on a 1366 x 768 screen. JohnCD (talk) 16:44, 3 June 2010 (UTC)[reply]

Yup. It's just as ugly in IE. --Tagishsimon (talk) 17:04, 3 June 2010 (UTC)[reply]

Watchlist star[edit]

Sometimes the star just keeps on turning, and doesn't stop. This happens (every once in a while, but not always) when you add/remove/add/remove/add an article quickly by clicking many times on the star. I use the latest version of Firefox and the latest version of Mac OS. Randomblue (talk) 17:13, 3 June 2010 (UTC)[reply]

Top of the page displays badly on mobile browser[edit]

I have symbian OS 9 (S60) on my phone, using default browser I can`t really access most buttons on top of the article (edit, add to wachlist and the dropdown menu) because they are displayed under the logo and search window making it imposible to click them ~~Xil (talk) 17:26, 3 June 2010 (UTC)[reply]

This issue is known as bugzilla:20234. —TheDJ (talkcontribs) 20:31, 3 June 2010 (UTC)[reply]
Okay, that looks similar enough. BTW I just noticed that it can also be reproduced by decreasing width of web browser window on PC ~~Xil (talk) 06:13, 4 June 2010 (UTC)[reply]

Logo in IE 6[edit]

In Internet Explorer 6, the Wikipedia logo has an opaque, light-blue background. It is not transparent. Strictly, this does not have to do with the skin change but rather the logo change (the logo also displays incorrectly in Monobook). PleaseStand (talk) 20:44, 3 June 2010 (UTC)[reply]

That is weird. I thought our PNGfix script fixed any pngs that were not IE6 compatible ? —TheDJ (talkcontribs) 21:05, 3 June 2010 (UTC)[reply]
Fixed sometime today. Thank you. LeadSongDog come howl! 21:28, 8 June 2010 (UTC)[reply]
I submitted the change to File:Wikipedia-logo-v2-en.png that changed the background color to the lighter gray used by the vector skin. It is not perfect, but is far less distracting. This is not the ultimate solution however as the script pointed out by TheDJ is not working. I have opened bug 23825 to address this.--Svgalbertian (talk) 16:51, 11 June 2010 (UTC)[reply]

Show/hide links in preview mode[edit]

Clicking the "show" or "hide" link of a collapsed template while in preview mode causes the Navigate away message to be displayed (using IE8). #Edittools do not work in Internet Explorer may be a related issue (in that it also involves the Navigate away message). -- Black Falcon (talk) 23:33, 3 June 2010 (UTC)[reply]

New skin/bug[edit]

Resolved
 – Duplicate of #Edittools do not work in InternetExplorer
  • Can't the default be for the toolbox to be open so that it is easier to get to the "contributions" link?
  • Also, Whenever I click on the Wiki markup items at the bottom of the page, I get a dialogue box that asks if I am sure I want to navigate away from the page. Can that be stopped? Thanks! -- Ssilvers (talk) 17:00, 4 June 2010 (UTC)[reply]
You can fix both those in your Preferences: (a) under Appearance, uncheck " Enable collapsible left navigation menu" (right at the bottom); (b) under Editing, uncheck "Warn me when I leave an edit page with unsaved changes". JohnCD (talk) 18:08, 4 June 2010 (UTC)[reply]
Thanks, John! It's too bad about the second one. I would like to be warned before I leave an edit page with unsaved changes, but not just to insert something from the wiki mark-up items at the bottom. All the best! -- Ssilvers (talk) 19:30, 4 June 2010 (UTC)[reply]
The second one is a bug noted above. I'm sure it'll eventually be sorted out. I presume you're an IE user. The bug affects only IE, so a move to firefox or chrome would serve as a work-around until the bug is fixed. --23:39, 4 June 2010 (UTC)

Black line instead of characters in the search box[edit]

Using the mobile phone Nokia E71 to browse Wikipedia (see Web Browser for S60), I get black line instead of characters when I enter them in the search box. Before the update, the text was displayed normally. --Eleassar my talk 20:36, 4 June 2010 (UTC)[reply]

Clicking on redlinked images[edit]

Resolved
 – not a Vector issue

When I click on a redlinked image I now get a botched link to the upload form. There is now no (easy or intuitive) way of getting to the deletion logs for the page to see whether it has been deleted. Take Emma Rigby for example, click the redlink in the infobox and you come to the link http://en.wikipedia.org/wiki/Wikipedia:Upload?wpDestFile=EmmaRigby.jpg whereas it used to take you to http://en.wikipedia.org/w/index.php?title=Special:Upload&wpDestFile=EmmaRigby.jpg . The link is botched, at the very least, it should simply go to the filepage. Woody (talk) 16:11, 5 June 2010 (UTC)[reply]

Yes this is a known issue of MediaWiki 1.16 (nothing to do with the skin). bugzilla:23140. —TheDJ (talkcontribs) 13:22, 6 June 2010 (UTC)[reply]
Ok, I thought it went past the skin change but wasn't sure. Thanks, Woody (talk) 13:56, 6 June 2010 (UTC)[reply]

Logs,contributions[edit]

Resolved
 – Options hidden under collapsed toolbox

When I am on a page I can not find a link for all of the logs for the pages. Also When I go to user pages I still don't see the contribution section for the users.Checker Fred (talk) 18:32, 5 June 2010 (UTC)[reply]

Have you clicked on Toolbox? Are the missing items in there? --Tagishsimon (talk) 12:45, 6 June 2010 (UTC)[reply]

what tool boxChecker Fred (talk) 21:33, 6 June 2010 (UTC)[reply]

Left side of the screen, pretty much where you'd find User Contributions, were they not now hidden under Toolbox. --Tagishsimon (talk) 22:27, 6 June 2010 (UTC)[reply]

I think i got itChecker Fred (talk) 23:41, 6 June 2010 (UTC)[reply]

Good. If you cannot find it, get your browser to search for Toolbox and it'll find it. Click on Toolbox and it shows you a bunch of links beneath it. --Tagishsimon (talk) 23:56, 6 June 2010 (UTC)[reply]

what browser are you talking about.Checker Fred (talk) 17:06, 7 June 2010 (UTC)[reply]

Internet Explorer, Firefox ... the programme you;re using to view web pages such as this. --Tagishsimon (talk) 17:21, 7 June 2010 (UTC)[reply]

Editing at end of a line[edit]

When I add stuff at the end of a line, it tends to be inserted at the beginning of the next line instead. Added text needs to go before the end of line code, not after it. — Cheers, Steelpillow (Talk) 10:48, 6 June 2010 (UTC)[reply]

Tell us more. I cannot recreate this. --Tagishsimon (talk) 17:45, 6 June 2010 (UTC)[reply]
It seems to be for certain situations only. Try this: edit this section, then try to add a third "=" at the end of the heading. When I do that, it jumps to the start of the next line. But start a new heading below here, and all is well. — Cheers, Steelpillow (Talk) 18:07, 6 June 2010 (UTC)[reply]
I have experienced the same sort of thing with the old Monobook skin when using the mouse (in IE7) to position the insertion point: the blinking insertion cursor appears in the right place but the insertion happens in the next line. It does not happen consistently, frequently, or even reproducibly, and I have never figured out what is special about the context that triggers it. It has not yet happened to me with the Vector skin. ~ Ningauble (talk) 18:46, 6 June 2010 (UTC)[reply]
I couldn't get it to happen in IE or Firefox, but noting the above comment, maybe I got lucky. --Tagishsimon (talk) 00:00, 7 June 2010 (UTC)[reply]
Today it is still repeatable. Using Iceweasel (aka Firefox) on debian Linux. Just thought to try Epiphany - it does not show this problem. If Firefox on Windows is fine, then maybe it's just one of life's little mysteries. — Cheers, Steelpillow (Talk) 19:50, 7 June 2010 (UTC)[reply]

Tabs[edit]

Resolved
 – design, not bug

My tab bar is annoyingly split. Some tabs left-align while others right-align, leaving a gap in the middle. Constantly irritating to use. I guess that privileged users prolly get a full tab bar, but have pity on us mere mortals. Using Iceweasel. — Cheers, Steelpillow (Talk) 10:48, 6 June 2010 (UTC)[reply]

Are you talking about Project Page and Discussion justify left, and Read, Edit, View History justify right? Or something else? --Tagishsimon (talk) 12:42, 6 June 2010 (UTC)[reply]
Yes, that is exactly what I mean. — Cheers, Steelpillow (Talk) 13:29, 6 June 2010 (UTC)[reply]
Ah. Then it's not a bug, merely the new design. You'll get used to it. It's the same bar as the "privileged" users see. --Tagishsimon (talk) 17:36, 6 June 2010 (UTC)[reply]
No I won't. That's never an excuse for bad design. — Cheers, Steelpillow (Talk) 18:15, 6 June 2010 (UTC)[reply]
The original reporter denies the validity of your "solution." Further discussion is mandatory. --Tbrittreid (talk) 21:51, 6 June 2010 (UTC)[reply]
Go and discuss the bad design somewhere such as Wikipedia:User experience feedback. This is a bugs page. This is not a bug. --Tagishsimon (talk) 22:25, 6 June 2010 (UTC)[reply]
Thanks for the tip - done that. — Cheers, Steelpillow (Talk) 09:21, 10 June 2010 (UTC)[reply]

Search box selection issue[edit]

If the cursor is over the list of suggested search terms then if return is hit the article whose title is under the cursor at the time will load, instead of the article whose title has been entered into the search box. Firefox 3.6.3 on XP Pro SP3 --GW 12:56, 6 June 2010 (UTC)[reply]

I'm struggling to see the problem here. The point of being able to highlight a search suggestion is to use the search suggestion rather than the typed text. If you don't want to be taken to the article, then don't highlight the suggestion. --Tagishsimon (talk) 17:42, 6 June 2010 (UTC)[reply]
This happens if the cursor is over it, even if it is not selected. --GW 19:27, 6 June 2010 (UTC)[reply]
The original reporter denies the validity of your "solution." Further discussion is mandatory. --Tbrittreid (talk) 21:51, 6 June 2010 (UTC)[reply]
Return selects it. That's just the way it is. --Tagishsimon (talk) 22:20, 6 June 2010 (UTC)[reply]
I'll go along with the other one (I should have acknowledged the dubiousness of his dispute there), but the reporter of this problem categorically contradicted the description in your "solution." Deal with that. Do not ignore it, but deal with it. --Tbrittreid (talk) 22:51, 6 June 2010 (UTC)[reply]
It is not a bug. It is the design of that part of the user interface. Not liking it does not make it a bug. I wish I knew what your problem was, Tbrittreid. People are working on the bug affecting you. People are trying to spot bugs. People need to distinguish between bugs and bits of design they don't like. In this case, if the behaviour was different, we would be entertaining a bug report saying "why does the system not take me to the right article when I hover over an autosuggestion in a search box and press return".
None of this is helped by you carrying your antipathy for me into other thread. There just is no bug to be solved here. If you discuss the issue here, it does no good. This is a bug fixing page. There's another page, Wikipedia:User experience feedback where you can discuss your dislike of the interface design and who knows, someone might care. But here, no one cares, because it is not a bug. Now. Please go and read WP:STALK and stop stalking me. It's pathetic and embarrassing. --Tagishsimon (talk) 23:34, 6 June 2010 (UTC)[reply]

On the other one the reporter said he didn't like it, and I dropped that one. Here, he said your claim of design aspect did not match the situation he was faced with. You have yet to so much as acknowledge that he has done so. DO IT NOW! And stop talking for anybody but yourself ("...here, no one cares....").

I categorically deny stalking you, but it is simply that you are all over this page, behaving in an unacceptable manner. You should be a lot worse than embarrassed. --Tbrittreid (talk) 20:34, 7 June 2010 (UTC)[reply]

Restating the problem[edit]

Let me restate the problem, but I suppose that there is no cure. Similar annoyance happens with standard Windows combo boxes:

  1. Click on the search box to activate it. Leave the mouse cursor ~50 pixels below the box.
  2. Type your search term, say "asdf"; the list of items starting with "asdf" pops up below the search box
  3. Hit Enter after typing "asdf".
  4. If the mouse cursor happened to be over e.g. second item, Asdfghjkl, you will be taken to that page, not the Asdf that you wanted.

The workaround: leave the cursor elsewhere before you start typing. But it's all too natural to leave it close to the search box. No such user (talk) 06:55, 11 June 2010 (UTC)[reply]

Exactly. This just happened to me because I forgot to park the mouse in a safe place before using the keyboard. This annoying problem is not unique to Wikipedia: it is common for websites with (an excess of) active components to confound the keyboard and mouse interfaces. IMHO this is just sloppy, but it seems to be becoming an accepted norm. One reason I almost never maximize a browser window is to leave the desktop exposed for safe parking. ~ Ningauble (talk) 14:51, 11 June 2010 (UTC)[reply]
An autosuggestion should be selected when the mouse hovers over it, but not when the mouse was already there before the list of autosuggestions appears. I don't know if it's feasible. Cenarium (talk) 17:25, 13 June 2010 (UTC)[reply]
Cenarium hit the nail on the head. The problem is that the mouse happens to be already there, I am not selecting anything. This is clearly a bug that is being sold as a feature. It's very annoying. The mouse is in that area more often than not. Why? Because I have to click on the bloody box before I can search for something.
If I hit enter on the keyboard then it means that my right hand is not using a mouse, and I mean to search for what I have just typed. Do you want to force everyone to grab the mouse and click on the magnifying glass icon, when my pinkie can hit return 100 times faster? Who is in charge of usability here? I have never had this problem with any other interface, not even with Flash/Flex interfaces, for crying out loud.
Can a developer who is not a mouse-head please look into this and fix it? Thanks. 205.228.108.186 (talk) 07:23, 14 June 2010 (UTC)[reply]

Are you telling me that users would (1) stop typing, (2) grab the mouse, (3) move it to select a suggestion and then (4) move back to the keyboard and hit Enter? I would really like to see that dance. Enter = ignore any mouse selection, end of story.

Also (but this is probably too subtle to the boneheads that can't see a bug in this behaviour) the suggestion should be selected when the mouse *moves* on it, not just because it happened to be already there. And even so, before this is misunderstood, hitting Enter when a selection is active *still* means ignore mouse selection.

By the way, this is how the address bar in Firefox works, and how the Google suggestions work, and... is this embarrassing enough yet? —Preceding unsigned comment added by 114.146.168.127 (talk) 13:14, 14 June 2010 (UTC)[reply]

Ad hominem attacks rarely make the situation any better. This bug is reported as T25949. --Tagishsimon (talk) 18:01, 14 June 2010 (UTC)[reply]

Interesting how your comment in that bug makes it sound like Google's behaviour is "different" and possibly inferior, when in fact it is *correct*. So you *still* don't get it. Amazing. You should really stay out of discussions that you don't understand, or at very least ask for clarifications. If in the future you stay out of discussions that you don't get, then consider this an example of an "ad-hominem attack" that made the situation better. And perhaps consider growing thicker skin. —Preceding unsigned comment added by 123.225.99.170 (talk) 21:50, 14 June 2010 (UTC)[reply]

Google's behaviour is different. I can see why you would parse my comment as suggesting I thought it inferior, though that was not my intention. I'm still not finding your attacks of very much use, but maybe they work for you. --Tagishsimon (talk) 22:00, 14 June 2010 (UTC)[reply]
Tag does have a history of posting onto threads here that he "doesn't care," "isn't interested" or "can't be bothered" about the bug at hand. When that's how a person feels about a particular discussion, it is painfully obvious that the proper behavior is to simply stay out of it. --Tbrittreid (talk) 22:29, 14 June 2010 (UTC)[reply]
We're getting a little off topic here. A search for "bothered" finds me saying I couldn't be bothered to get my head around the IE compatibility mode UI, in the context of confirming the existence of a bug. A search for "interested" finds nothing. I hold my hand up to the "don't care" stuff, which it at the top of this thread. I was wrong about this bug. So kill me. --Tagishsimon (talk) 22:41, 14 June 2010 (UTC)[reply]

Update: The "mouse is under the dropdown & thus highlights a suggestion" issue is fixed. Suggestions are only highlighted if the mouse is subsequently moved. However the other element of the behaviour under discussion - whether when a suggestion is highlighted, the return key should search for the term in the search box or for the highlighted suggestion - is unchanged; that is to say that the highlighted suggestion is searched for. Those concerned about this latter aspect of the issue may wish to weigh in on bugzilla. --Tagishsimon (talk) 09:57, 15 June 2010 (UTC)[reply]

inserts[edit]

You edit a section, after the first edit u insert for example nbsp. You get the warning that u ll lose ur edits, u ignore the warning n u do not lose ur edits. This warning is a pain. --Chris.urs-o (talk) 14:41, 6 June 2010 (UTC)[reply]

View source on protected pages[edit]

When viewing source text for protected pages, the (disabled) edit box is displaced an inch and a half to the right. I tried this on three protected pages in different namespaces (Article, Template, and MediaWiki) with consistent results. (Platform: IE 7.0.6001.18000 on Vista Home Premium SP1 using 1440x900 resolution.) ~ Ningauble (talk) 15:47, 6 June 2010 (UTC)[reply]

This problem is known as bugzilla:20842TheDJ (talkcontribs) 15:41, 8 June 2010 (UTC)[reply]

Tab rollup in windows side by side view[edit]

Does anyone have a solution to make the "read, edit, view history" tabls show up when you have two windows in the side by side view in IE8, because only the "project pg, discussion" tabs show up, and you have to maximize the pg to even see the other tabs. Just wondering... --Funandtrvl (talk) 18:51, 6 June 2010 (UTC)[reply]

P.S.: I have my search box widened:

#simpleSearch input#searchInput { width: 25em; } #simpleSearch { margin-top: 0.6em; } --Funandtrvl (talk) 19:37, 6 June 2010 (UTC)[reply]

Problems: no edit summary special insertions, edit field jerks with anything[edit]

My browser is Internet Explorer version 8. I cannot insert special characters (e.g., arrows) into an edit summary field at all, and I have always used them much more there than in the main edit window (except for talk page posts). Furthermore, doing absolutely anything causes the main edit field to jump upwards, sometimes causing the cursor to be someplace other than where I placed it. This does not happen often enough to make one check for it every single attempt, however, resulting in my edits sometimes being far removed from their intended location. --Tbrittreid (talk) 21:41, 6 June 2010 (UTC)[reply]

You well know that the first of these is reported on above in #Edittools do not work in Internet Explorer and the second is reported on above in #Much bouncing-about of text during editing. Multiple reports do more to hinder than help. --Tagishsimon (talk) 22:23, 6 June 2010 (UTC)[reply]
I know that no one has posted to the first in days and the other has had nothing but evasions of late. Furthermore, in my first post to "Much bouncing..." I expressly stated that I had just discovered it after posting the above, which I identified there in very explicit terms. I am also convinced that these problems are directly connected, and to genuinely fix one will genuinely fix the other. And who is stalking who now? --Tbrittreid (talk) 21:09, 11 June 2010 (UTC)[reply]

Google search script doesn't work in vector[edit]

Resolved
 – Fixed by Mr.Z-man

I switched back to Monobook layout because the Google search bar script (User:Mr.Z-man/gsearch) doesn't work in Vector for some reason, even though I added it to my Vector.js file. Vector is nice-looking but I prefer the earlier functionality of Monobook. --Eastlaw talk ⁄ contribs 03:43, 7 June 2010 (UTC)[reply]

Left a note on Mr.Z-man's talk; the bug is easily fixable (though to be fair to vector and its developers, it's more of a compatibility tweak for the script than a bug with vector). Shubinator (talk) 05:16, 7 June 2010 (UTC)[reply]
I've fixed the script (though I haven't tested it, since I don't use it anymore). Though this is, to a certain extent, a vector issue. One of the biggest complaints when it was first introduced was that it arbitrarily changed HTML IDs, breaking scripts for no good reason. Mr.Z-man 21:50, 7 June 2010 (UTC)[reply]
Thanks, it appears to work fine now. --Eastlaw talk ⁄ contribs 02:19, 8 June 2010 (UTC)[reply]
Although on firefox, and fwiw, I seem unable to select the article title (e.g. to copy it to the clipboard). --Tagishsimon (talk) 22:54, 8 June 2010 (UTC)[reply]

Horizontal rule through link on user contributions page[edit]

Resolved
 – Fixed by TheDJ

On the "User Contributions" page, the "Help: User Contributions" link to the right is overlapping the horizontal rule under the page title text, making it difficult to read and looking badly laid out.

I have recreated this bug at a variety of window resolutions in Firefox 3.6.3, Chrome 5.0.375.55, and IE 8 under Windows 7. It seems too obvious for me to be the first person to notice it, though, unless its something else about my system (It happens regardless of whether I'm logged in, so its not a script of mine.) Or it has been reported, but it was somewhere else or I didn't notice it but it's here. gnfnrf (talk) 13:08, 7 June 2010 (UTC)[reply]

Yeah I know exactly why this is. It is because we were only showing "From Wikipedia, the free encyclopedia" on articles. This however makes the coordinates and topicon css more annoying to deal with. I've switched the code back to always show "From Wikipedia, the free encyclopedia" like we used to have before. —TheDJ (talkcontribs) 18:38, 7 June 2010 (UTC)[reply]

Preview warning[edit]

This:

Preview
Remember that this is only a preview; your changes have not yet been saved! 

used to come up red. On my edit screen (using Mozilla's Firefox), it is now black and easily overlooked. I think it was better red. The same is true for the "no edit summary" warning. Bielle (talk) 18:33, 7 June 2010 (UTC)[reply]

This is a known issue bugzilla:23519. —TheDJ (talkcontribs) 18:43, 7 June 2010 (UTC)[reply]
Thanks Bielle (talk) 22:12, 7 June 2010 (UTC)[reply]

Non-expadable navigation on mobile phone[edit]

Using the mobile phone Nokia E71 to browse Wikipedia (see Web Browser for S60), I cannot expand the menus on the left (interaction, toolbox, languages). --Eleassar my talk 18:45, 7 June 2010 (UTC)[reply]

Overlapping things[edit]

I am using Internet Explorer 7.0. Windows Vista.

Things on the page often overlap. An example is file:vectorbug.jpg. As well, the message displayed whenever I add a page to my watchlist pushes the page downwards, but the text stays in the same place, not following the shift in position of the "page" (text area). Brambleclawx 22:30, 7 June 2010 (UTC)[reply]

File:vectorbug.jpg is because the userpage in question has CSS that forces the position of this content. I have since fixed it, because it was totally breaking pages and that simply isn't acceptable. Could you please create a screenshot of your IE7 issues ? I would highly appreciate that. —TheDJ (talkcontribs) 00:25, 8 June 2010 (UTC)[reply]
File:otherissue.jpg. As requested. It is a composite image of the top and bottom of the screen, seperated by a red line. Brambleclawx 00:37, 8 June 2010 (UTC)[reply]
Do you have any gadgets installed in your preferences ? —TheDJ (talkcontribs) 15:58, 8 June 2010 (UTC)[reply]
I am using refTools, UTC clock, and lead section edit button. Brambleclawx 22:27, 9 June 2010 (UTC)[reply]
I haven't been able to find a computer with IE7 yet, so i can neither confirm or deny. You are however the only person so far who has reported an issue like this. —TheDJ (talkcontribs) 23:05, 13 June 2010 (UTC)[reply]

Text box glitches[edit]

Resolved
 – not a Vector issue

I am using:

  • Internet Explorer 8 and Safari 4 on Windows 7
  • Safari 4 on Snow Leopard
  • "Cologne Blue" setting for Wikipedia interface settings

I wanted to report a few glitches pertaining to the new Wiki design that I have come across.

1. When you try and create a new page, there is a problem with the text box. You can see the graphics where the text box should be, but there is no way to input text here. You are only able to input text directly below this graphic. There seems to be an extra space in the coding or something.

2. When you edit any page, there is extra spacing beside the text box (coloured blue) where there should be more room for the text box should be. Sometimes the text spacing messes up, and it creates horizontal scroll bars you have to use.

3. When you edit any page, there is text from the last thing (usually the last line) inputed in the text box, that appears directly below the text box and directly above the edit summary box. It appears exactly as you typed it.


Example: ''This is my [[edit summary]]'' ~~~~

Thanks. PopMusicBuff talk 23:53, 7 June 2010 (UTC)[reply]

This is because of your cologneblue scripts. That script is not compatible with cologneblue and the error it generates prevents other javascript (such as which build the toolbars) from running. —TheDJ (talkcontribs) 00:07, 8 June 2010 (UTC)[reply]

Fixed:::How do I fix this? I tried blanking the pages (as I cannot place {{db-self}} anywhere on these types of pages), but that didn't do anything. I never use them or need them, so deleting would be best if possible. Thanks. PopMusicBuff talk 21:12, 10 June 2010 (UTC)[reply]

Layout quirks in Epiphany[edit]

The following layout problems were noted in Epiphany (v2.30.2, based on WebKit).

  • The search box itself is positioned too low, such that it slightly overlaps the pale blue horizontal line.
  • The space at the left is too narrow, with the effect that the WP logo is cropped at the sides (half the 'W' and 'P' are missing).
  • The vertical gap between the items at the top (eg. "log out") and the search box is too small. (Using Firefox as a reference.)

The skin seems perfectly usable; it just looks cramped. Jakew (talk) 10:40, 8 June 2010 (UTC)[reply]

Line spacing and focus bug[edit]

Each time I click to edit an article, and then start editing, after a few seconds the line spacing suddenly gets bigger and at the same the textarea loses focus so I have to click on it again. I am using Opera 10.5 with Windows 7 Ultimate x64. —Ynhockey (Talk) 21:00, 9 June 2010 (UTC)[reply]

I cannot reproduce this issue with Opera 10.53 on the same OS. Perhaps this is a bug in a user script? PleaseStand (talk) 21:32, 9 June 2010 (UTC)[reply]

Hi Ynhockey,
do you happen to have the "Make text fields (e.g. the edit form) use a sans-serif font instead of a monospace font" gadget enabled?
Amalthea 22:06, 9 June 2010 (UTC)[reply]

No, but I have made a monobook.css file that uses a sans-serif script (more suitable for editing). If this is font related, can you please explain how to fix it? I am rather dissatisfied with monospace fonts for editing as they don't differentiate between regular dashes (-) and en dashes (–). However, it's hard for me to believe that this is a font-related problem since it has to do with line spacing. I will make a few experiments to see what I can do myself. Thanks, —Ynhockey (Talk) 17:19, 10 June 2010 (UTC)[reply]
P.S. I have just tried this in IE without being logged in, and what happens is that it doesn't let me edit at all before the line spacing change, which takes about 2 seconds. I believe this is also a bug, because 2 seconds is a long time for someone who makes many edits. —Ynhockey (Talk) 17:22, 10 June 2010 (UTC)[reply]

iPhone problem[edit]

The enhanced editing toolbar won't appear on my iPhone; the old toolbar appears instead. I'm using an original iPhone with OS 3.1.3. ~NerdyScienceDude () 02:50, 10 June 2010 (UTC)[reply]


Doesn't display properly in seamonkey or IE8. Not sure about firefox. See screenshot on left. The navigation and the like have ended up on the lower left and the history and edit buttons bellow the level of the article. Problem consistent across two computers.©Geni 21:20, 10 June 2010 (UTC)[reply]

Sorry, Geni, but I have IE8, yet none of the problems you describe. --Tbrittreid (talk) 21:37, 10 June 2010 (UTC)[reply]
Were you logged in? Screenshot taken while logged out.©Geni 21:49, 10 June 2010 (UTC)[reply]
Resolution is 1024*768 FWIW.©Geni 21:49, 10 June 2010 (UTC)[reply]

Purge the page and it should work. See WP:VPT#Bug?. PleaseStand (talk) 23:15, 10 June 2010 (UTC)[reply]

Geni: Yes, I was logged in. PleaseStand: It's good that I don't have the problem, as I have no idea what "purge the page" means in this context. --Tbrittreid (talk) 20:54, 11 June 2010 (UTC)[reply]

Article History radiobuttons missing in Chrome 5, XP[edit]

Win XP SP3, Chrome 5.0.375.70 Example: http://en.wikipedia.org/w/index.php?title=Idiocracy&action=history Also, in Article Edit, "this is a minor edit" and "watch this page" checkboxes are missing. — Preceding unsigned comment added by Lexein (talkcontribs)

Do you have any Gadgets enabled in your preferences ? I cannot reproduce the problem on my Google Chrome 5, but perhaps a gadget is in the way somehow. —TheDJ (talkcontribs) 19:07, 11 June 2010 (UTC)[reply]
After reboot, I couldn't reproduce it either. I was most likely in a low free memory situation when the symptom occurred. No recurrence since. --Lexein (talk) 17:41, 13 June 2010 (UTC)[reply]
Since your first post was unsigned, maybe you just weren't logged in. "Minor" and "Watch" don't show unless you are, regardless of browser or anything. --Tbrittreid (talk) 23:23, 13 June 2010 (UTC)[reply]

Undo disabled[edit]

While editing the "undo" feature is now diaabled. Please restore this feature--Woogie10w (talk) 12:44, 12 June 2010 (UTC)[reply]

Browser and OS please. Undo works fine for me. ~NerdyScienceDude () 05:09, 13 June 2010 (UTC)[reply]

Talk page insertions with Internet Explorer[edit]

When editing a talk page using Internet Explorer 7.0, I can no longer insert such objects as the signature and time stamp, the <ref></ref>, Greek letters etc. When I select these characters and hit Insert, nothing is inserted, although the page does move. These objects used to be inserted with Monobook, but now will not insert either with Vector or Monobook. The only workaround seems to be to copy and paste the objects manually. They do insert correctly however if I switch browsers and use Firefox 3.6. Dirac66 (talk) 14:14, 13 June 2010 (UTC)[reply]

I too have the same issue. It worked a few weeks ago, but all the symbols at the bottom no longer insert anything. They just move the page. Same browser (IE 7.0), on Windows Vista. Brambleclawx 16:22, 13 June 2010 (UTC)[reply]
Oh, its's been adressed at WP:VPT#Drop down menu underneath edit summary. Brambleclawx 16:24, 13 June 2010 (UTC)[reply]

OK, I see the problem has now been fixed. Thanks. Dirac66 (talk) 01:42, 16 June 2010 (UTC)[reply]

Can't turn off AJAX search suggestions[edit]

Firefox 3.6.3. I managed to turn off the search box's AJAX suggestions once, but now am not able to. I've tried various things. Just now I restored my default preferences (again), turned the AJAX suggestions off, logged off and on again, and still I get the suggestions when searching. Pfly (talk) 23:59, 14 June 2010 (UTC)[reply]

A known bug. bugzilla:23520. —TheDJ (talkcontribs) 00:00, 15 June 2010 (UTC)[reply]

Qui and Lupin scripts do not work.[edit]

Using Google Chrome version 5.0.375.70. These two scripts do not work in the new skin. N419BH 16:47, 15 June 2010 (UTC)[reply]

Lupin wrote about a 100 scripts, can you be more specific ? —TheDJ (talkcontribs) 17:33, 15 June 2010 (UTC)[reply]
My apologies; I am referring to Lupin's Anti-Vandal tool. I think you probably know your own Qui script :) (wonderful tool by the way, thanks for creating it). I like the new skin, but those two scripts are paramount to my work here on Wikipedia and I need them to work. Thanks for looking into it. N419BH 00:51, 16 June 2010 (UTC)[reply]
See also #Lupin's anti vandal tool - not that it adds much. --Tagishsimon (talk) 00:54, 16 June 2010 (UTC)[reply]
Both work for me in Google Chrome. Perhaps you can elaborate on what specifically doesn't work, or perhaps you have other gadgets/scripts enabled that are breaking the tools. ? —TheDJ (talkcontribs) 14:56, 16 June 2010 (UTC)[reply]
On Qui, the little circle in the corner next to the clock is missing entirely, and for Lupin the toolbox links are missing, and when I enable them manually the page just sits there and does not update. As for gadgets, I have Twinkle, refTools, and Friendly, along with the clock. My monobook.js file has a few lines to customize Twinkle, and specifies Philip Trueman's version of Lupin's tool. Maybe the clock is covering up the Qui toolbar, and Philip's tool doesn't work while Lupin's does. N419BH 15:21, 16 June 2010 (UTC)[reply]

Sighted overlaps text[edit]

Firefox 3.5. I have javascript disabled, and under the DE wikipedia, the sighted box overlaps text (screenshot). For the record Monobook is my preference, but under https, the left hand language links send you to http (separate issue of course), so vector is hard to avoid. User A1 (talk) 17:04, 17 June 2010 (UTC)[reply]

No edit tool bar[edit]

None of the titles in the Contents box points to my problem even though I remember it being discussed, and with this page currently at 125 threads, I just don't have the time to go through each one trying to find it.

IE8 is my browser. After getting a semi-fix for the jumping around of the edit field (it's still there but not as bad, as I reported, and the edit summary insertion problem completely disappeared at the same time, for the record), I no longer show a tool bar at the top of an edit field. So far, the only PITA has been having to manually tilde-sign my posts. However, I'm sure something will prove problematical when I start doing edits more complicated than those I've been doing lately. Help and thanks. --Tbrittreid (talk) 20:32, 17 June 2010 (UTC)[reply]

It sounds like a javascript snafu to me, assuming you have checked the edit preference for "Show edit toolbar (requires JavaScript)". This page relates some javascript & IE8 not working together solutions. --Tagishsimon (talk) 09:14, 18 June 2010 (UTC)[reply]
I clicked on the link. Most suggestions did not help my problem. The only one I did not dare try was extremely drastic: Click Tools in the tool bar, then Internet options in the resulting drop box, the Advanced tab in the resulting small window, then Reset; what the next window, asking me to confirm my intent, told me would happen--so many things reset to factory defaults or such--was too drastic for this problem. When I asked there for further help, explaining the problem in detail, I was essentially told that I had come to the wrong place. For that matter, as I had the bar until the day I launched this thread (yesterday), I can't see how "javascript and IE8 not working together" is the problem anyway. --Tbrittreid (talk) 20:18, 18 June 2010 (UTC)[reply]
One test of whether javascript is or is not working on your machine is here. Which toolbar options to you have set in your preferences? --Tagishsimon (talk) 11:48, 19 June 2010 (UTC)[reply]
That test said javascript works for me. As for my tool bar options, one more time: I had the tool bar and without me changing a thing here it disappeared between one session and the next. Even if I knew what set of "preferences" you had in mind, I'd be certain it was an irrelevant question. Anybody who can't--or won't--proofread a post as short as that one and catch "to" where "do" was intended is worthy of little respect from me. -Tbrittreid (talk) 19:37, 19 June 2010 (UTC)[reply]
You are consistently good value, Tbrittreid. Very enjoyable. If you cast your jaundiced eye to the top right of the screen you'll find an option called "My preferences". Were you to click that, you'd see that amongst the tabs presented to you is one entitled "Editing". Within that are two options claiming to control the behaviour of toolbars. Is that the sort of irrelevance you are certain of? --Tagishsimon (talk) 23:36, 20 June 2010 (UTC)[reply]
As the bar disappeared between one time on this computer and the next without my going anywhere near those or any other preferences, yes that is exactly "the sort of irrelevance" I mean. --Tbrittreid (talk) 18:18, 21 June 2010 (UTC)[reply]
You're like a person whose lightbulb has gone off, but will not check the electricity nor the switch, nor take the bulb out and shake it to see if the filament has broken. "But I turned the light on yesterday. It should be working". How on earth do you expect to fix the problem, or get help, if you are sulkily unwilling to do the very basic checks. Baffling. --Tagishsimon (talk) 08:55, 24 June 2010 (UTC)[reply]

Double Bold[edit]

When bold is used in table headers, it's redundant. But that seems to cause some VERY odd text including missing characters, etc. I seem to have that problem with Navboxes whose titles link back to the article I'm reading.—Markles 16:18, 18 June 2010 (UTC)[reply]

This has nothing to do with the new skin (Question should probably have been asked on Wikipedia:Village pump (technical). And we can't help you unless you say WHERE exactly you are seeing this problem. Please link to the problem articles in question. —TheDJ (talkcontribs) 17:33, 18 June 2010 (UTC)[reply]
  • Sorry for the misplaced RFC. I'll post it appropriately elsewhere.13:16, 19 June 2010 (UTC)

NEW tiny font problem[edit]

I've seen others complain about tiny font, but haven't had that problem at all until yesterday. Suddenly I can't read diffs without zooming to 150%. Just diffs. Something changed (for the worse) yesterday. Using Win XP Home 2002, IE8. --Hordaland (talk) 21:05, 20 June 2010 (UTC)[reply]

Oops, I spoke too soon. Suddenly most everything is tiny, but diffs are tiniest. --Hordaland (talk) 04:59, 21 June 2010 (UTC)[reply]
I have not noticed any issues. Maybe this is a silly question, but did you accidentally resize the text by holding ctrl while using the scroll wheel? If that's the case, then "ctrl 0" should fix it (in Firefox at least). If not, what browser are you using? ▫ JohnnyMrNinja 09:47, 21 June 2010 (UTC)[reply]
I resize using ctrl+ and ctrl-. You're right that ctrl-0 lands me back at 100%, which is too small as of the last couple of days. Other sites, such as yahoo mail, are ok at 100%. Still using IE8. Hordaland (talk) 11:47, 21 June 2010 (UTC)[reply]

Tabbed browsing (2)[edit]

Can anyone fix the problems of tabbed browsing that I've commented at the top of this page? :| TelCoNaSpVe :| 04:22, 24 June 2010 (UTC)[reply]

This is a known problem, but it requires a lot of work to fix it properly, even though the fix itself is easy. It will take a while. You can always switch browsers of course. Only Internet Explorer is affected. —TheDJ (talkcontribs) 12:23, 25 June 2010 (UTC)[reply]

Tables in simple skin no longer have borders[edit]

I am regular user of the simple skin. The table borders are gone. I am not really sure whether this happened when the vector skin was made default instead of the monobook skin or whether it was some unrelated change. I'm not quite sure what has to be changed so tables get their border back. -- machᵗᵃˡᵏ 11:45, 25 June 2010 (UTC)[reply]

No, it has a totally different reason. Simple skin seems to be quite broken. It doesn't load the shared definitions of a lot of elements. The simple skin is basically unmaintained, so it breaks quite easily. I'll see if i can get this repaired. —TheDJ (talkcontribs) 12:21, 25 June 2010 (UTC)[reply]