2010 Wikimedia design and feature change/Bug reports/Archive 1

Arrow Key edit

Browser (exact version number can be typically found in Help/About screens): Crome

Operating system: Win XP

Screen resolution

Expected behavior

Observed behavior

Steps to reproduce

Additional notes/comments/screenshots: arrow key in diff view is doesn't work.

Arabic Wikipedia bUG edit

Browser (exact version number can be typically found in Help/About screens): Mozila Firefox 3.6.3

Operating system: Microsoft Windows 7

Screen resolution: 1920 x 1080

Expected behavior: In pictures, putting LEFT will make the picture on LEFT, and RIGHT will make it on RIGHT side.

Observed behavior: LEFT cause pictures on the RIGHT of the page, and RIGHT will make it on the LEFT side of the page.

Steps to reproduce

Additional notes/comments/screenshots

Can reproduce. Should be fixed soon - see Bugzilla:24075.--Eloquence 20:21, 22 June 2010 (UTC)[reply]

Fixed and deployed.--Eloquence 23:47, 29 June 2010 (UTC)[reply]

Navigation links on wikisource edit

Browser (exact version number can be typically found in Help/About screens)

Internet Explorer 7.0.5730.13

Operating system

Windows XP Pro, SP3

Screen resolution

1152.864

Expected behavior

Working navigation links beetween pages at fr.Wikisource.

Observed behavior

The 3 navigation links (leftarrow, rightarrow, and index) dont working. I had to click right and select Open the link.

Steps to reproduce

Go to any pages of the namespace Page on wikisource.

Additional notes/comments/screenshots

Sadly, lot of other things doesn’t work on Wikisource with Vector.

Search box needs double enter keypress to work on Hungarian Wikipedia edit

Browser (exact version number can be typically found in Help/About screens)

Chrome 6.0.437.3, Firefox 3.6.4, IE 8 (with and without compatibility mode)

Operating system

Win XP

Screen resolution

1024x600

Expected behavior

On entering a search text into the search box and hitting enter one should be taken to the article chosen in the dropdown or to a search page with his search term.

Observed behavior

Pressing enter only once will only hide the dropdown menu and if a suggestion is selected it will copy the suggestion into the search box. To initiate a search or to actually go to an article one has to click enter one more time. This is problematic especially in cases where one would like to do a "containing" search for which an article already exists - as he cannot do it.

Steps to reproduce

Go to huwiki, type e.g. "test" into the search box and hit enter.
Go to huwiki, type e.g. "test" into the search box and select the lowest item (the containing search) and hit enter

Additional notes/comments/screenshots

The problem exists even if one selects the search suggestion with the mouse. In this case he has to manually click into the search box and hit enter or to click onto the little search icon.--Dami 14:14, 22 June 2010 (UTC)[reply]

Can reproduce, looking into this now. May be some community-developed JavaScript interfering with Vector.--Eloquence 18:48, 22 June 2010 (UTC)[reply]

Was caused by a local script. Should be fixed as of this revision of Common.js.--Eloquence 20:20, 22 June 2010 (UTC)[reply]

IE7 reports HTML error (in Central Notice?) edit

Browser: Windows Internet Explorer® 7, version 7.0.6001.18000

Operating system: Windows Vista™ Home Premium, SP1

Screen resolution: 1440 x 900, 32 bit

Expected behavior: Render page without HTML errors

Observed behavior: When loading any page with the site notice "{{SITENAME}} is getting a new look...", when the background and site notice are rendered, and before anything else, the following HTML error message is received:
"Line: 95; Char: 1; Error: Object doesn't support this property or method; Code 0; URL: http://meta.wikimedia.org/wiki/2010_Wikimedia_design_and_feature_change/Bug_reports"
(URL and line number vary, sample obtained browsing this page where I am now posting.)

Steps to reproduce: This happens with default user preference settings, both at en.Wikipedia with Vector and also on sites such as this one that still use Monobook by default (without even enabling "Try Beta"). I first noticed it at en.wikiquote (Monobook) when the central notice went up.

