Talk:Releases/Babaco/Compatibility Matrix

Statistics

Are now updated to include IE 9 for future testing. Meanwhile: Can someone check the Fox-Numbers? They are WRONG: 45% fox3 + 45% fox35 = 90% FOX TOTAL.

Feedback

Questions on Test Procedure

The 5th instruction, under the "Navigable Table of Contents" section of the Babaco test procedure states: "Verify that moving the cursor from one section to another causes the various sections to be highlighted in the table of contents". Based on my understanding of the Babaco test procedure, this step, refers to verify the moving cursor on the edit page tab of the article. Unlike the pictures in the Babaco test procedure, there is no table of contents pane. Instead, upon pressing the "Show Preview" button, the Table of Contents appear in the previewed text (displayed above the edit box). This seems to be a change from the table of contents pane. Is it expected that moving the cursor in the edit box will highlight the corresponding section in the Preview window? It is not clear to me what is expected given the current configuration (For example [1] ).

Please clarify. Thanks. --User:Mknight1130 made 01:17, 2 August 2010 (UTC)[reply]

I followed testing procedure: I found a bug. Enviroment: WindowsXP, Chrome 2.0.172.43.

Verify that clicking one of the suggestions causes the field to be filled with the article's title and the status icon become green

No mouse click detected while choosing a prompted link

go back on home page by clicking on return

I hope this will help you. bye, --Quaro75 11:57, 12 September 2009 (UTC)[reply]

Test passed with success

Everything worked fine for me, using Opera 9.64. Well done ! 84.227.159.176 19:24, 15 September 2009 (UTC)[reply]

Google Chrome 3

Everything but the TOC in edit mode seems to work on Chrome 3. The TOC doesn't show up for me in edit mode, but I'm not sure if I'm doing something wrong in that respect or what. --en:User:Dinoguy1000 as 72.251.164.58 04:54, 17 September 2009 (UTC)[reply]

Can you try the prototype wiki to see if the bug occurs there? --Catrope 19:03, 6 October 2009 (UTC)[reply]

Edit TOC fail with long page title

I edit this, click on the "References" entry in the edit TOC. The bold page title in the TOC (section 0) gets "un-bolded", but the edit box doesn't jump to references. Also, references doesn't get bold, so there's no bold entry in the TOC anymore. Clicking on a TOC entry again returns normal function. I assume that has to do with the page title being so long that it is one line longer in bold than in "normal". Observed in FF 3.5.3 on Mac OSX 10.6.1. --Magnus Manske 20:35, 21 September 2009 (UTC)[reply]

We've fixed the TOC so it now cuts off long titles rather than breaking them over lines. If that's the cause of the bug you experienced, it should be fixed now. --Catrope 18:58, 6 October 2009 (UTC)[reply]

Navigable TOC fails with IE 8 using Vista and XP

Dodoïste 15:17, 3 October 2009 (UTC)[reply]

As an update, it only fails when IE8 is forced into Compatibility view by the MS list. When not in Compat. mode, it displays and functions correctly, except that all inserted text is forced to the beginning of the page code. And when clicking a link in the TOC, it places the cursor near the intended section but not on it.

Other than that, everything works fine. It only needs a little work and removal from the Compat. View list, which can be done only for the whole domain wikimedia.org (see here: [2]), or by adding this HTML to the beginning of the pages (as a temporary measure, preferably): <meta http-equiv="X-UA-Compatible" content="IE=IE8" >

Hope this helps. I would add a screenshot if I had an account. --72.95.94.142 01:20, 4 October 2009 (UTC)[reply]

These issues have been reported (and fixed) as bug 20874 and bug 20900. --Catrope 19:01, 6 October 2009 (UTC)[reply]

Browser figures

The statistics from W3C are bogus. Firefox 3 is not used by more than 40% of internet users, just those who are tech-savvy enough to visit W3C. Most general statistics show that only about 20% of internet users use any Firefox version, and that 60% still use IE6 or IE7. So if the new UI doesn't work properly in those two, it's a rather big deal. -- JovanCormac 11:43, 5 October 2009 (UTC)[reply]

Good on Firefox 3.5.3

I followed the testing procedure on Firefox 3.5.3 on Win XP. All tests worked as expected. —Veeven 10:05, 6 October 2009 (UTC)[reply]

Text browsers

Mention lynx, w3m. Jidanni 01:22, 14 October 2009 (UTC)[reply]

Testing Omniweb 5.10

v5.10 SP r116127

On the prototype page showing the featured article, clicking on "Edit" only produced this error (on an otherwise blank page):

Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting ')' in /srv/org/wikimedia/prototype/extensions/UsabilityInitiative/ClickTracking/ClickTracking.hooks.php on line 64

The URL looked OK:

http://prototype.wikimedia.org/en-wp/index.php?title=Manchester_Small-Scale_Experimental_Machine&action=edit

