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

[James Cunningham]

Steps to reproduce the defect:

1. Open the Ajax sample in IE.

2. Paste the following code into the source view.

<table border="1" cellpadding="1" cellspacing="1" style="width: 500px; height: 200px">
	<tbody>
		<tr>
			<td>&nbsp;</td>
			<td>&nbsp;</td>
		</tr>
		<tr>
			<td>&nbsp;</td>
			<td>&nbsp;</td>
		</tr>
		<tr>
			<td>&nbsp;</td>
			<td>&nbsp;</td>
		</tr>
	</tbody>
</table>

3. Return to WYSIWYG mode & click into the editor to give it focus.

4. Hover the cursor over one of the table borders until the cursor becomes a cross & click the left mouse button to select the table.

5. Now hover the cursor anywhere over the selected table and click the right mouse button to display the context menu.

6. 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)

[Jakub Ś]

True for IE6 IE7 and IE8 from CKEditor version 3.3.2.

It works in IE9.

[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

[typeof]

[IE8]

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.

Comments

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

[Frederico Caldeira Knabben]

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.

[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 ​http://cksource.com/forums/viewtopic.php?f=11&t=22439 ?

[Frederico Caldeira Knabben]

Replying to typeof:

One question: do I proposed the valid code to unselect there ​http://cksource.com/forums/viewtopic.php?f=11&t=22439 ?

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 range.select. (I know, there is not API documentation for this, I'm sorry)

[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 :)

[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.

[Piotrek Koszuliński]

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.