Last modified: 2014-04-08 08:57:01 UTC
When we do a search and replace and there are several replacements made, the edit box changes at each replacement, making the script very slow. Besides this, if we want to undo the replacement, then we need to press CTRL+Z lots and lots of times until we get to the wikitext we had before.
The replacements should be done in a copy of the content of edit page and be copied back only after the replacements are made, in only one step.
Any updates on this?
The search and replace is still very slow. For example, replacing all occurrences of "* " by "*" takes more than 20 seconds using the dialog from enhanced toolbar.
The very same substitution made by an script like Pathoschild's Regex menu framework is instantaneous
Could anybody fix the problem, please?
I should look into this some time.
The issue here is that replacing everything at once is sure to be faster in Gecko and Webkit, but I think individual replaces may be faster in IE.
Is the issue about the "Replace all" command? If you find/replace one at a time, doing one at a time seems about right and should be the correct thing to do.
On my Linux desktop (FF 4.0, i5 something orother) it took about 8 seconds to search-replace all instances of 'Illinois' on [[Obama]]; definitely longer than I like without any progress feedback.
It looks like currently in trunk, the replace all mode does a fairly quick match, but then runs through encapsulateSelection logic for each individual replacement.
I guess the main alternative to that would be to perform the replacements in a single regex on the source text, then drop that source text back into the editor. This is probably ok for the plain textarea, but could involve reparsing of iframe or CodeEditor stuff, which might itself be slow or fast.
It also looks like each individual replacement is doing things like changing the scrolling, so that might be contributing to the time spent in each replacement.
(In reply to comment #4)
> Is the issue about the "Replace all" command? If you find/replace one at a
> time, doing one at a time seems about right and should be the correct thing to
Yep. I mean "Replace all".
> On my Linux desktop (FF 4.0, i5 something orother) it took about 8 seconds to
> search-replace all instances of 'Illinois' on [[Obama]]; definitely longer than
> I like without any progress feedback.
If I do the same using Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:184.108.40.206) Gecko/20110430 Iceweasel/3.5.16 (like Firefox/3.5.16), all I get is the following warning after something like 15 seconds (and then again after other 15):
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete
This report has been in ASSIGNED status for more than one year and you are set as its assignee. In case that you are not actively working on a fix, please reset the bug status to NEW/UNCONFIRMED.
In case you do not plan to work on a fix in the near future: Please also edit the "Assigned To" field by clicking "Reset Assignee to default", in order to not prevent potential contributors from working on a fix. Thanks for your help!
Unsetting as ASSIGNED as on-one has not looked at this in three years, and it's just cookie-licking.
Quim Gil, do you think this a good candidate for GCI?
Thank you for proposing GCI tasks!
I'm unable to assess the complexity of this task, though. Would it take 2-3 hours to someone like Trevor or Roan? This is our pragmatic way to measure the appropriateness of GCI tasks.
I am a newbie to media wiki and this is would be my first contribution. Could someone please assign this bug to me and help me out?
RituS: Please see https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker - if you have *specific* questions that only refer to the topic of this bug report feel free to ask them here; for general questions on development tools etc. please use one of the resources linked on that wikipage (e.g. IRC, wikipages or mailing lists). Thanks!
Hi RituS, thank you for your interest in contributing to Wikimedia. I'm not sure about the complexity of this but, but if you are looking for a first contribution you might want to start with a bug marked explicitly as EASY.
See https://www.mediawiki.org/wiki/Annoying_little_bugs tom find easy bugs, and https://www.mediawiki.org/wiki/Starter_kit for general information for new contributors.
Hey Quim Gil
I got this particular bug from the given list of annoying little bugs. That is why I went ahead with the bug though I did find understanding it tough. I think I should jump to a easier one then.
(In reply to comment #13)
> Hey Quim Gil
> I got this particular bug from the given list of annoying little bugs.
Ooops, sorry! Then someone able to assess this report should either mark it as EASY or remove it from https://www.mediawiki.org/wiki/Annoying_little_bugs
Hey Quim Gil
Well that's disappointing. But anyhow thanks for letting me know!
*** Bug 61118 has been marked as a duplicate of this bug. ***