VisualEditor/Feedback/Archive/2013/05

unable to edit this page

VE is unable to edit this page - https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013 LeslieCarr (talk) 15:37, 3 May 2013 (UTC)

That's because the page is entirely wrapped in <div>s which, until Tuesday, were not editable - I just added this and their contents will be editable when the next release rolls our (but not the whizzy CSS formatting, which will come later). Jdforrester (WMF) (talk) 15:40, 3 May 2013 (UTC)

text pasted into italic section appears plain

Select a single word of text in some other app, paste it into an italic block in the editor, and the italics are closed and reopened either side. This is in Firefox 20 on Linux using the keyboard. S Page (WMF) (talk) 15:23, 4 May 2013 (UTC)

Yes, all copy-paste from external sources are stripped of all formatting before insertion; we're fixing this in 33105. I'm not sure we'd also want to provide a "paste without formatting and inherit local styles" tool, as this will be a mess to provide. Jdforrester (WMF) (talk) 15:27, 4 May 2013 (UTC)

A mess ?? But this is the standard behaviour in any word processor software. I don't speak here of pasting formatted text. But, when there is plain text in the clipboard, pasting it must do the same as typing the same text with the keyboard — that is : give it the local formatting. Nnemo (talk) 18:22, 6 May 2013 (UTC)

Yes, but giving users three options:

• Paste with remote formatting
• Paste with local formatting
• Paste with no formatting

... feels like a mess. Jdforrester (WMF) (talk) 22:09, 6 May 2013 (UTC)

The choice would be between “original formatting” and “local formatting”. “No formatting” would not be an option. But, anyway, this does not apply to plain text in the clipboard. When there is plain text to paste, there is no choice, the text simply has to be pasted, without interfering with formatting. Nnemo (talk) 00:08, 7 May 2013 (UTC)

gratuitously different Saved message from PostEdit Feedback

Edit source on most wikis shows the gray PostEdit Feedback "Your edit was saved." with green check and a Unicode × symbol to close, which goes away after a timeout. The VisualEditor "Your changes to $1 have been saved" has a different behavior, look, and location. S Page (WMF) (talk) 15:23, 4 May 2013 (UTC)

Yes, because it pre-dates "PostEdit Feedback". We asked for E3 assistance in switching to the new, built-in version some time ago. :-) Jdforrester (WMF) (talk) 15:24, 4 May 2013 (UTC)

Small Failure

During the edition with the visual editor, an unwanted modification happened: ></table http://es.wikipedia.org/w/index.php?title=Alcatraz_%28serie_de_televisi%C3%B3n%29&diff=66703778&oldid=66536861

The prior disordered the table. Supousedly tables can not be edited, but this one was :)--3BRBS border|20px @ 16:31 6 may 2013 (UTC)

Thank you for your feedback! Sorry about this bug - we discovered it last week. It's due to a jQuery bug that we encountered with new code, which is now fixed in "master" ([1], [2]) and will be made available in production for eswiki on Wednesday 8 May.

Table structures aren't editable (no adding columns or rows), but cell contents should be - if you have any problems, please report back! :-) Jdforrester (WMF) (talk) 00:53, 7 May 2013 (UTC)

VisualEditor removed watch status

I edited a page that was on my watch list with the VisualEditor. When submitting it the "Watch this page" was unchecked and when I just saved as normal VE removed the watched status of the page.

