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

neilk wrote:

(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.

neilk wrote:

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.

neilk wrote:

(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.

neilk wrote:

screenshot showing frozen page

screenshot that maury markowitz mailed to me

Attached:

neilk wrote:

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.

andrewrturvey wrote:

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!