| Jdforrester-WMF | |
| May 8 2013, 9:31 PM |
| F28628688: image.png | |
| Apr 12 2019, 2:51 PM |
| F28629206: image.png | |
| Apr 12 2019, 2:51 PM |
| F28628692: image.png | |
| Apr 12 2019, 2:51 PM |
We use textarea which means that browsers don't suggest text from previous uses.
See Also:
T53903: If the user only has edited in one section, VisualEditor should insert the name of the edited section into the edit summary
T54859: VisualEditor: Populate the edit summary for simple changes
T54085: VisualEditor: Provide buttons for locally-configured frequent edit summary contents
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Release | None | T84936 Release VisualEditor-MediaWiki as "1.0" | ||
| Declined | matmarex | T54133 VisualEditor: Edit summary box should be a text input box and not textarea | |||
| Resolved | • ppelberg | T50274 VisualEditor: For edit summary field, give users an auto-fill drop-down (or similar) of recent edit summaries they've used |
I have a (very hackish) user script for providing access to previous edit summaries: https://de.wikipedia.org/wiki/Benutzer:Schnark/js/veSummary.js If anybody wants to use code from there to fix this in VE itself, feel free to do so.
How plausible would it be to use input but magically make it word wrap, even though the HTML spec says it mustn't?
Bartosz had a go at this a few years ago, but then I pointed out some IME issues and he gave up. I think my API approach is probably the simplest.
(That was https://gerrit.wikimedia.org/r/#/c/212795/, it tried to dynamically swap between <input type=text> and <textarea>.)
It's not possible to make <input> wrap. If anything, it could be possible to make <textarea> have autocomplete (nothing in the spec prohibits it, the attribute is valid on textarea and the new 'autocomplete' values include one that is only valid on multiline content). But no browser seems to actually support this.
(Actually, Chrome does support autocomplete="street-address", huh. But that doesn't really help us here, it doesn't remember and autocomplete values in textareas on its own and there doesn't seem to be a way to make it do that.)
A solution could also be HTML5 contenteditable, at least its support in browsers is acceptable. (see StackOverflow question about this topic)
I don't think that list: 'recentchanges' is the best approach, as it will only give you summaries from the last month. When you are not very active, these are very few, so won't help much. In my script https://de.wikipedia.org/wiki/Benutzer:Schnark/js/veSummary.js, I instead decided to use list: 'usercontribs' instead.
But neither will give results for users not logged in. Even if they have a static IP, mw.user.getName() will only return null.
There are a bunch of features that don't work for logged-out users; I'd not worry too much about that.
According to https://developer.mozilla.org/en-US/Firefox/Releases/59#HTML Firefox now supports autocompletion of textareas, so it should actually be possible to have native autocomplete suggestions, at least in Firefox.
Change 495451 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Edit summary autocomplete
Why doesn't this make use of T50274#4048873 ? It looks like Firefox, Webkit, and Chromium all support autocomplete (even though Mozilla.org indicates otherwise, the link to the Chromium indicates the bug is fixed since Jan 2018)...
Change 495451 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Edit summary autocomplete
I agree, this is well done.
My only problem: when I have entered a summary, the drop down appears. When I hit the hotkeys for save, the system will complete the summary with the top item whatever the value of my original summary was. (This is not how it works in old WTE.)
The particular issue was that I wanted a summary of "clean table", but after having entered the entire thing in it removed the exact match and attempted to add the lengthier summary after hitting cntrl + enter, and then chose not to save. (The biggest win for me is that the hotkeys should always save regardless of the current value of the dropdown.)
Happy to split this to a different task if it seems like a significant chunk of additional work...
No. But if you make 200 more edits, it'll automagically go away. The tool only looks back at your most recent 200 edit summaries.
@Esanders, Izno's problem is going to drive me nuts. When there's an exact match, it needs to use that exact match, and not suggest something longer. If I've typed r, and the options it finds are 35 instances of r and one of Re-ping in my last 200 edit summaries, then it should definitely be suggesting r and not the other longer one.
(In the meantime, the workaround is to hit the Escape key.)
So I have to be patient. And be careful: I've already accidentally entered some bad summaries while editing. :/
This is a big problem for me as well. My most common summary on talk pages or project discussion pages is just “reply”, but the first suggestions are all like “reply (something something)”, “reply, something else”, etc. When I press Ctrl+Enter out of habit – for years, VisualEditor has trained me that Ctrl+Enter in the summary field means “save” – then it will “complete” my edit summary with some gibberish that makes no sense in the current context, and if I don’t notice it I’ll save an edit with a nonsense summary.
Is it possible to opt out of this feature until that’s fixed?
The edit summaries are pulled from the API and old edit summaries are immutable so I don't see an easy fix for this without using another storage system. Suggestions welcome.
No, but it shouldn't be too hard to fix. In the meantime you can press escape before ctrl+enter.
Change 506191 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] EditSummaryWidget: Don't highlight first automatically
The above patch stops the first item being highlighted automatically. You can test the effect on live by pasting ve.init.target.saveDialog.editSummaryInput.lookupHighlightFirstItem = false; into the console after the save dialog has opened.
Change 506191 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] EditSummaryWidget: Don't highlight first automatically
BTW since you're in the area there's a TODO there that was waiting on what is now a task that you closed a week or two ago.
// HACK: Disable pending animation. Should be made an upstream option (T220204) // Parent method
T220204: Make pushPending optional on OO.ui.mixin.RequestManager / OO.ui.mixin.LookupElement widgets
@Izno Now done in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/VisualEditor/+/512227. I think we were still waiting for MediaWiki to be updated to use the new version of OOUI of something.