Thank you for reporting this bug. We will make it our priority to review this report.
  1. #1
    Ext User
    Join Date
    Jul 2010
    Posts
    4
    Vote Rating
    0
    jimshell is on a distinguished road

      0  

    Default [DUPE-1096] Strange behaviour of the HtmlEditor in Google Chrome...

    [DUPE-1096] Strange behaviour of the HtmlEditor in Google Chrome...


    Hi there,

    I'm new to Sencha/ExtJS, and to this forums as well, so I hope I launched this thread in the right place - a little research let me see that this issue hasn't been reported/addressed so far...

    First, here is my testing environment:
    ExtJS version: 3.2.1 (downloaded today)
    OS: Windows Vista 32bits
    Main browser: Google Chrome (5.0.375.99)
    Other browsers (pretty old ones): IE7, Firefox 2.0.0.20

    Now here is the issue I encounter in Chrome only, experienced on the forms example page "dynamic.html" (both remotely and locally):

    the html RTE editor works fine for everything in Chrome, except when you want to use lists (ordered or unordered ones): when you select a few lines and activate a list, it works a treat, clean display, clean code. But when you want to use a list in the flow of your writing (say: you initiate a list, then begin to type the text for point 1.) it doesn't work as expected in terms of user experience in text editors:

    indeed, when you type Enter, the cursor just goes to the next line, and this has no end as you keep on staying in the same point of the list (no real new line, just carriage returns). Thus, you can't easily get out of the list logic unless you inactivate it, type your points as paragraphers, then select them all to re-generate a clean list (whatever ordered or unordered).

    Don't know if anyone has alreadt experienced this with Chrome, or can confirm the bug. Please post here if you have confirmations to this behaviour.

    Everything works fine with both my IE and my Firefox (though ancient): when you type Enter, you get to the next point, and if you just want to have a carret instead of a new point, you just do Shift+Enter and you're there.

    So, I think there might be a problem with the way Chrome (and other Webkit browsers?) are handled to this regard.

    I decided to have a look at the code and run some tests: switched to "ext-all-debug.js" into my local "dynamic.html" file, then found that the following piece of code seemed to work (in Chrome at least).


    Code:
        fixKeys : function(){ 
            if(Ext.isIE){
               [...]
            }else if(Ext.isOpera){
               [...]
            }else if(Ext.isWebKit){
    		//Changed to fix the Chrome issue with lists
    		return function(e){
                    var k = e.getKey(),
                        doc = this.getDoc(),
                            r;
                    if(k == e.TAB){
                        e.stopEvent();
                        this.execCmd('InsertText','\t');
                        this.deferFocus();
    		   //fix starts here
                    }else if(k == e.ENTER){
    			r = doc.getSelection();
    			if(r){
    				var target = r.anchorNode.parentNode.nodeName.toLowerCase();
    				if(target == 'li'){
    					//it seems this condition is necessary, whatever it contains, even nothing
    					// - so the following line may be useless:
    					this.deferFocus();
    				}else if(target != 'ol' && target != 'ul'){
    					e.stopEvent();
    					this.execCmd('InsertHtml','<br /><br />' );
    					this.deferFocus();
    				} else {
    					//below is an attempt to remove the unwanted "div" tags that 
    					//Chrome automatically puts at the end - didn't found why
    					// I couldn't keep nor assign the focus after that... 
    					//But in the Source Edit panel, the code is clean after this 
    					//(just like in IE or Firefox)
    					Ext.EventManager.on(doc, 'keyup', function () {var target = doc.getElementsByTagName('div')[0]; target.parentNode.replaceChild(document.createElement('br'),target);}, this);	
    				}
                        }
    		}
                 };
            }
        }(),

    Sorry for the formatting (if not legible, I can upload the modified "ext-all-debug.js" file somewhere for whomever wants to test it.

    As you can see by comparing to the original file, I just added a few lines to handle the Enter key for Webkit browsers, which wasn't done previously (not sure as I can't run tests with other Webkits browsers, but this can be narrowed to Chrome easly, using Ext.isChrome instead of Ext.isWebkit, and adding a few conditions earlier in the code).

    I'm not satisfied with this *hack* because:
    - well, I'm very new to ExtJS, so I've clearly not got all the meaning of everything
    - Chrome automatically adds 'div' tags around the ending 'br' tags, which needs to be removed afterwards
    - doing this, the focus is lost (which, to me, is far less a hassle than having to cancel my list and create them again afterwards, anyway, but...)

    I hope that some people here will have the chance to have a look at this and give their opinion and advice, because I'm about to develop an application based on ExtJS and I need the RTE functionalities to be absolutely perfect (because real internet noobs will have to use it).

    Many thanks in advance for your feedback! :-)

    Jimshell

  2. #2
    Sencha - Sencha Touch Dev Team Jamie Avins's Avatar
    Join Date
    Mar 2007
    Location
    Redwood City, California
    Posts
    3,661
    Vote Rating
    20
    Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough

      0  

    Default


    Dupe of http://www.sencha.com/forum/showthre...nd-bullets-bug

    When it comes to the editor mode on browsers, it's all a hack since every browser does things differently. We'll review what you have as a good starting point and see what we can do with it.

  3. #3
    Ext User
    Join Date
    Jul 2010
    Posts
    4
    Vote Rating
    0
    jimshell is on a distinguished road

      0  

    Default


    Quote Originally Posted by Jamie Avins View Post
    Dupe of http://www.sencha.com/forum/showthre...nd-bullets-bug

    When it comes to the editor mode on browsers, it's all a hack since every browser does things differently. We'll review what you have as a good starting point and see what we can do with it.
    Hi Jamie,

    Thank you for your reply! And apologies for the dupe (I got lost in the forums, definitely...)

    So, the "issue" is real with Chrome - I'm quite disappointed, actually, I like this browser
    I'm not satisfied with my code suggestion (not a JS expert), it doesn't produce a clean behaviour; why does Chrome insert those div tags at the end, I can't figure out, and my try to remove them breaks the focus on the textarea...

    As mentioned, I tried a hack with an "Ext.isWebkit" condition, but I don't know if all webkit browsers do the same.

    Anyway, I've been testing different JS libraries for 2 days now, and I must say that Ext JS is the best one (to me): neat and smart code, excellent functionalities... Many thanks for your work!

    I'm sure that you and your team will soon find a smart solution to have Chrome behave the "right way" ;-) And I'm glad if my try may help.

    Many thanks again,

    Jimshell

  4. #4
    Ext User
    Join Date
    Jul 2010
    Posts
    4
    Vote Rating
    0
    jimshell is on a distinguished road

      0  

    Default


    Hi Jamie and everyone

    OK, after a few tries, I think I have achieved something functional as a reliable "Chrome hack" to solve the lists issue.

    Here is the (final?) changes I made :

    Code:
        fixKeys : function(){ 
            if(Ext.isIE){
    
                [...]
    
            }else if(Ext.isOpera){
    
                [...]
    
            }else if(Ext.isWebKit){
    	    //This part of the function has been changed to fix the Chrome issue with lists
                return function(e){
                    var k = e.getKey(),
                        doc = this.getDoc(),
                            r;
                    if(k == e.TAB){
                        e.stopEvent();
                        this.execCmd('InsertText','\t');
                        this.deferFocus();
    		    //The fix starts in the next if statement to handle the Enter key properly
                    }else if(k == e.ENTER){
    				r = doc.getSelection();
    				if(r){
    					var target = r.anchorNode.parentNode.nodeName.toLowerCase();
    					if(target != 'ol' && target != 'ul' && target != 'li'){
    					//This is the normal behaviour when not typing in a list
    						e.stopEvent();
    						this.execCmd('InsertHtml','<br /><br />' );
    						this.deferFocus();
    					}else if(target == 'ol' || target == 'ul'){
    						//This is the new actions to take when pressing enter while editing a list.
    						//This actually does nothing in terms of HTML insertion - which let's
    						//Chrome add the final "br" tag inside unwanted "div" tags: 
    						//let's remove that when the keyup event is fired
    						Ext.EventManager.on(doc, 'keyup', this.delDivs, this);	
    						//The delDivs function has been added separately as a class function, 
    						//so that we can more easily remove the keyup listener when done
    					}
    				}
    			}
    		};
            }
        }(),
    
    	delDivs : function(){
    	//This function will get rid of the unwanted "div" tags
    		var doc = this.getDoc();
    		var target = doc.getElementsByTagName('div')[0];
    		target.parentNode.replaceChild(doc.createElement('br'),target);
    		//OK, we have removed the "div" tags, but the iframe lost the focus, 
    		//thus don't show the caret any longer - let's fix this
    		this.iframe.focus();
    		//the caret is back there, but at the beginning of the text, we want it right after 
    		//the last bit/list
    		this.execCmd('selectall');
    		var r = doc.getElementsByTagName('html')[0].innerHTML;
    		this.execCmd('InsertHtml',r);
    		//Let's scroll down in case we typed a huge text/list
    		this.iframe.contentWindow.scrollTo(0,1000000);	
    		//We're done. Now, let's remove the keyup listener as it's not required 
    		//until the next list is closed using the Enter key
    		Ext.EventManager.un(doc, 'keyup', this.delDivs, this);
    	},
    With these changes, I get the expected behaviour in Chrome, say:
    1. Enter Key : new point
    2. Shift + Enter : carriage return within the same point
    3. Enter Key when on an "empty point" (nothing typed after the new point has been created): the list is closed properly, the caret is visible and gets back to the normal position within the text area, the iframe is scrolled down conveniently.
    4. Selection of multiple line then list activation : works OK

    Attached is a zip file with my test files.

    Would be glad to know your thoughts on this as soon as you/your team has a chance to review it.

    Many thanks in advance,

    Jimshell
    Attached Files

  5. #5
    Sencha User
    Join Date
    Jan 2010
    Posts
    37
    Vote Rating
    0
    DerSalz is on a distinguished road

      0  

    Default


    Hi Jimshell and Jamie,

    I haven't seen your thread yesterday that's why I opened another thread:

    http://www.sencha.com/forum/showthre...leditor-in-IE8

    I checked the RTE with IE8 (IE9 beta) and it's even worse to what you described. I also tested Chrome and I can confirm your bug.

    At them moment only FF works as expected. Well... I don't like IE very much but for my project this has to work with IE7 and IE8. I don't have IE7 installed. You said that it works fine for IE7 right? If I would knew that there will be a solution für IE8 (and IE9) it would be great and I could go for it...

    Many thanks
    DerSalz

  6. #6
    Sencha User
    Join Date
    Feb 2013
    Location
    singapore
    Posts
    9
    Vote Rating
    0
    highradius is on a distinguished road

      0  

    Default


    thanks for this fix..it helped me

Similar Threads

  1. [OPEN-1096] HTMLEditor numbering and bullets bug
    By Xeon06 in forum Ext 3.x: Bugs
    Replies: 4
    Last Post: 24 Jun 2011, 7:26 AM
  2. Replies: 1
    Last Post: 1 Jul 2010, 7:44 AM
  3. Google Chrome OS
    By TopKatz in forum Community Discussion
    Replies: 5
    Last Post: 28 Nov 2009, 9:15 AM
  4. Google Chrome
    By evant in forum Community Discussion
    Replies: 38
    Last Post: 3 Sep 2008, 5:15 AM

Thread Participants: 3

Turkiyenin en sevilen filmlerinin yer aldigi xnxx internet sitemiz olan ve porn sex tarzi bir site olan mobil porno izle sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli porno izle siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir. Mesela diğer sitelerimizden bahsedecek olursak, en iyi hd porno video arşivine sahip bir siteyiz. "The Best anal porn videos and slut anus, big asses movies set..."