Last modified: 2014-04-08 08:57:01 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 23510 - "Replace all" is very slow: WikiEditor should do a one-step replace when replacing all occurrences
"Replace all" is very slow: WikiEditor should do a one-step replace when repl...
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
WikiEditor (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: RituS
https://gerrit.wikimedia.org/r/gitweb...
: javascript, performance
: 61118 (view as bug list)
Depends on:
Blocks: 63665 24493
  Show dependency treegraph
 
Reported: 2010-05-13 18:21 UTC by Helder
Modified: 2014-04-08 08:57 UTC (History)
13 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Helder 2010-05-13 18:21:04 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.

Helder
Comment 1 Helder 2010-08-31 15:51:18 UTC
Any updates on this?

The search and replace is still very slow. For example, replacing all occurrences of "* " by "*"[1] 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[2] is instantaneous

Could anybody fix the problem, please? 

[1] http://en.wikipedia.org/w/index.php?diff=382088466&oldid=382087927
[2] http://meta.wikimedia.org/w/index.php?title=User:Pathoschild/Scripts/Regex_menu_framework.js
Comment 2 Roan Kattouw 2010-09-12 15:28:13 UTC
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.
Comment 3 Helder 2011-06-16 18:44:13 UTC
Any updates?
Comment 4 Brion Vibber 2011-06-16 21:46:44 UTC
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.
Comment 5 Helder 2011-06-16 22:35:40 UTC
(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
> do.

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:1.9.1.16) 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

Script:
http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%7Cmediawiki&only=scripts&skin=vector&version=20110509T132640Z:1
==============================================================================
Comment 6 Andre Klapper 2013-01-09 13:27:25 UTC
Trevor:
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!
[assigned>=1y]
Comment 7 James Forrester 2013-11-04 17:18:44 UTC
Unsetting as ASSIGNED as on-one has not looked at this in three years, and it's just cookie-licking.
Comment 8 Helder 2013-12-26 11:47:57 UTC
Quim Gil, do you think this a good candidate for GCI?
Comment 9 Quim Gil 2013-12-27 06:11:18 UTC
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.
Comment 10 RituS 2014-01-15 13:46:53 UTC
Hey
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?
Comment 11 Andre Klapper 2014-01-15 14:30:48 UTC
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!
Comment 12 Quim Gil 2014-01-15 16:32:56 UTC
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.
Comment 13 RituS 2014-01-16 13:09:01 UTC
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.
Thanks!
Comment 14 Quim Gil 2014-01-16 17:03:24 UTC
(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
Comment 15 RituS 2014-01-18 14:28:46 UTC
Hey Quim Gil
Well that's disappointing. But anyhow thanks for letting me know!
Comment 16 Kunal Mehta (Legoktm) 2014-02-09 21:59:55 UTC
*** Bug 61118 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links