User blog comment:Toughpigs/Wikia's new Forum demo/@comment-5473581-20120726035605/@comment-5473581-20120728025211

Various editor problems, originally reported on
 * http://community.wikia.com/wiki/User_blog:Sarah_Manley/Try_the_New_Wikia_Editor
 * http://community.wikia.com/wiki/User_blog:Sarah_Manley/New_Editor_Scheduled_for_Sitewide_Release

Category Module I although I prefer to edit with the RTE disabled, I also prefer to use the old-style auto-completing Category Module - which is still displayed at the bottom of each article. I logged in to my non-admin testing account recent and noticed that this Category Module is still enabled as part of the RTE. There's an option in the preferences to enable/disable to category module, but with the RTE also disabled that only controls whether are entered in the main edit area or in a small category-only area.

There was a long standing category related bug where after previewing an article, and pressing the submit button in the preview window, the categories would be duplicated - I'm unable to reproduce this problem right now, so maybe it was fixed recently, but it was happening for many months. Perhaps it was fixed during the mediawiki upgrade

Tabindexes
 * User_blog:Sarah_Manley/Try_the_New_Wikia_Editor
 * User_blog_comment:Sarah_Manley/New_Editor_Scheduled_for_Sitewide_Release/@comment-5473581-20120728025211-20110908003107?permalink=321655
 * Internal links to blog comments are broken, here's an external link to the same comment

When pressing tab while editing a page first, the focus first goes to the edit summary box, but then it goes to the word "Wikia" at the top of the page. Prior to the editor update, the tabindexes were set correctly to tab to the minor edit button then the submit button (my memory is fuzzy whether it tabbed to preview). In the new editor, the tabindexes just aren't defined. I added some JS to fix this and restore a sensible tab order, but it's currently non-functional due to an upgrade related problem causing multiple sidebar modules to vanish. (The JS isn't causing the problem, it also occurs here.) From my original comment in August 30. As this has still not been fixed, the new editor is therefore still not ready for deployment, despite having been deployed for 11 months now.
 * In the comments where I originally reported this, it was indicated that this problem would be fixed.
 * The tab order of the old editor is: edit box, summary, minor edit checkbox, follow checkbox, publish button, preview.
 * The tab order of the new editor is: edit box, summary, wikia link on the top bar, and then all of the links on the top bar.
 * You have to press tab approximately 60 times to get to the minor edit checkbox. The new editor is NOT ready for deployment.
 * This comment says it was going to be fixed, but it hasn't.
 * And by attempting to direct link to a comment, I've revealed another bug: links to blog comments are partially broken. An external link works, but an internal link does not.

edit summary textarea Previously, the edit summary was a single line input, which meant anything typed there was saved by the browser when the form was submitted, so common edit summaries would autocomplete locally, making leaving edit summaries a lot quicker. (I often do essentially the same edit to multiple pages to fix related problems at once, so a saved edit summary is helpful) Textareas do not do this, primarily because they are multiline. Since newlines in edit summaries are ignored anyway, there isn't any benefit to using a textarea.
 * I was never told that this would be fixed, but that it would be considered. Whether or not anything is done about it, this is an instance of the editor upgrade removing functionality.

Edit summary length There is no max length defined for the edit summary textarea - which means you can type a nice long descriptive edit summary, only to have it truncated in the history. Setting the max length attribute would allow it to be reworded instead of having it truncated without warning.
 * This may have been a problem in the old editor too.

page down scrolling more than a single screen The behaviour of the page-down button should be to move the currently visible line at the bottom of the input area to move to the top, either just out of view or as the first visible line - this is the de facto expected behaviour as this is how it behaves everywhere but wikia. What it is actually doing is moving the cursor down exactly one page, but if the cursor is in the middle of the screen, it is now at the top. The only time it works as expected is if the cursor was already at the top of the screen. This means that some content is scrolled past, unseen. I'm using Chrome and WinXP and realise this may be a browser specific problem, but I don't remember this being a problem with the old editor.

I'm not done going through my past reports, but have to go AFK for a while. If there's a reply by the time i get back to this, I'll leave a new comment, but if there's no reply, I'll edit this one. I think I'm done with this list.