Page MenuHomePhabricator

"Search and replace" for IE does not correctly replace words but changes others
Closed, DuplicatePublic

Description

using the search and replace toolbar button in IE is broken.

REPLICATION

  • fire up IE
  • open https://en.wikipedia.org/wiki/Software_bug?action=edit
  • open "Advance" toolbar
  • press the "search and replace" button
  • enter "bug" for "search" and "bug" for "replace" (without the quotes)
  • press "replace all"
  • after the replace is complete, press "Show Changes"

WHAT YOU EXPECT

nothing should change

WHAT YOU SEE

the page gets trashed.

problem exists when running legit replaces also, but replacing a string with itself makes it the most obvious.

peace.


Version: unspecified
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65732

Details

Reference
bz42073

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:02 AM
bzimport set Reference to bz42073.
bzimport added a subscriber: Unknown Object (MLST).

(In reply to comment #0)

the page gets trashed.

not "bug" is replaced with "bug", but the three letters before each "bug" are changed, and at the very beginning "bug" is inserted.

Please mention the exact version of IE, and whether you have "compatibility mode" enabled or not. Bug 24194 might be related.

did you try it?

for me it happens on IE 8 and 9, both with and without compatibility mode.

peace.

(In reply to comment #3)

did you try it?

I couldn't as I'd need a machine that IE runs on & there's no IE for Linux.

Thanks for sharing the IE versions here!

i may be a complete dunce, but i can't understand this piece of code (could not find it in the repo - where is WikiEditor in the repo anyway? i had to cut it from the browser's debugger):

BIZARRE CODE BEGIN

						} else if ( mode == 'replaceAll' ) {
							// Instead of using repetitive .match() calls, we use one .match() call with /g
							// and indexOf() followed by substr() to find the offsets. This is actually
							// faster because our indexOf+substr loop is faster than a match loop, and the
							// /g match is so ridiculously fast that it's negligible.
							// FIXME: Repetitively calling encapsulateSelection() is probably the best strategy
							// in Firefox/Webkit, but in IE replacing the entire content once is better.
							for ( i = 0; i < match.length; i++ ) {
								index = textRemainder.indexOf( match[i] );
								if ( index === -1 ) {
									// This shouldn't happen
									break;
								}
								var matchedText = textRemainder.substr( index, match[i].length );
								textRemainder = textRemainder.substr( index + match[i].length );

								start = index + offset;
								end = start + match[i].length;
								// Make regex placeholder substitution ($1) work
								var replace = isRegex ? matchedText.replace( regex, replaceStr ) : replaceStr;
								var newEnd = start + replace.length;
								$textarea
									.textSelection( 'setSelection', { 'start': start, 'end': end } )
									.textSelection( 'encapsulateSelection', {
											'peri': replace,
											'replace': true } )
									.textSelection( 'setSelection', { 'start': start, 'end': newEnd } );
								offset = newEnd;
							}
							$( '#wikieditor-toolbar-replace-success' )
								.text( mw.msg( 'wikieditor-toolbar-tool-replace-success', match.length ) )
								.show();
							$(this).data( 'offset', 0 );
						} else {
BIZARRE CODE END

this looks very strange. for the "ReplaceAll", all you have to do is
$textarea.val($textarea.val().replace(regex));
$( '#wikieditor-toolbar-replace-success' )

								.text( mw.msg( 'wikieditor-toolbar-tool-replace-success', match.length ) )
								.show();

using the "textSelection" tool for repetitive replacement, where in reality there *is* no selection, and the code iterate through loop of setting the selection and then using the selection tool with "replace" looks very perverted.

completely unrelated to this bug, but since i am here anyway: the most glaring omission of the "text and replace" tool is the ability to limit the "replace all" to current selection.

(i hate it that bugzilla does not have a "preview" feature).

peace.

(In reply to comment #5)

omission of the "text and replace" tool is the ability to limit the "replace

s/"text and replace"/"search and replace"/

(i hate it that bugzilla does not have a "preview" feature).

peace.

(In reply to comment #5)

$textarea.val($textarea.val().replace(regex));

it seems that whoever wrote it chose to limit the interaction with $textarea to textSelection, but all it means is that this should be

$textara.textSelection( 'setContent', $textara.textSelection( 'getContent' ).replace( regex ));

or simply
$textara.textSelection( 'setContent', textRemainder.replace( regex ));

peace.

my little snippet does not take isRegex into account.
it should really be:

$textarea.val($textarea.val().replace(regex,
function(matchStr) { return isRegex ? matchedStr.replace( regex, replaceStr ) : replaceStr; } ));

peace.

(In reply to comment #6)

(i hate it that bugzilla does not have a "preview" feature).

File your upstream request in bugzilla.mozilla.org, and paste longer code in attachments... Thanks.

(In reply to comment #9)

(In reply to comment #6)

(i hate it that bugzilla does not have a "preview" feature).

File your upstream request in bugzilla.mozilla.org,

ahhh.... one of the oldest in the book:
https://bugzilla.mozilla.org/show_bug.cgi?id=40896
(circa 2000).

... and paste longer code in attachments... Thanks.

will do.

peace.

verified that problem still exists on wmf5.

peace.

  • Bug 23591 has been marked as a duplicate of this bug. ***
  • Bug 22878 has been marked as a duplicate of this bug. ***

dawpa2000 wrote:

See:

Bug 23992 - Search&replace disabled in IE8, Opera:
https://bugzilla.wikimedia.org/show_bug.cgi?id=23992

Bug 48305 - 1.22wmf3, "Search and replace" capability not working in IE/Opera:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48305

Is this still an issue in 2015? If so, which IE versions are (not) affected?