Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IE not synchronizing scroll from input ScrollLeft to Highlight Area in INPUT tags #35

Open
alfadormx opened this issue Dec 4, 2014 · 5 comments

Comments

@alfadormx
Copy link

Hi,

My code is as follows. As simple as this:

(function($) {
  $(document).ready(function() {
    $("#e5")
     .highlightTextarea({
        caseSensitive: false,
        words: ['test']
   });
  });
}(jQuery));
<input id="e5" size="50" value="This is a test and i like it of course because this test is great!"></input>

The outcome is like this:
screenshot_1

Then if I move to the right of my input, the highlighter component is expected to move as well but it doesn't.
screenshot_2

The inner left css is always 0 for the hightlighter div. Debugging the code I have found that in IE only the function Highlighter.prototype.updateSizePosition in the following section:

        this.$highlighter.css({
            'width': width,
            'height': this.$el.height() + this.$el.scrollTop(),
            'top': -this.$el.scrollTop(),
            'left': -this.$el.scrollLeft()
        });

uses the sentence this.$el.scrollLeft(). This is ALWAYS 0. I haven't found anything on the internet about this issue with IE. Could you please help out?

By te way, I am using jquery-2.1.1.js and I changed the css for the highlighted test as part of my debug to find out the problem. I just removed the color:transparent sentence from .highlightTextarea .highlighter.

@mistic100
Copy link
Contributor

I'm didn't write this part of the code, see if @rinogo has an idea

@alfadormx
Copy link
Author

Hi,

Further research seems to reveal that JQuery's scrollLeft and scrollTop functions fallback into JavaScripts element.scrollLeft function when you don't send a value as parameter.

Having said this and following my previous example doing:

document.getElementById('e5').scrollLeft;
// and
document.getElementById('e5').scrollLeft = 50;

In a Chrome + Firefox console it will move the Input window as expected.
The same behavior is not supported by IE. The return value is always 0 and when set you don't see any change in scroll.

There must be another way to calculate the 'scroll' position of an input in IE.

Any help by the community is greatly appreciated.

@rinogo
Copy link
Contributor

rinogo commented Dec 5, 2014

Hello! Unfortunately, I can't dive in right now and find a workaround. For my particular application, supporting IE wasn't a top priority, given that this code was to be used on essentially an intranet site. By the way, have you tried other versions of IE? You might find a version for which it works (I believe I did do some IE testing), and either 1) only support from that version on or 2) at least know where to start looking for alternatives (based on the version, changelogs, etc.).

Sorry I can't be of more assistance!

@rinogo
Copy link
Contributor

rinogo commented Dec 5, 2014

By the way, I looked into it a bit more - you should check out my merge request (#22), particularly the last few comments about IE8/IE9 compatibility.

@alfadormx
Copy link
Author

Hi, thanks for your answers.
Well, for the time being I have discovered that the scrollLeft property for inputs works in IE<9.

On the other hand. I have found a workaround to solve my problem.

What I do is actually use a textarea but I make it appear as an Input with the following inline styles:

<textarea id="demo1" cols="50" rows="1" style="white-space: nowrap; overflow: hidden;">Lorem ipsum dolor sit amet, vulputate molestie nec dui.</textarea>

then with a javascript code as follows:

$(document).ready(function() {
  $('#demo1').highlightTextarea({
    words: {
      color: '#FF0000',
      words: ['Lorem ipsum','vulputate']
    }
  });
});

I manage to get the following result (screenshot from IE11)

capture

I will continue my efforts to prove if there is no other solution. Otherwise I will remain with the one previously introduced.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants