Last modified: 2013-05-24 14:47:19 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 48305 - 1.22wmf3, "Search and replace" capability not working in IE/Opera
1.22wmf3, "Search and replace" capability not working in IE/Opera
Status: RESOLVED DUPLICATE of bug 23992
Product: MediaWiki extensions
Classification: Unclassified
WikiEditor (Other open bugs)
master
All All
: High major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-09 19:18 UTC by kipod
Modified: 2013-05-24 14:47 UTC (History)
6 users (show)

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


Attachments

Description kipod 2013-05-09 19:18:39 UTC
Using IE-9 or IE-10, 1.22wmf3 lost the "search and replace" functionality.

Reproduction:

0) find machine with IE-9 or IE-10, and use it
1) Open 1.22wmf3 wiki, e.g. enwiki, hewiki or mw (did not test with other wikis)
2) open random page for editing
3) in editor toolbar, open "advance" tab.
4) click on "search and replace" button

Expected result:
   Search and replace form should open

Actual result:
   nada



peace.
Comment 1 Sam Reed (reedy) 2013-05-09 19:21:37 UTC
Any javascript or similar errors?
Comment 2 kipod 2013-05-09 19:25:20 UTC
you should know me by now ;) ... if there were any errors i would have put it in original report.

this is so easy to repro that you don't really need any help - surely *someone* there has access to a box that can run IE, no?

peace.
Comment 3 Andre Klapper 2013-05-10 02:26:48 UTC
CC'ing Krinkle: Could you take a look at this?


Confirming for Windows XP, IE 7, 800x600px, https://en.wikipedia.org/w/index.php?title=Louisiana_State_Archive_and_Research_Library&action=edit on browserstack.com, not being logged in.
Same problem for Opera 12.14, not being logged in.

Works correctly in Google Chrome 24 (not logged in) and Firefox 18 (logged in).

kipod: Just because it's easy to repro for you doesn't mean it's for everybody else.
Comment 4 Andre Klapper 2013-05-10 02:32:49 UTC
I might have jumped the gun here. No indicators that this is a regression; bug 23992 is the same and has been open for a while.

*** This bug has been marked as a duplicate of bug 23992 ***
Comment 5 kipod 2013-05-10 17:47:35 UTC
this is absolutely a regression. text and replace sort-of worked in 1.21, and probably on 1.22wmf2 (i do not use IE regularly - only fire it up to verify users' bug reports). 

it "sort of" worked because of bug 42073 - "replace all" trashed the content. "find" and regula "replace" (i.e., not "replace all") still worked, ttbomk.
now, the search and replace dialog just does not open at all.

if this "disable" is intentional, then it was done wrong: you don't disable something by leaving dysfunctional button on the toolbar - if this is an intentional disable, please remove the button also.

peace.
Comment 6 kipod 2013-05-10 17:48:18 UTC
(In reply to comment #5)
> this is absolutely a regression. text and replace sort-of worked in 1.21, and
s/text and replace/search and replace/

peace.
Comment 7 XP1 2013-05-17 06:29:38 UTC
Did anyone else take a look at "jquery.textSelection.js"? Like I said on 2012-02-07, the bug is on line 65:

    getContents: function () {
        return this.val();
    },

https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=resources/jquery/jquery.textSelection.js#l65
Comment 8 XP1 2013-05-17 09:04:10 UTC
In "jquery.textSelection.js", there are a few bugs with handling newlines.

For Opera, the only change required is to the `getContents` function.

There are more bugs regarding Internet Explorer. The if statements in "jquery.textSelection.js" should be reversed. You want to check for W3C way first and then fallback to Internet Explorer way.

Furthermore, the newline strings should not be hardcoded. This causes problems when the browser has a different newline than what was expected, which results in off-by-one errors.

Experiment with the following example:

    function getNewline() {
       var document = window.document;
       var textarea = document.createElement("textarea");
       textarea.value = "\n";
       return textarea.value;
    }

    var newline = getNewline();

Running in IE8 mode and Opera 11.50, 11.60:

>> newline.length
2
>> newline === "\r\n"
true
>> newline === "\n"
false

Running in IE9 mode and Opera 11.64:

>> newline.length
1
>> newline === "\r\n"
false
>> newline === "\n"
true
Comment 9 XP1 2013-05-17 09:12:48 UTC
@kipod said:
> the search and replace dialog just does not open at all.

That is because the `$.wikiEditor.modules.dialogs.config.getDefaultConfig().dialogs["search-and-replace"].browsers` properties were set to `false` for "opera" and "msie". Browser sniffing is lousy and terrible. You would have to override the default config to get the dialog to show.

I have updated my user JS for Opera that disables the browser sniffing, so the dialog should show.

Fix MediaWiki:
https://gist.github.com/XP1/1712432/
Comment 10 Andre Klapper 2013-05-24 14:47:19 UTC
Please comment on bug 23992 instead. This report is closed as a duplicate.

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


Navigation
Links