I had not created an account at that stage. So I went back and created an account, logged in and tried the process again, but the same error occurred. It looks like a missing final parenthesis, but I'll leave that up to you. ;)

Omniweb generally has very good standards support. Based on WebKit (like Safari and Camino), it's an OSX browser with many cute gadgets –– er, useful functions. Clytie 07:47, 16 October 2009 (UTC)[reply]

v5.10.2 SP r120607

Bummer, I thought maybe a later release would help. Nope. I'll see what happens when I test the Wikipedia Beta. Clytie 08:34, 16 October 2009 (UTC)[reply]

Testing at a later date, I am now able to edit the prototype test page: it opens. However, all I see is a standard edit frame, without even the standard toolbar, much less the beta toolbar. The TOC does not show. I can't do any of the things requested in the tests. I note these results mirror those using Safari 4, which isn't surprising, since both Mac browsers are based on WebKit. Do we know what is causing this? Screenshot: Media:Omniweb_WikiPrototype.png Clytie 13:40, 5 March 2010 (UTC)[reply]

Navigable TOC not working in FF3

I'm working on enwp, and the sidebar is added in edit mode when I have the preference enabled, but there is nothing in it on any pages. Firefox 3.5.3 on Windows Vista. The Firefox error console comes up with:

Error: $("<a />").attr("href", "#").addClass("section-" + structure[i].index).data("textbox", context.$textarea).data("position", structure[i].position) is undefined
Source File: http://en.wikipedia.org/w/extensions/UsabilityInitiative/js/plugins.combined.min.js?44
Line: 152

--Drilnoth 19:47, 20 October 2009 (UTC)[reply]

I have the same problem, under the exact same setup.--Danaman5 16:18, 27 October 2009 (UTC)[reply]

Good with Firefox 3.0.13 on Win XP

Everything worked fine with Firefox 3.0.13 on Win XP, and I love it.

--Surak 03:42, 4 November 2009 (UTC)[reply]

Poor in Safari 4 on Mac

Modal Windows do not work at all, cannot insert or anything, but do exit out effectively. Also, table of contents does not show. File:Wikisafari4.png

Navigable ToC missing on Firefox 3.6 Beta 5 or maybe due to gadget

I'm using FX 3.6 beta 5. Whenever I enable the Friendly gadget in preferences, I'm unable to see the ToC sidebar in the edit box. I see the sidebar but there's no links. Also seeing the problem in Chrome 4 alpha. Disabling the gadget fixes it in both browsers. Only seems to happen on the English Wikipedia, not on the Protoype wiki. Mahanga 05:17, 19 December 2009 (UTC)[reply]

Testing http://prototype.wikimedia.org/es-wp/

I'm testing http://prototype.wikimedia.org/es-wp/ with Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7.

1) When the editbox has no focus, it must show anyway a cursor in order to indicate where the command will insert the content (i.e. special characters).

2) When inserting special characters, the cursor must move to the right (but RTL).

3) In "insert link" dialog, the text in spanish must be:

For the first text (Target page or URL:): "Nombre del artículo:" (internal link) and "Dirección de la página:" (external link), or "Nombre de artículo o dirección URL:" (both).
Fot the second text (Displayed text:): "Texto mostrado" or "Texto a mostrar".

4) When inserting headers, it must show a dialog to insert the texto or, at least, select the text of the header in order to replace it.

5) When click A+/A- (font size) with no selected text, it should select the new inner text. Then, if repeated click A+/A- it generates a text with double "big" tag. Now it generates two texts with a simple tag.

6) When click A+/A- with selected text it should detect if there's null combinations like "<big><small>Text</small></big>", in order to delete to generate the equivalente "Texto".

7) When inserting embedd files it should open a dialog with details of the image (size, thum, comments).

8) Search and replace don't work for me. The dialog works ok, but has no funcionality.

Eloy 18:54, 20 January 2010 (UTC)[reply]

Testing in IE8, Windows 7

Testing was successful in Internet Explorer 8 (version 8.0.7600.16385), Windows 7 Home Premium. All of the features listed in the testing procedure worked as expected.

A few points, though, not entirely related to the testing procedure:

Sometimes, after scrolling the edit box using the mouse wheel, clicking the edit box caused the text cursor to jump to the end of the article. Not entirely sure how to reproduce it.
I couldn't highlight the text using the cursor. Not sure if this is intentional behaviour for the testing environment, but I figure I'd note it down.
On opening the "Insert link" dialog box, I found that the entry boxes each contained a single space. When adding an external link, for example, the link would be inserted as "http://%20en.wikipedia.org", and not "http://en.wikipedia.org".

Still, the test procedure worked, so that's okay. 92.18.90.123 20:08, 23 April 2010 (UTC)[reply]

Firefox 3.6.3

English Prototype: A sounding success for me, cant wait till its out of beta :D