Additional notes/comments/screenshots: Reported by ~ Ningauble 21:13, 22 June 2010 (UTC)[reply]

We're looking into this now.--Eloquence 21:49, 22 June 2010 (UTC)[reply]

Should be fixed now.--Eloquence 23:08, 22 June 2010 (UTC)[reply]

Works for me now. (Also, the site notice is no longer being displayed at en.wikipedia, where it was anachronistic.) Thanks. ~ Ningauble 03:08, 23 June 2010 (UTC)[reply]

Later that day (next day, in my time zone) the Central Notice is no longer showing up at Wikiquote or here at Meta. Is this intentional? It is not clear to me which projects are included in the Phase IV Deployment. ~ Ningauble 15:00, 23 June 2010 (UTC)[reply]

Later still, the notice is back again... Never mind. ~ Ningauble 18:26, 23 June 2010 (UTC)[reply]

Search bar glitch after pressing escape edit

Browser (exact version number can be typically found in Help/About screens)

Firefox 3.6.3

Operating system

Windows 7

Screen resolution

1367x768

Steps to reproduce

Enter "foo" in search bar
select a suggestion with the cursor keys (say, "football")
press Esc (the suggestions dropdown disappears)
copy the string "bar" to the clipboard
select the contents of the search box by double-clicking, paste the contents of the clipboard and press enter (the point is to replace the content of the search box and submit it before the AJAX call would return)

Expected behavior

search for "bar"

Observed behavior

go to the "football" article

Additional notes/comments/screenshots

this can happen in less contrived ways when the search suggestion AJAX queries are network lagged

--Tgr 13:44, 23 June 2010 (UTC)[reply]

Edit textarea too big on small screen resolutions edit

Browser (exact version number can be typically found in Help/About screens)

Firefox 3.6.4., Chrome 6.

Operating system

Win XP

Screen resolution

1024x600

Expected behavior

Edit area shrunk to comfortably fit the screen so as to be able to see the toolbar and the edited text at the same time. The vertical size of the textarea should be dynamically shrunk on detecting the small available resolution.

Observed behavior

The edit area is too big. The editarea already scrolls so there is no added benefit in having to use the browser windows's scrollbar to see the bottom of the textarea. Clicking on toolbar buttons while editing text at the end of the textarea causes a jumping effect.

Steps to reproduce

Change vertical resolution to 600
choose a somewhat longer article and hit edit
observe the size of the edit area and its scrolling properties;
try adding a special character to the end of the visible text using the toolbar.

Additional notes/comments/screenshots

The above resolution is currently quite common among netbooks.

Chrome has a feature to manually resize text areas, however with the Wikipedia edit area it only allows it to be enlarged, making it smaller than the original seems impossible for some reason.

The textarea was bigger also on monobook, but the enhanced editing toolbar adds almost a third in vertical size if one chooses the special characters box, and as the last choice is remembered, this space problem is noticeable even if one doesn't use the special characters tools in a particular edit.

The edit area is bigger than fits even on full screen mode if the special characters dropdown is open. --Dami 16:26, 23 June 2010 (UTC)[reply]

Extension DoubleWiki edit

Browser (exact version number can be typically found in Help/About screens)

Firefox 3.6.3

Operating system

Ubunut 10.04

Screen resolution

1024*768

Expected behavior

Clean behavior of mw:Extension:DoubleWiki : http://fr.wiktionary.org/wiki/bis?match=br

Work fine for this wiktionary (at least) :

an
br
co
en
hr
hu
hy
id
it
ko
pl
vi
zh

Observed behavior

Bad behavior : http://fr.wiktionary.org/wiki/bis?match=af

The logo is over the text.

Don't work for this wiktionary (at least) :

af
am
ar
cs
de
el
es
fi
io
ja
la
li
nl
pt
ru
sq
sv
vo
wo

Steps to reproduce

Activate the DoubleWiki gadget. Go to any pages of the French speaking wiktionary with IWL and click on ⇔ near the lang.

Additional notes/comments/screenshots