((There's a small possibility that I actually clicked the watch star and then opened up the VisualEditor after that instead of reloading first)) Daniel Friesen (Dantman) (talk) 01:29, 8 May 2013 (UTC)

Hey, this is odd behaviour indeed. Do you know what browser you were using at the time? Jdforrester (WMF) (talk) 01:30, 8 May 2013 (UTC)

VE removes normal edit page's active/selected status

When you are on the normal edit page and VE replaces the edit button with an "Edit source" button it removes the selected/active styles from it. Daniel Friesen (Dantman) (talk) 02:12, 8 May 2013 (UTC)

Yes, sorry, this is now fixed in master and will be deployed in the new branch (wmf4) released here on 13 May. Jdforrester (WMF) (talk) 02:13, 8 May 2013 (UTC)

On the Right Path

I just finished reading Karen McGrane's recent column on A List Apart in which she discusses the separation of content from presentation. It made me think of the work around VisualEditor and, in my humble opinion, a reaffirmation that you're on the right track.

http://alistapart.com/column/wysiwtf Ckoerner (talk) 15:57, 8 May 2013 (UTC)

Thank you! I agree with the value in the split, and we're keen to focus on tools that help our editors create content rather than endlessly fiddle with presentation (though tools for setting CSS/etc. will be forthcoming). Jdforrester (WMF) (talk) 20:19, 8 May 2013 (UTC)

Linking to current document's section headings

Trying to make a local link to a section,

• The link pop-up dialog doesn't offer any help
• In wiki markup I know to type a leading #, when I start typing #Something the dialog displays

 New page
 [checkmark] #Severity (in red)
 Matching page:
 $1

The resulting link to a section works, but the dialog is misleading. S Page (WMF) (talk) 20:31, 8 May 2013 (UTC)

Feedback posting to LQT notice page, not LQT board

I'm not sure why my feedback ^above^ from VE got inserted up here. I copied and pasted my feedback from a text editor into the VE [Leave feedback] dialog, it looked fine there and I got a confirmation from VE. S Page (WMF) (talk) 20:32, 8 May 2013 (UTC)

This is because we're using the core MediaWiki feedback tool, and LiquidThreads doesn't extend the API that the core tool uses, just captures section=new events through the UI. See bugzilla:41276. It's annoying, but not enough to switch off the tool. Jdforrester (WMF) (talk) 20:33, 8 May 2013 (UTC)

Rapid-fire editing

I edited a page with VE and saved successfully. I immediately opened the VE again, but the page I was given to edit did not have my most recent change. This seems to happen whenever I edit twice within a few seconds. Ypnypn (talk) 00:01, 9 May 2013 (UTC)

Sorry about this bug; we've fixed it in master but it's not yet deployed - it will be here on MediaWiki.org on 13 May and more widely soon afterwards. Jdforrester (WMF) (talk) 03:15, 9 May 2013 (UTC)

Really weird bug

That "pawn" bug (bugzilla:48346) must be one of the weirdest bugs I've ever seen. Here's another strange one, seen in Firefox 20.0.1:

1. Go to w:Mersin İdmanyurdu SK and invoke VisualEditor
2. The cursor should automatically be on the first (blank) line. Start typing
3. As well as a appearance of a pawn, strange duplication of characters starts to occur

Not only is VE playing chess, but perhaps also some drinking games :) This, that and the other (talk) 10:41, 11 May 2013 (UTC)

Yes, this is the same bug; I think we've fixed these problems in master (which means it will be fixed here tomorrow, and on enwiki next week), but we'll verify. Jdforrester (WMF) (talk) 22:17, 12 May 2013 (UTC)

Surface cover over image link

Try the visual editor on https://www.mediawiki.org/wiki/User:Dantman/Code_Ideas and scroll down to the image.

iirc that's supposed to be an image link, not an image. And in VE the entire thing isn't covered on hover making it still a link. Daniel Friesen (Dantman) (talk) 19:49, 12 May 2013 (UTC)

Oh dear, that's an unfortunate bug in Parsoid; filed as bug 48387. Thanks for the report. Jdforrester (WMF) (talk) 20:04, 12 May 2013 (UTC)

Would love to have images and file insert/links on this ASAP

Would love to have images and file insert/links on this ASAP 152.160.16.98 15:41, 13 May 2013 (UTC)

Agreed; we're working on this and hope to have it available in a few weeks. Jdforrester (WMF) (talk) 15:41, 13 May 2013 (UTC)

VisualEditor plus WikiEditor

You should be able to go back and forth between WikiEditor and VisualEditor until all the features available are identical If VisualEditor isn't going to have a button for creating tables and one for images (and one for wikitext) - I hope this is the plan when released as it would obviate the need for both editors. Superman57 (talk) 22:25, 14 May 2013 (UTC)

I agree that it would be good to allow editors to switch between VisualEditor and the wikitext editor, and we intend to build it, but unfortunately it is unlikely for us to be able to deliver it in the next month or so. Our focus is on providing the ability to add and alter images, references, templates and categories, which we feel are more important than altering the structure of tables. We do not intend to build an "insert wikitext" button, though it's not impossible.

(BTW, the wikitext editor is different from WikiEditor, which is an extension deployed on Wikimedia wikis that gives it a toolbar.) Jdforrester (WMF) (talk) 22:30, 14 May 2013 (UTC)

Maybe just allowing administrators to allow a link display above the editing window for 'view in wikieditor' that users could click if they needed to create a table, or wanted to enter in wikitext. This is increasingly necessary for wikis used in work environments (tables) and also for software developers who use wikis for housing their information and prefer to enter information directly in wikitext. Superman57 (talk) 22:15, 11 June 2013 (UTC)

Whether it's available to admins or to everyone doesn't alter the scale of the engineering challenge. Okeyes (WMF) (talk) 16:42, 14 June 2013 (UTC)

Understood - however if VisualEditor is to be used as a default editor / toolbar, you can't leave users that are already using the functionality of WikiEditor hanging by requiring admins to make a false choice between the two when upgrading.

VisualEditor serves a more novice editing crowd and brings in users, but it can't happen at the expense of established users that are used to the WikiEditor table functionality / preference for coding in wikitext - which everyone has been using to enter information for years.

Currently it looks like VisualEditor as a toolbar solution solves one problem by creating another one - favoring new users over established users and content - there has to be a compromise between the two; ensuring that tables and wikitext are options in one way or another, allows both sets of users to use VisualEditor effectively. This is especially true in company settings where there are an equal number of novice and expert mediawiki users - both options have to be available. Superman57 (talk) 21:01, 2 July 2013 (UTC)

I don't understand the "false choice between the two when upgrading". All users are supposed to have both editors available to them. Whatamidoing (WMF) (talk) 05:57, 7 July 2013 (UTC)

My bad - I see that now - separate 'edit source' tab allows wikitext editing using WikiEditor toolbar (which includes 'insert table' wizard). Thanks! Superman57 (talk) 22:14, 8 July 2013 (UTC)

Workflow for creating links

There are essentially two ways to create a link:

1. You enter the link's text, select it, click the link button, and choose the link target.
2. You click the link button first, enter the target and get out of the dialog, at which point the link text (identical to chosen link target) will be entered.

I'm not sure which method users prefer, but it's clear that both methods should work seamlessly. However, with the current setup both methods are problematic:

1. Once the correct target has been picked (either by entering it, or by selecting from the list), it is not quite clear what the user should do next. Is the back arrow the right thing to do, or does that cancel the selection? Should I simply click outside of the dialog, or does that cancel? It turns out: if the target was selected from the list, both these actions are correct and do not cancel the choice, but if the link target was entered by hand (and not followed by Enter!), both actions do cancel the choice. The fastest way is to enter the link target and hit Enter twice. This is all fairly unintuitive.
2. With this method, the user will often have to adjust the link's text afterwards, for instance in the case of plurals or if the target article is disambiguated with parentheses. But it is not clear to the user that adjusting the link text is safe and won't create a broken link; indeed the whole distinction between link text and link target remains obscure.

I have checked the workflow of entering links in LibreOffice, Gmail and Word; they are all basically the same as in the Visual Editor, with two big differences: the selection box has a clear OK button, and it contains separate clearly labeled boxes for the link text and the link target. I believe both of these changes make a lot of sense.

When entering the dialog from an existing link or from highlighted text, that text should automatically be entered into the link text's box, with a corresponding suggestion for the link target preselected, but both boxes should be editable independently. The link target box should have a list of further suggestions underneath. Once everything is OK, clicking the OK button or hitting Enter should create the link; clicking outside of the dialog box or hitting the back arrow should cancel the action.

There is another minor issue: right now, when hovering over an existing link, the link target is displayed; when clicking on the link, a link symbol occurs which does not show the link target. The meaning of that symbol is not clear; it turns out that clicking on it will allow to change or remove the link. Gmail solves this issue as follows: hovering will not display anything, but when clicking on a link, a tiny window shows up giving the link's target and options to change or remove the link. I find that completely self-explanatory. AxelBoldt (talk) 21:54, 15 May 2013 (UTC)

All of that makes sense, except “clicking outside of the dialog box”. Closing the dialog and discarding what the user has entered just because some click happened outside of the box would not be user-friendly at all. Nnemo (talk) 00:56, 17 May 2013 (UTC)

I agree with all of this. The current link workflow is really confusing and non-standard, even for experienced users. This, that and the other (talk) 03:08, 18 May 2013 (UTC)

Agreed. It's very confusing. Ypnypn (talk) 14:52, 21 May 2013 (UTC)

Comments

I would like some way for <!-- comments --> to appear in the VE. Ypnypn (talk) 15:02, 21 May 2013 (UTC)

+1 Helder 11:39, 7 June 2013 (UTC)

+1 Panpog1 (talk) 02:02, 12 June 2013 (UTC)

Yes. In case it is unclear, on English Wikipedia, comments are often used for communication between editors about matters of particular importance, particularly local consensus. For example,<!-- do not add this person's date of birth! They have requested that it is removed -->. Similar things probably happen on other wikis. This, that and the other (talk) 10:42, 12 June 2013 (UTC)

How about having a special template for the purpose, only visible in the editor? The template could have parameters for the date added and an optional link to the relevant talk page section. Pointillist (talk) 12:54, 12 June 2013 (UTC)

Yes, this (support for HTML comments) is on our backlog, and we hope to get to it soon after the beta release. There's also some work by a GSoC student on a rather different, "co-ment" style of commenting system which we could adopt in VisualEditor once that's done (see bug 46440). Jdforrester (WMF) (talk) 16:35, 12 June 2013 (UTC)

Using up-arrow to scroll to the top of a long article doesn't work

Go to some long article (so long that it won't fit on one screen in your browser), start the visual editor, use down-arrow to walk all the way down, then up-arrow to walk all the way back up to the top of the article. It's not possible: the first lines of the article will be obscured by the visual editor's menu bar; the only way to make them visible is using the scroll bar. AxelBoldt (talk) 23:24, 23 May 2013 (UTC)

Tracked in bugzilla:48787, now mostly-fixed. Jdforrester (WMF) (talk) 16:33, 12 July 2013 (UTC)