Ticket #2426 (closed Bug: fixed)

Opened 4 months ago

Last modified 3 months ago

IE: Switching between two editors with shared toolbar does not work properly

Reported by: Mathias-S Owned by: martinkou
Priority: Normal Milestone: FCKeditor 2.6.3
Component: General Version: FCKeditor 2.6.3 Beta
Keywords: Confirmed IE Review+ Cc:

Description

When using two FCKeditor instances with a shared toolbar, it is not possible to directly switch from one instance to another. One has to click either outside the editors, then on the second instance, or twice on the second instance.

To recreate: 1. Open sample10.html or sample11.html in IE 2. Select the first instance of FCKeditor 3. Select the second instance

When you select the second instance, the toolbar is deactivated, and the cursor remains in the first instance. You have to click twice on the second instance to properly activate it.

The fix of #2376 is the cause of the regression. In my view, it would be best to revert that change, since it makes the use of shared toolbar practically impossible.

Attachments

2426.patch (1.2 KB) - added by martinkou 4 months ago.

Change History

Changed 4 months ago by martinkou

  • owner set to martinkou
  • status changed from new to assigned

Changed 4 months ago by martinkou

Changed 4 months ago by martinkou

  • keywords Review? added

It turns out this is not caused by an IE bug. The brief flickering which stopped you from switching between editor instances in a single click happened because FCKSelection.Restore() was called when you tried to focus into the other editor instance. But FCKSelection.Restore() brought the focus back to where you started because the saved selection was in the first editor instance.

What my patch does is that, as long as you've brought your focus to an editable area, FCKSelection.Restore() won't do anything.

Changed 4 months ago by martinkou

  • keywords Confirmed IE added
  • version set to FCKeditor 2.6.3 Beta

Changed 4 months ago by fredck

  • keywords Review+ added; Review? removed

Changed 4 months ago by martinkou

  • status changed from assigned to closed
  • resolution set to fixed

Fixed with [2323].

Click here for more info about our SVN system.

Changed 3 months ago by alfonsoml

this fix has caused #2496

Note: See TracTickets for help on using tickets.