Opened 12 years ago

Closed 9 years ago

#7582 closed Bug (fixed)

IE: Cannot select items from the context menu when a table is selected

Reported by: James Cunningham Owned by:
Priority: Normal Milestone:
Component: UI : Floating Panel Version: 3.2.2
Keywords: IBM IE Cc: Damian, Satya Minnekanti, Teresa Monahan


Steps to reproduce the defect:

  1. Open the Ajax sample in IE.
  1. Paste the following code into the source view.
<table border="1" cellpadding="1" cellspacing="1" style="width: 500px; height: 200px">

  1. Return to WYSIWYG mode & click into the editor to give it focus.
  1. Hover the cursor over one of the table borders until the cursor becomes a cross & click the left mouse button to select the table.
  1. Now hover the cursor anywhere over the selected table and click the right mouse button to display the context menu.
  1. Try to select Table Properties from the context menu.

Expected: The Table properties dialog is displayed.

Actual: The context menu remains on the screen. The Table Properties option in the context menu is selected & the Table Properties dialog is not displayed. (see screenshot)

Attachments (1)

context menu over selected table defect.JPG (36.5 KB) - added by James Cunningham 12 years ago.

Download all attachments as: .zip

Change History (10)

Changed 12 years ago by James Cunningham

comment:1 Changed 12 years ago by Jakub Ś

Status: newconfirmed

True for IE6 IE7 and IE8 from CKEditor version 3.3.2.

It works in IE9.

comment:2 Changed 12 years ago by typeof

3.5.3, IE8: I noticed an interesting behavior.

Ad.3 Put the caret in the first cell of the second row

Ad.4 Click the border between cells in the first row - the bug appears

and now repeat it but click the border between cells in the third row - no bug, it works :)

I'll try to further debug it

comment:3 Changed 12 years ago by typeof


Additional details on bug symptoms

  1. The bug occurs only when you click a menu item in the point which is over the selected table. If this point is outside the table boundaries then everything works as it should. For example consider opening context menu near the right border - the menu is partly inside and party outside the table. Now it depends where you exactly clicked at the item.
  2. The bug occurs if you click left or right mouse button
  3. Selection visually changes from table to clicked element (it can be item text or item icon). Clicked element do not respond to clicks anymore. You can however choose this item by pressing enter or by clicking the item icon or text (if the selected element is text or icon respectively)

You may see an interesting side effect when you click the item for the first time - do not release the mouse button and you'll be able to drag the item outside the menu :)

Technical details

The selected element does not receive onclick events. It still receives oncontextmenu event. Selection changes from table to none.

Solution (workaround) proposition

If all the following conditions are met:

  • the menu is open
  • selection is table
  • ie7 or ie8

then check on some time interval if:

  • menu is still open
  • selection changed from table to none

and if so then invoke onclick function of the item. The item to "click" will be chosen based on onmouseover and onmouseout events.


There is one drawback of the above solution. We must slightly modify behavior of the right click on a menu item. Normally it is ignored but in this particular situation we cannot ignore it because we won't have any way to recognize if there will be a left click afterwards. I see two possibilities:

  1. Treat right click as the left click and execute menu command
  2. Close context menu on the right click
Last edited 12 years ago by typeof (previous) (diff)

comment:4 Changed 12 years ago by Frederico Caldeira Knabben

Component: GeneralUI : Floating Panel

The problem here is clearly the overlay IE uses to indicate the table selection (I think it adds a transparent object over the entire document contents, no matter the z-index). It seems that IE catches clicks on it and passes it to the object under it. But it's doing it improperly, in the case of the context menu, essentially focusing the element, instead on clicking on it.

Interestingly, this doesn't happen for images.

I doubt we would be able to catch this event somehow. I think the easiest thing we could do here is simply guarantee that there is no table selected in the editor when the context menu opens (lock on open -> unselect -> unlock on close). This is the IE9 behavior for it, in fact.

We have the same problem with toolbar combos. So this fix should not go on the contextmenu code, but on the floating panel.

comment:5 Changed 12 years ago by typeof

I guess I was too much fixed to my idea that keeping table selection when the context menu is shown will provide better user experience :) I admit your solution is better.

One question: do I proposed the valid code to unselect there ?

comment:6 in reply to:  5 Changed 12 years ago by Frederico Caldeira Knabben

Replying to typeof:

One question: do I proposed the valid code to unselect there ?

Actually you're not unselecting things there, but instead moving the selection to another place. Additionally, it may happen to the editing area to scroll to top with that code.

I don't think we have a ready to use API function to unselect. Being this a browser specific issue, it would be enough to manipulate the native selection object in this case.

Another note regarding your code. You should have used range.moveToElementEditStart and (I know, there is not API documentation for this, I'm sorry)

comment:7 Changed 12 years ago by typeof

Ok, thanx.

And what does it actually mean that a selection is locked? Looking at e.g. selection::selectRanges() I see that when the selection is locked then the native selection stays intact.

But you wrote in your comment "lock on open -> unselect -> unlock on close" (where unselect regards native selection).. so I'm a bit confused what the locking really is :)

comment:8 Changed 12 years ago by Frederico Caldeira Knabben

On lock, the editor takes a kind of "snapshot" of the selection. Any manipulation to the selection through our API will work on that snapshot.

If we do "non standards API changes" to the selection (like removing the selection), then we'll not touch that snapshot.

Once we close the floating panel, we then use the snapshot to recover the selection state before locking.

This is just theoretical, but it may be a way to for it.

comment:9 Changed 9 years ago by Piotrek Koszuliński

Resolution: fixed
Status: confirmedclosed

We were not able to reproduce this issue on IE8 on any version of CKEditor (we were checking back to 3.3.*). Perhaps it's due to the very complicated steps (comment:2). Additionally, other browsers on which this issue was reproducible are not supported any more, thus I'm closing this ticket. If anyone is still able to reproduce the issue on any of the supported IE versions, please let us know, we'll reopen this ticket.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy