Last modified: 2014-07-18 12:33:06 UTC
This bug was initially created as a clone of Bug #29200; Brion wrote: Workarounds for failures to handle error conditions in the JavaScript code exist. The error info from the dieUsage appears to perfectly correctly make it back to the 'doneCallback' function in 'handleAJAXSave' (via the actual call in liquidThreads.doNewThread ). However, doneCallback tries to handle error conditions by submitting the same form as non-Ajax in the hopes that that code path will show an error as well, which apparently isn't ending up having the expected results. It should instead probably show the error message directly.....? Does this need more general or more specific handling for particular kinds of errors that we can't report back cleanly through this interface?
for debugging it may help to add dump() (javascript version of PHP print_r ) see http://www.openjs.com/scripts/others/dump_function_php_print_r.php in callback handler of apiRequest function /** * Function : dump() * Arguments: The data - array,hash(associative array),object * The level - OPTIONAL * Returns : The textual representation of the array. * This function was inspired by the print_r function of PHP. * This will accept some data as the argument and return a * text that will be a more readable version of the * array/hash/object that is given. * Docs: http://www.openjs.com/scripts/others/dump_function_php_print_r.php */
Andrew, I need your help to overcome this problem of not having error messages in lqt: the modules do not show error alert messages; they appear to get caugth somewhere else. You can try this for example by intentionally insertings dieUsage() calls. The lqt.js already has a lot of "FIXME" comments related to error handling, so it looks as if something's is broken or otherwise going wrong as indicated by Brion in the first comment.
The way error handling is done at the moment is that if there is an error, it submits the request through the non-Javascript POST mechanism, and any error will be displayed on the result page. It's a quick fix, but it's effective. If you like, you can have the errors show up with JavaScript.
(In reply to comment #3) > The way error handling is done at the moment is that if there is an error, it > submits the request through the non-Javascript POST mechanism, and any error > will be displayed on the result page. It's a quick fix, but it's effective. If > you like, you can have the errors show up with JavaScript. At the moment, no errors are shown for unknown reason when there are some. See Brion's comment ( https://bugzilla.wikimedia.org/show_bug.cgi?id=29390#c0 )
(In reply to comment #4) > At the moment, no errors are shown for unknown reason when there are some. > See Brion's comment ( https://bugzilla.wikimedia.org/show_bug.cgi?id=29390#c0 ) Is that still the case?
Clarification: I found this during debugging LiquidThreads in 2011: I wanted to fix the problem, that the AJAX loading "spinner" is oftern not cleared, for example when you move a Lqt thread. The debugging was difficult, and I stopped when I found that errors are not correctly treated inside Lqt. Honestly, I gave up. The Wikimedia Foundation told me several times, that a professional person is working on LiquidThreads - I asked several times for evidence of some outcome of this project, but their answer was always like cookie-licking "yes we working on that". I gave up with LiquidThreads.
Adding Krenair in case he's interested in fixing this.