I didn't test all the projects (other wiktionaries or wikisources). Cdlt, VIGNERON * ^discut. 12:27, 24 June 2010 (UTC)[reply]

Pending changes and read tabs get obscured by discussion tab instead of being hidden if screen resolution is low edit

Browser (exact version number can be typically found in Help/About screens)

Firefox

Operating system

Win XP

Screen resolution

tested on 1024x600 (reported on 800x600 resolution)

Expected behavior

All the tabs visible, or unused tabs hidden under the arrow

Observed behavior

As the resolution gets lower first the "read" and then the "pending changes" tab is forced partially and then entirely behind the "discussion" tab.

Steps to reproduce

go to the Hungarian Wikipedia
Choose an article with pending changes (go to recent changes and choose anyone with the yellow highlighting)
Start minimizing the browser window size and observe the behaviour of the tabs

Additional notes/comments/screenshots

screenshot

This pending changes tab is a side-effect of the recent changes in Flagged Rev for enwiki, I am not sure it is essential or useful to have on all wikis that use Flaggedrevs. --Dami 14:57, 24 June 2010 (UTC)[reply]

If I'm not mistaken, the tab existed prior to introducing Pending Changes to enwiki, though I think the name of the tab was different (in English it was previously "draft"). Regarding the collapsing behavior, this can be configured by each wiki. So you can configure your wiki to have the "Pending Change" tab collapse upon the browser window shrinking, though I'll need to check if this behavior is enabled on the FlaggedRevs extension. Howief 19:27, 25 June 2010 (UTC)[reply]

