ansaurus

Question

Problem with Google Chrome and Javascript. Guru needed!

Answer 1

A:

Just quickly, can you try adding semicolons to the end of the lines inside your send() function? And see if that works.

function send() {
  resetContent();
  setEditFocus();
}

Albert 2010-08-29 22:57:47

@Albert, thanks for your suggestion, but this dont let it work as well, the semicolons dont have any effect. I invite you to click the link above to see the problem in action using Chrome

Luka 2010-08-29 23:02:27

Answer 2

+1 A:

You know how I solved this one? In resetContent(), replace '' with ' ':

if (myIFrame) myIFrame.contentWindow.document.body.innerHTML=' ';

If it works, good. Don't ask why though, it might be one of those Webkit glitches with Range object, file a bug if you will.

syockit 2010-08-30 02:38:05

@syockit thanks for your tip, look like the "Colombo egg" :) but still have some problem with this suggestion in other browser

Luka 2010-08-30 09:40:45

Answer 3

+2 A:

I'm not really sure what the cause of the issue is, as there are times where Chrome will give focus to the element correctly, though most of the time it does not. You shouldn't need to request focus at all, since the focus is not lost when you press the key. If you omit the setEditFocus() call, you should notice that it still works correctly in everything but Chrome, which apparently gets offended that you've removed all of the content in the body.

When you set contenteditable, every browser sets the innerHTML of the iframe document's body element to be something different:

Browser           | innerHTML
-----------------------------
Internet Explorer | ''
Opera             | '<br>\n'
Firefox           | '<br>'
Chrome/Safari     | '\n'

If you're not expecting to see that extra stuff when you parse the content later, you might want to remove it upfront in addFrame().

I was able to "fix" the problem by doing the following:

First, update the event handler so we can return false in it and prevent Opera from generating HTML for fun when we call getSelection() later...

function addFrame() {
    ...
    window.iframeloaded = function() {
       ...
       if (typeof iframeDoc.addEventListener != UNDEF) {
           iframeDoc.addEventListener('keypress', keyHandler, false);
       } else if (typeof iframeDoc.attachEvent != UNDEF) {
           iframeDoc.attachEvent('onkeypress', keyHandler);
       }
    }
}

Edit: Removed original function in favour of the new one included below

Finally, return false from the key press handler to fix the Opera issue mentioned above.

function keyHandler (evt) {
    var myKey=(evt.which || evt.charCode || evt.keyCode)

    if (myKey==13) {
        ...
        return false;
    }
}

I had originally done what syockit suggested, but I found it was doing weird things with the caret size in Chrome, which this method seems to avoid (although Firefox is still a bit off...). If you don't care about that, setting the innerHTML to be non-blank is likely an easier solution.

Also note that you should be using className instead of class in the object you pass to new Element(), since IE seems to consider it a reserved word and says that it's a syntax error.

Edit: After playing around with it, the following function seems to work reliably in IE8/Firefox/Chrome/Safari/Opera for your more advanced test case. Unfortunately, I did have to include Prototype's browser detection to account for Opera, since while everything looks the same as far as the JavaScript is concerned, the actual behaviour requires different code that conflicts with the other browsers, and I wasn't able to find a better way to differentiate between them.

Here's the new function, which focuses on the editable content of the iframe, and makes sure that if there is already content in there, that the caret is moved to the end of that content:

function focusEditableFrame(frame) {
    if (!frame)
        return;

    if (frame.contentWindow)
        frame = frame.contentWindow;

    if (!Prototype.Browser.Opera) {
        frame.focus();

        if (frame.getSelection) {
            if (frame.document.body.innerHTML == '')
                frame.getSelection().extend(frame.document.body, 0);
            else
                frame.getSelection().collapseToEnd();
        } else if (frame.document.body.createTextRange) {
            var range = frame.document.body.createTextRange();

            range.moveEnd('character', frame.document.body.innerHTML.length);
            range.collapse(false);
            range.select();
        }
    } else {
        frame.document.body.blur();
        frame.document.body.focus();
    }
}

Updated setEditFocus() (Not really necessary now, but since you already have it):

function setEditFocus()
{
    focusEditableFrame($(editorFrame));
}

Tim Stone 2010-08-30 03:54:11

@Tim, oh you are a real GURU and the explanation is so clear! As the last time u help me a lot and ur suggestions fix the problem in CHROME! IN real the code that i post is extrapolated from my source that is bigger because the chat can be closed, re-open and more so ur fix work well but i need to give the focus in same cases and in FF, IE so i need to add a condition in the `function setEditFocus`. So i added a condition as `if(Prototype.Browser.Gecko || Prototype.Browser.IE || Prototype.Browser.Opera) {ifWin.focus();} else {... your code}` Opera dont work as well btw :( Suggestions?

Luka 2010-08-30 09:53:42

@Luka - I tested the code that I posted in Firefox, IE, Opera, and Chrome (and Safari, just 'cause), so you shouldn't need to add the condition, because it works as I've written it in all of them. Is it not working when you add it to the rest of your code, or?

Tim Stone 2010-08-30 10:07:59

@Tim, ops i let you work a lot :) but you are so good!! I created a new example where you can see your code in action, go here `http://under.bestqm.com/test/iframe2.asp` and try to press the buttons in sequence, you will see that the focus dont work in FF (button 2). Btw when press enter (as first problem) it work fine (both in Chrome and FF) as i desired and thanks to your code. The problem in this case is that i need give the focus in many cases to the IFRAME as the example using the button 2.

Luka 2010-08-30 11:23:48

@Luka - Ah, I see. I'll work on a more generalized solution later that should hopefully take care of that.

Tim Stone 2010-08-30 13:28:32

@Tim Great work! work fine with all browsers! Excellent solution.

Luka 2010-10-11 15:18:45

ansaurus

tags:

views:

answers:

Problem with Google Chrome and Javascript. Guru needed!

related questions