Bug 811167 - editarea does not work properly with IE9
editarea does not work properly with IE9
Status: CLOSED CURRENTRELEASE
Product: Fedora EPEL
Classification: Fedora
Component: editarea (Show other bugs)
el6
All Windows
unspecified Severity unspecified
: ---
: ---
Assigned To: Colin Coe
Fedora Extras Quality Assurance
:
Depends On: 811164
Blocks: 810991
  Show dependency treegraph
 
Reported: 2012-04-10 06:21 EDT by Stephen Herr
Modified: 2013-04-07 21:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 811164
Environment:
Last Closed: 2013-04-07 21:32:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to make editarea work well with IE9 (1.37 KB, patch)
2012-04-10 06:21 EDT, Stephen Herr
no flags Details | Diff

  None (edit)
Description Stephen Herr 2012-04-10 06:21:13 EDT
Created attachment 576439 [details]
Patch to make editarea work well with IE9

+++ This bug was initially created as a clone of Bug #811164 +++

Description of problem:
The javascript in the editarea RPM does not play nicely with IE9. Selecting text / moving the cursor is flat out broken and the text looks fuzzy. See http://sourceforge.net/tracker/?func=detail&aid=3081703&group_id=164008&atid=829997

Version-Release number of selected component (if applicable):
All

How reproducible:
Every time.

Steps to Reproduce:
1. Make sure that IE9's "document mode" is set to IE9 standards.
2. Attempt to edit text in an editarea window
  
Actual results:
Cursor always moves to the end of the text, you can't select text, text looks fuzzy.

Expected results:
It works as expected

Additional info:
The problem comes because IE9 actually correctly implements something that no other version of IE has correctly implemented. Editarea has some hack in it to do something like:
if ( usingIE ) {
  do some stupid hack to make it work right
}

and the stupid hack actually breaks IE 9. The following updates should fix the issue:

diff -uNr editarea.old/edit_area/edit_area.css editarea/edit_area/edit_area.css
--- editarea.old/edit_area/edit_area.css        2010-01-14 01:56:34.000000000 -0500
+++ editarea/edit_area/edit_area.css    2012-04-09 17:27:12.995918527 -0400
@@ -143,7 +143,7 @@
 }^M
 ^M
 .hidden{^M
-       opacity: 0.2; ^M
+       opacity: 0; ^M
        filter:alpha(opacity=20);^M
 }^M
 ^M
diff -uNr editarea.old/edit_area/manage_area.js editarea/edit_area/manage_area.js
--- editarea.old/edit_area/manage_area.js       2010-01-14 01:56:34.000000000 -0500
+++ editarea/edit_area/manage_area.js   2012-04-09 17:29:33.775855141 -0400
@@ -200,11 +200,14 @@
                return sel;             ^M
        };^M
        ^M
+       // IE < 9 ^M
+       var need_createRange = !("selectionStart" in document.createElement("textarea"));^M
+       ^M
        // set IE position in Firefox mode (textarea.selectionStart and textarea.selectionEnd)^M
        EditArea.prototype.getIESelection= function(){^M
                var selectionStart, selectionEnd, range, stored_range;^M
                ^M
-               if( !this.isIE )^M
+               if( !this.isIE || !need_createRange )^M
                        return false;^M
                        ^M
                // make it work as nowrap mode (easier for range manipulation with lineHeight)^M
@@ -246,7 +249,7 @@
        EditArea.prototype.setIESelection= function(){^M
                var a = this.textarea, nbLineStart, nbLineEnd, range;^M
                ^M
-               if( !this.isIE )^M
+               if( !this.isIE || !need_createRange )^M
                        return false;^M
                ^M
                nbLineStart     = a.value.substr(0, a.selectionStart).split("\n").length - 1;^M

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