The tab might have existed but it was not enabled on Vector (and consequently there was no conscious community decision on making it visible at all times; the edit tab's text changed slightly on Monobook if there were pending changes,but recently this has been moved to this extra tab - which is a bit too much both in visual emphasis and space used) -- if possible, please update the config files so that it gets collapsed or just disable the whole extra tab (so that we revert to the state before pending changes was introduced to enwiki). Thanks, --Dami 23:33, 25 June 2010 (UTC)[reply]

The config file for the FlaggedRevs extension has been updated, so you should be able to set the tab as collapsible for your project. Let me know if you have any issues with this. Thanks. Howief 21:36, 1 July 2010 (UTC)[reply]

Problems with position:absolute edit

Browser (exact version number can be typically found in Help/About screens)

Checked on Opera 10.10, IE6, Google Chrome 3.0

Operating system

Windows XP

Screen resolution

1280*1024, if it matters

Expected behavior

In Ukrainian Wikipedia on orphaned articles we have links to Toolserver located in the upper right corner of the page. In Monobook they are really located there, check random orphaned article, e.g. http://uk.wikipedia.org/w/index.php?title=.nfo&useskin=monobook

Observed behavior

In Vector this text (added with <div style="position:absolute;right:7em;top:0.66em;">) is located not in the top right corner of the page, but on the level of the first line of the text, see http://uk.wikipedia.org/w/index.php?title=.nfo&useskin=vector . Looks like in Vector the position is counted not from the top of the window, but from the bottom of the header, which is confusing for some of the messages

Steps to reproduce

Check any orphaned article in Monobook and Vector, e.g. http://uk.wikipedia.org/w/index.php?title=.nfo&useskin=monobook and http://uk.wikipedia.org/w/index.php?title=.nfo&useskin=vector

Additional notes/comments/screenshots

— NickK 15:30, 25 June 2010 (UTC)[reply]

Well, this is not Vector's fault, any new skin different from Monobook would "break" this. You have to switch to a more flexible system when you assign a specific id/class to absolutely positioned elements like this one and then provide different CSS for different skins. For example look for #coordinates (and .topicon) in en:MediaWiki:Vector.css, en:MediaWiki:Monobook.css, en:MediaWiki:Modern.css etc. Since global CSS can be cached in users' browsers for up to 31 days, you seem to have enough time to do this before upcoming Phase V switch. -AlexSm 16:49, 25 June 2010 (UTC)[reply]

Shortcuts don't work when search&replace dialog has focus edit

Browser (exact version number can be typically found in Help/About screens)

Firefox 3.6.4

Operating system

Windows 7

Screen resolution

1366x768

Expected behavior

Ctrl+T opens a new tab, Ctrl+K selects the search bar etc. etc.

Observed behavior

Nothing happens on keypress

Steps to reproduce

Open the search&replace dialog and give it focus by clicking somewhere on it

Additional notes/comments/screenshots

This does not happen when one of the text fields in the dialog has focus, only when the dialog window itself (e.g. by clicking on the background of the dialog).

--Tgr 23:35, 27 June 2010 (UTC)[reply]

The insert link dialog doesn't allow linking to special pages edit

Browser (exact version number can be typically found in Help/About screens)

Chrome 6.0.447

Operating system

XP

Screen resolution

1024x600

Expected behavior

Upon entering a name of a special page and clicking on insert link a link to the specified special page being inserted into the page.

Observed behavior

The link dialog autocompletes links to special pages but upon checking whether the page exists it gives an "invalid title" error and the insert link button is greyed out.

Steps to reproduce

Click on the add link button
Start typing "Special:"
Choose any of the suggestions and observe

Additional notes/comments/screenshots

The invalid title error (as opposed to the page does not exist info tidbit) comes up even if the given special page doesn't exist. --Dami 12:51, 29 June 2010 (UTC)[reply]

Can reproduce and tracked as bugzilla:24181.--Eloquence 23:49, 29 June 2010 (UTC)[reply]

a bug in italian version. edit

18:25, 30 June 2010 (UTC)89.97.189.164; Browser (exact version number can be typically found in Help/About screens): Internet Explorer 6.0.2800.1106

Operating system: Windows 2000 Professional

Screen resolution: 1024 x 768

Expected behavior: enter a word and search for it

Observed behavior: reset to initial page

Steps to reproduce

Additional notes/comments/screenshots: U can find here the bug, http://it.wikipedia.org/wiki/Pagina_principale, see the right high corner, the research cell.

Have a good work.

               Paolo Testa, Rome, Italy

"undefinedundefinedundefined" are shown in edit page "Special characters" on zh.wiki edit

Browser (exact version number can be typically found in Help/About screens)

Chrome 5

Operating system

Win Vista

Screen resolution

1440 * 900

Expected behavior

See screenshots on the right hand side.

Observed behavior

Steps to reproduce

Additional notes/comments/screenshots

(This is a user report on local comment page) Waihorace 05:54, 1 July 2010 (UTC)[reply]

I haven't been able to reproduce on Mac/Chrome, but I've logged this as bugzilla:24220 Howief 21:47, 1 July 2010 (UTC)[reply]

undo shortcut not effective on things inserted via the new toolbar edit

Browser (exact version number can be typically found in Help/About screens)

Chrome 6.0.447

Operating system

XP

Screen resolution

1024x600

Expected behavior

After using the toolbar to insert something into the editarea and clicking CRTL+Z, the insertion is undone.

Observed behavior

Pressing CRTL+Z has no effect on items inserted via the toolbar.

Steps to reproduce

open an edit window
click on buttons in the toolbar (for testing purposes try the bold button)
press CRTL+Z

Additional notes/comments/screenshots

The option to undo is greyed out in the right-click menu, as well, after the toolbar has been used (changes subsequent and preceding the use of the toolbar can be undone and redone as expected). --Dami 13:31, 1 July 2010 (UTC)[reply]

Search works incorrectly with brackets and hyphen edit

Browser (exact version number can be typically found in Help/About screens)

In fact any (checked on Opera 10.10, IE6, Google Chrome 3.0)

Operating system

Windows XP, although not an OS issue

Screen resolution

1280*1024

Expected behavior

If one types some search query with brackets or hyphen, old search usually ignored these symbols and offered variants both with and without these symbols

Observed behavior

Also new search does ignore these symbols, suggestions are displayed incorrectly. All of them tend to have the same symbol on the place of a bracket or a hyphen, which may be different for different suggestions. For example, Динамо Київ was typed on screenshot 1, the bottom variant really is Динамо Київ (журнал), although the top one is different, it is Динамо (Київ), incorrectly displayed as Динамо Київв). Same for screenshot 2, all links but the bottom one begin with Динамо (с, the bottom one begins with Динамо-С, and this variant is copied for other variants. However, links are correct

Steps to reproduce

Type any search query where some of the suggestions have brackets and/or hyphen and some not

Additional notes/comments/screenshots

Screenshot 1

Screenshot 2

Reproduced and logged as bugzilla: 24237 - Howief 17:31, 2 July 2010 (UTC)[reply]

Malay Wikipedia SiteNotice edit

Browser (exact version number can be typically found in Help/About screens)

Google Chrome

Operating system

Windows 7

Screen resolution

Expected behavior

The link on the site notice is different compared to the link placed in translation on Default Switch#Phase IV Deployment page. The current link on the sitenotice links to an English version although a translated version has been made.

Observed behavior

Steps to reproduce

Additional notes/comments/screenshots

Text Quality box missing edit

Browser (exact version number can be typically found in Help/About screens)

Google Chrome : 5.0.375.99

Operating system

Windows XP SP2

Screen resolution

1024x768

Expected behavior

The Text quality box ( {{TextQuality}} ) was displayed in the non-beta version of Wikimedia

Observed behavior

The Text quality box is not displayed

Steps to reproduce

Click on edit in a wikisource page.

Additional notes/comments/screenshots

Browser (exact version number can be typically found in Help/About screens)

Various

Operating system

Various

Screen resolution

Various

Expected behavior

Project wide site notice in the style of the skin.

Observed behavior

Project wide site notice in the style of the new skin, creating a weird jumble at the top of the page.

Steps to reproduce

Go to http://fy.wikipedia.com. See ugly style and no site notice. Log in quickly. See more acceptable skin, but with ugly style site notice. Same on http://fy.wiktionary.org.

Additional notes/comments/screenshots

Why do I have SUL, then, BTW?

Blender 3D- Noob to Pro - Beginner Tutorials.pdf File suddenly stopped at page 140. edit

Browser (exact version number can be typically found in Help/About screens): Firefox 3.6.6

Operating system: Windows XP sp2

Screen resolution: 1024x768

Expected behavior

Observed behavior

Steps to reproduce

Additional notes/comments/screenshots

I downloaded the file "Blender 3D- Noob to Pro - Beginner Tutorials.pdf" In the 2 page contents it shows a lot of things but the book ends suddenly at page 140(At 1/4 th of the contents). All the things missing are available in the online book. The last line of page 139 is also incomplete. So i guess you should fix it.

Logo cut off in en-wb edit

Browser (exact version number can be typically found in Help/About screens): Mozilla Firefox 3.6.6

Operating system: Windows XP SP3 fully patched to date

Screen resolution: dual monitors 1280x1024; browser in secondary monitor

Expected behavior: Wikibooks logo would either resize to fit space, or space would fit logo (as happens with old code)

Observed behavior: Left and right edges of logo are clipped ("pen books for an open wor")

Steps to reproduce: Open any en-wb page and examine logo.

Additional notes/comments/screenshots: Seems to happen only on some browsers, but on those is utterly consistent.

Improper Rendering when Producing PDF on hindi language wikimedia projects edit

Browser (exact version number can be typically found in Help/About screens): Mozilla Firefox 3.6.0

Operating system: Windows 7

Screen resolution: 1280x800 pixels

Expected behavior: PDF text should be same as on page for Hindi language Wikimedia projects and produced with proper rendering.
Observed behavior: Improper Rendering when Producing PDF for Hindi language Wikimedia projects
Steps to reproduce: Open any Hindi language Wikipedia/wikisource/wikshnary/ and any page on other projects and download as pdf compare the text on page and text in produced pdf file.
Additional notes/comments/screenshots: Because this problem is related to produced pdf, It is browser and Operating system Independent.