Last modified: 2013-01-14 23:14:20 UTC
https://gerrit.wikimedia.org/r/#/c/17605/ changed jsMessage significantly, by using a new css to make it a small pop-up style window, and making it auto-hide as well. The problem is that this change broke a significant number of widely used scripts, such as [[en:User:Mr.Z-man/closeAFD]]. These script uses the function to display a form for gathering user input. They are therefore dependent on the message being non-autohide, and moreover, many likely assumed that they have more space horizontally than that tiny window. I really can't see why the "new" behavior could not have been implemented in a new function. Please revert this change.
*** This bug has been confirmed by popular vote. ***
Please use don't abuse messages to get user input. Were it worse, we could consider a new method, but in this case it is imho perfectly justified to have changed the existing system for the exact reason that existing scripts should automatically use it. The old system had no advantages in any way. In the particular case of presenting a form to the use, it can be done in a minute by simply using a jQuery .dialog() instead. That will probably look a lot better and be more consistent with native components.
Sorry, but if you provide a function that can display, well, almost everything, people are going to use it to display, well, almost everything. That includes, of course, forms. The legacy jsMsg() function is used by about 146 scripts on enwiki: https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=advanced&search=jsmsg&fulltext=Search&ns2=1&ns8=1&redirs=1&profile=advanced Even assuming that half of those scripts will not properly function with auto-hide, that's quite a number of scripts to be broken on developer fiat. One advantage of the old system is that it will never cover any text on the screen. Someone who is closing an AfD, for instance, will likely want the original text to not be obfuscated by a dialog box.
Fair enough, but there's lots of paths to take. But using jsMessage for it is not one of them imho. If the goal is really to have it be on top of the page (which I imagine can actually be unexpected if one wants to read the original text since one'd have to scroll back and forth when the form is on top of the page) - then simply prepend it to the top of the page (mw.util.$content.prepend()), no need for jsMessage for that. Also when using jsMessage there is another problem. I wonder why that never caused a problem for those 146 scripts (or it has, but nobody cared to fix it). Namely the fact that it the old jsMsg always replaced what was there. So when any other gadget, extension or core script emits a message, the form will vanish without mercy. That'is a bad thing, and one of the many reasons why jsMsg is not at all a good way to display a form for user input. Possibilities: * That the $form, perhaps wrap it (while at it) in a <fieldset> with descriptive <legend>, prepend it to mw.util.$content. * Display it inline * Use jQuery ui .dialog() - either on top of the page, or in place where the page scroll is currently at (even possible to not dim the background, which you don't want if the page should remain visible). * In the sidebar * with jsMessage and autoHide: false * lots of possibilities. Even if we would keep the deprecated jsMsg() as it was, how long would we keep it deprecated? It has already been deprecated for almost 2 years (MediaWiki 1.17). And aside from being deprecated, it was never documented as being a way to put content on top of the page. It is a way to notify the user about interactive state. Although it does work to put something generic on top the page, even for that it was never reliable because it always replaced the previous message. Looking at a few of those 146 scripts on en.wikipedia: * I see about half a dozen scripts that are full of syntax errors and don't even work. Such as: jsMsg(A test message called hopefully by Initiating Edit mode,) > Unexpected identifier at " test" * Many that haven't been updated in 5+ years, and probably never will be updated no matter how many years of deprecation and migration announcements there will be - until they break visibly. * Fortunately the fast majority is actually correct and proper usage: Displaying a brief message to the user. * Many are exact duplicates where users copied a script instead of importing it, so they likely know every little (if anything) about how javascript works and the author of the script may or may not be aware of the fact that users copied it. That is the mess we are dealing with as a result of ~ 7 years of crappy undocumented legacy scripts and there is a point were we started over with many of them. Most of that happened in 2010 with ResourceLoader, jQuery etc. in MediaWiki 1.17 and now with jsMessage. I'm more than willing to help anyone find a good alternative while at the same time making other improvements.
This is a horrible idea.
Yesterday I discussed this a bit on IRC. So one idea that seems pretty good actually is a scenario like this: * Something happens, a notification is send and a follow-up action by the user is recommended. * The user clicks a link or button inside the notification. * A dialog comes up or a new page is loaded, or some other means of interaction. Practical application: Chat. * User makes a call to another user. * Other user gets notification (autoHide: false, has a short message and two buttons: accept / deny) * Deny hides the message, accept takes the call and pops up a dialog with the call or a hovering box on the bottom right, or popup, or whatever. Either way, not inside the notification itself.
As per comment 4, is this realistically speaking a WONTFIX?
Yes.
