Last modified: 2014-08-19 19:34:10 UTC
The Hebrew Wikipedia, as well as a few others, have a gadget for canned edit summaries: https://he.wikipedia.org/wiki/MediaWiki:Gadget-Summarieslist.js If the forceeditsummary user preference is enabled and the user uses this gadget to insert a summary, the warning about an empty edit summary is issued, even though it shouldn't. I suspect that the problem is in the VE code. As far as I can see, this preference is checked in modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.js on line 867 and the summary values are not what I expect them to be. (See also Bug 52085.)
This gets a bit weirder for me. It seems that with the gadget that summaries aren't saved at all, even if I type something manually in the textbox, and this behavior is inconsistent: If I add automatic summaries from the buttons and save, the summary isn't saved. If I add automatic summaries from the buttons and then add a text, they are saved as a summary. If I add a summary by hand, it isn't saved. I'm not sure what would cause this to happen; the gadget fills in automatic text by adding into the textbox.val() which should make this work.
Got it. The issue was a mixup between dealing directly with the textarea object through jQuery (which updates .val()) and dealing with VE's OOUI elements (which update through .setValue() ) I've created a fix to the gadget, but I don't have the permissions to edit it. I've asked Eran to take a look and implement the fix.
Fixed by triggering manually input event. However oojs-ui should use the widget value to get must up to date value (e.g protype.getValue( return this.widget.val(); ), and not to be based on some cached variable. If it does something smart with the value it can be check that if this.value !=this.widget.val() then it should trigger the function for updating this.value, before actually return the widget value.
Created attachment 16237 [details] Fix for oojs-ui Attaching a proposed patch for oojs-ui.
The problem is actually to do with the fact that the browser isn't emitting events when it should. OOjs UI is listening for the change event. Just use: $input.val( newValue ).trigger( 'change' );
@Trevor Parscal, I already fixed it with triggering input event. However it should be fixed in oojs-ui itself for later cases. The browser should not emit event in this case (see RFC: http://www.w3.org/TR/html401/interact/scripts.html#adef-onchange), and even if the spec was the other way - oojs-ui can't blame browsers...
The problem is that we really should be caching the value; it's done to protect the behavior against a lot of event triggering and browser mishaps that otherwise would make interaction with inputs pretty horrible. We can't have ooui deal with the jQuery element directly; if you notice, htere's also a SetTimeout() method inside 'setValue' -- that's on purpose to make sure that if the user types quickly we don't emit crazy amount of events. Changing ooui to deal with the jQuery element's value directly will remove a lot of its intended functionality.
This is onEdit function (with setTimeout) that protect against browsers mishaps if I understand correctly. BTW - don't scar to change getValue, as it is used only in ~35 places in the code ;)
There are actually several reasons for the setTimeout, but the real problem here is that getValue compensating for not noticing the value changed previously causes other issues. The OO.ui.TextInputWidget has a "change" event, which is depended on by other systems. If we just make getValue compensate for not noticing the value changed previously, then systems depending the aggregated change event will behave incorrectly. The best way to handle this is to either trigger the event or come up with a way to access the input. We could, for instance, leave references to widgets in the elements using jQuery.data().
