Last modified: 2014-09-09 17:29:43 UTC
see https://secure.wikimedia.org/wikipedia/commons/wiki/Commons:Village_pump#Typing_long_descriptions_using_the_wizard_locks_up_my_browser https://secure.wikimedia.org/wikipedia/commons/w/index.php?title=Commons:Village_pump&oldid=65142142#Typing_long_descriptions_using_the_wizard_locks_up_my_browser I will report more details ASAP
Basically: there appears to be a problem in the upload wizard. When typing in descriptions, reaching a limit of about 1 to 2kB the browser "freezes" as JS goes into a tight loop. If you need any additional details, please email me: maury.markowitz@gmail.com
(In reply to comment #0) > see > https://secure.wikimedia.org/wikipedia/commons/wiki/Commons:Village_pump#Typing_long_descriptions_using_the_wizard_locks_up_my_browser > > https://secure.wikimedia.org/wikipedia/commons/w/index.php?title=Commons:Village_pump&oldid=65142142#Typing_long_descriptions_using_the_wizard_locks_up_my_browser > > I will report more details ASAP The short Village Pump thread is archived here: https://secure.wikimedia.org/wikipedia/commons/wiki/Commons:Village_pump/Archive/2012/01#Typing_long_descriptions_using_the_wizard_locks_up_my_browser Not much more details though.
In Safari 5.1.2 on OS X 10.6.8, I tried descriptions of size 512 bytes, 1024 bytes, and 2048 bytes. I did several other things which trigger JavaScript rescanning of the text field, such as trying to submit without a description. I could not reproduce this bug. Maury Markowitz: what version of Safari / OS ? Is this is still reproducible? Do you use any browser add-ons or gadgets that might be contributing?
Yes, the bug is 100% reproducible. It just happened to me yesterday while uploading pictures of the Port Perry railway. OSX 10.7.2 Safari 5.1.2 AdBlocker add-in, but removing it does nothing. Are you *typing* into the wizard, or cut-n-pasting?
I've typed the majority of a page in Firefox on the same machine without a problem.
(In reply to comment #4) > Yes, the bug is 100% reproducible. It just happened to me yesterday while > uploading pictures of the Port Perry railway. > > OSX 10.7.2 > Safari 5.1.2 > > AdBlocker add-in, but removing it does nothing. > > Are you *typing* into the wizard, or cut-n-pasting? Okay, I just typed in 2000 characters of "All's well that ends well", on Safari 5.1.2 (same as yours) on OS X 10.6.8 (unsure if this makes a difference), and I see no issues. Then I tried doing a submission with a blank description (to trigger the length checker in the validator, which I suspected might be the issues) and typed 1000 characters, and still saw no issue. Then I did all this all over again on OS X 10.7.2, just to be really sure. I believe that you're seeing something, but at this point I'm pretty sure that I've eliminated our software as the source of the problem. Perhaps you should just use a different browser.
How do I attach a photo? It just died again, but I got a screen snap. All my work gone, AGAIN.
Created attachment 9906 [details] screenshot showing frozen page screenshot that maury markowitz mailed to me
Please do not use my personal email to contact me about this bug. It's better for everyone if we communicate in public. As it happens, I'm leaving my job at the WMF in a few days anyway, so all these bugs will be turned over to other people. I note from your screenshot that you are using Monobook. That's an example of a possibly relevant difference in your configuration, that I was asking you about. Are you sure you haven't forgotten about any other gadgets or customizations that would help us diagnose this? Anyway, I tried it in Monobook on Safari, and I still can't reproduce your problem.
I would love nothing more than to upload the image in question directly to this page. However, I can't figure out how to do it. I still have 100% repeatability. Thus I have re-opened the thread. If it works for you, please hand it to someone else to take a look at.
(In reply to comment #10) > I would love nothing more than to upload the image in question directly to this > page. However, I can't figure out how to do it. Use this link to get a form that will allow you upgrade a screenshot as an attachment to this bug: https://bugzilla.wikimedia.org/attachment.cgi?bugid=33607&action=enter > I still have 100% repeatability. Thus I have re-opened the thread. If it works > for you, please hand it to someone else to take a look at. Neil was probably your best bet to get this fixed.
I want to note, I have reproduced this bug, just by typing a lot of characters into the description box. I'm not sure exactly what's causing the problems, though--at first I thought it might be a large number of onchange callbacks, all of them checking increasing numbers of characters, eating up a lot of memory. But even a few hundred such callbacks, with roughly 1000 characters each, would only have some 300 KB in use. There must be some reason that jQuery's validation method is not optimal for this situation, so I will look into a modification that might fix it after lunch.
Sadly, after I ate, the bug no longer appeared. My current best suggested fix is delicious tacos, but other than that it appears to be a heisenbug, only appearing when you aren't looking at it. If anyone can get it to happen reliably, it would be awesome if you could post details here. Thanks! Note to future bug-wranglers: My suspicions point me towards the line in mw.UploadWizard.js where growTextArea is being defined....about halfway through that function, at the end of the inline function resizeIfNeeded, there is a return statement. I would guess that it doesn't need to be there, and that passing around huge amounts of data to nowhere in particular on *every keyup event* is probably not a great idea, and could predictably cause problems. If someone else can reproduce this bug consistently, it would be good to test this theory on them.
I made a change as per suggestion in previous comment, not sure if it fixes this bug https://gerrit.wikimedia.org/r/#/c/53978/
Although I can't reproduce this bug, I merged the change (it makes sense to me based on comment 13 and I couldn't find any breakage). Can we set the latest copy of master up somewhere to ask Maury to test it?
Won't it be on test.wp in the next deployment?
Has anyone been able to reproduce this since ?
Rainer: Is this still an issue?
(In reply to comment #18) Suggest asking those who are using UpWiz with Safari. If you want me to hack a notice into UpWiz at Commons "Did you experience any browser crashes while using Upload Wizard?" when the UA-sting indicates Safari, I can do so. (But I doubt you want :) ) Didn't see anyone reporting this recently.
I've had the same symptoms using Crome recently when I add text above a certain length to the description field while using the upload wizard. I'm assuming this relates to the same bug. The page is here: https://commons.wikimedia.org/wiki/Special:UploadWizard When I got to the "describe" section I extended the box for my description, typed away including various line breaks, external links etc. and then it got to a stage when it froze. Simple work around is just to save without a description and then edit it later, but this is annoying, wastes contributors' time and could put them off altogether. If someone could fix this it would be helpful. Thanks
Closing as nobody can reproduce the problem anymore. Assuming comment 14 fixed this. AndrewRT: A separate bug report with exact steps to reproduce is welcome, if this still happens.
Change 148222 had a related patch set uploaded by MarkTraceur: Don't check description validity on keyup https://gerrit.wikimedia.org/r/148222
Is this code patch in production? It just locked up again two days ago. I can take a movie if anyone thinks that will help?
No, it's literally just been uploaded to Gerrit, minutes before you said that.
Ok excellent, fingers crossed!
I'm honestly not sure if the patch will help anything, but I'll say here when it gets out to Commons and we'll see if y'all can reproduce.
Change 148222 merged by jenkins-bot: Don't check description validity on keyup https://gerrit.wikimedia.org/r/148222
There are a few more reports of similar problems, so I guess this never got fixed. I still haven't been able to reproduce the issue, though. See bug 68807 and bug 54994 for similar problems.
Change 152824 had a related patch set uploaded by MarkTraceur: Remove growTextArea https://gerrit.wikimedia.org/r/152824
Change 152830 had a related patch set uploaded by Rillke: Fix unresponsive browser on auto-growing input https://gerrit.wikimedia.org/r/152830
Change 152830 merged by jenkins-bot: Fix unresponsive browser on auto-growing input https://gerrit.wikimedia.org/r/152830
Change 152824 abandoned by MarkTraceur: Check for CSS height in growTextArea Reason: I8e46af40f28baf7002fe35586ea5efdd8a7544a7 is more better. https://gerrit.wikimedia.org/r/152824
We *think* this fixed it. If you continue to experience issues with browsers crashing, please reopen!
