Ticket #647 (closed Bug: fixed)

Opened 7 years ago

Last modified 5 years ago

[EK] In RC2, using IE6 issues with UseBROnCarriageReturn

Reported by: anonymous Owned by:
Priority: Normal Milestone: FCKeditor 2.5 Beta
Component: Core : Lists Version:
Keywords: SF Cc: fredck, andrwo@…, cluestream@…

Description

I enabled the UseBROnCarriageReturn option in RC2 and then went to experiment with the editor in IE6. Some weird behavior started showing up with the bulleted list functionality. When I tried to create a list, it put all the content in the text box into a single list item. This occured even if I hit return several times, typed something else, highlighted only the new text, and then hit the button. I'm guessing the function was trying to seperate things by <p> tags, instead of <br> ones. The same problem showed up with the numbered list.


Moved from SF:
http://sourceforge.net/tracker/index.php?func=detail&aid=1104098&group_id=75348&atid=543653

Change History

comment:1 Changed 7 years ago by martinkou

  • Cc fredck, andrwo@…, cluestream@… added
  • Reporter changed from martinkou to anonymous

Marking it as Enter Key [EK]


Moved from SF. Original poster: fredck

Thanks for the patch, andrwo ... I see some new evidence of it in 2.0FC but the guts are removed and it's commented out ... guess somebody tried it at least ... ? A fix should really get in there ... the default behavior is sufficiently awful that nobody could really want it to work that way.

My tweaked version follows ... by defaulting to the normal behavior for un-handled cases, it allows you to switch an OL to a UL and vice versa, and other important cases. The original version also contained a risk of infinite loop by calling FCK.ExecuteNamedCommand(...) at the end ... which would in turn again call ExecuteRedirectedNamedCommand ... etc. -- if the conditionals and the list of commands redirected got out of sync. This way is a little safer for further evolution.

if ( FCKConfig.UseBROnCarriageReturn )
{
        // Named commands to be handled by this browsers
specific implementation.
        FCK.RedirectNamedCommands =
        {
                InsertOrderedList       : true,
                InsertUnorderedList     : true
        }

        FCK.ExecuteRedirectedNamedCommand = function(
commandName, commandParameter )
        {
                if ( commandName == 'InsertOrderedList' ||
commandName == 'InsertUnorderedList' )
                {
                        if (
!(FCK.EditorDocument.queryCommandState( 'InsertOrderedList'
) || FCK.EditorDocument.queryCommandState(
'InsertUnorderedList' )) )
                        {
                            var item;
                           
if(commandName=="InsertOrderedList") item="ol";else
item="ul";
                            var oSel =
FCK.EditorDocument.selection;
                            var oRg = oSel.createRange();
                            oRg.setEndPoint("EndToStart",oRg)
                            oRg.pasteHTML( "<"+item+"><li>" );
                            return true;
                        }
                }
                // not a case we are monitoring, so behave
like regular ExecuteNamedCommand
                FCK.Focus() ;
                FCK.EditorDocument.execCommand( commandName,
false, commandParameter ) ;
                FCK.Events.FireEvent( 'OnSelectionChange' ) ;
        }
}

I also added the following at line 85 in fck_1_ie.js, which implements the tab-indent, shift-tab-outdent behavior familiar to Word users. I figure since we are already subverting OnKeyDown we might as well go all the way.

        else if ( e.keyCode == 9 &&
FCKConfig.UseBROnCarriageReturn )   // TAB
        {
            if ( FCK.EditorDocument.queryCommandState(
'InsertOrderedList' ) ||
FCK.EditorDocument.queryCommandState( 'InsertUnorderedList' ) )
                if (e.shiftKey)
                {
                    FCK.ExecuteNamedCommand("Outdent");
                }
                else
                {
                    FCK.ExecuteNamedCommand("Indent");
                }
                return false ;
        }

This behavior would be nice even outside of UseBROnCarriageReturn, but then we're not necessarily intercepting keypresses. I will probably be working on this issue some more due to other top-case problems in the IE6 list implementation, so I may post further ideas ...


Moved from SF. Original poster: cluestream

Facing the same problem.

I've approximated a better behaviour with a change in the script, not ideal, but better than the default. Add the following code at the start of fck_2_ie.js (or for the compressed version, before the FCK.Paste=function()... line in fckeditorcode_ie_2.js):

if ( FCKConfig.UseBROnCarriageReturn ) 
{
	// Named commands to be handled by this browsers 
specific implementation.
	FCK.RedirectNamedCommands = 
	{
		InsertOrderedList	: true,
		InsertUnorderedList	: true
	}

	FCK.ExecuteRedirectedNamedCommand = function( 
commandName, commandParameter )
	{
		if ( commandName == 'InsertOrderedList' 
|| commandName == 'InsertUnorderedList' )
		{
			if ( !
(FCK.EditorDocument.queryCommandState
( 'InsertOrderedList' ) || 
FCK.EditorDocument.queryCommandState
( 'InsertUnorderedList' )) )
			{
		var item;
		if(commandName=="InsertOrderedList") 
item="OL";else	item="UL";
		var oSel = FCK.EditorDocument.selection;
		var oRg = oSel.createRange();
		oRg.setEndPoint("EndToStart",oRg)
		oRg.pasteHTML( "<"+item+"><li>" ) ;
			}			
	
		return true;
		}

		FCK.ExecuteNamedCommand( 
commandName, commandParameter ) ;
	}
}

Moved from SF. Original poster: andrwo

comment:2 Changed 7 years ago by fredck

  • Status changed from new to closed
  • Component changed from General to Core : Lists
  • Resolution set to fixed
  • Milestone set to FCKeditor 2.5

This one has been fixed for version 2.5.

Note: See TracTickets for help on using tickets.
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy