[OSX][Webkit/Blink][Image2] No context menu entry on right-click

[Olek Nowodziński]

Use Chrome/Safari:

1. ​http://ckeditor.com/demo#widgets
2. Go to "Image Tool" section.
3. Right-click the widget:
   • OSX: No "Image Properties" entry.
   • Linux: "Image Properties" is available.

Works in FF in both OSs.

[webbson]

Bug was present in previous Chrome Beta. In the current Chrome Beta (32.0.1700.76 beta) bug is no longer happening.

[Jakub Ś]

This issue may be related to #11475.

[Kyle]

The context menu appears inconsistently, showing only the "Copy" menu option

Confirmed that this bug is still present in:

• Mac OS X 10.9.1
  • Google Chrome Version 32.0.1700.107
  • Apple Safari 7.0.1 (9537.73.11)

FF 26.0 and 27.0 Firebug console shows no errors on the same click event

The context-menu click event on Google Chrome produces the following message in the Inspector Console:

body.scrollLeft is deprecated in strict mode. Please use 'documentElement.scrollLeft' if in strict mode and 'body.scrollLeft' only if in quirks mode. ckeditor.js?n0u4gq:90
body.scrollTop is deprecated in strict mode. Please use 'documentElement.scrollTop' if in strict mode and 'body.scrollTop' only if in quirks mode. 

Safari shows no error output on the click event — while only showing the 'copy' menu item

FWIW; works in IE8 - IE9 on Win7

[Wim Leers]

I ran into this while working on integrating CKEditor 4.4/image2 with Drupal 8 (​https://drupal.org/node/2039163). Thank to @reinmar for pointing me here.

I can confirm that in Firefox (28) on OS X, it works fine.

[Wim Leers]

Not sure if that's the right way to do it, but this is still a bug in 4.4.0, so updating the version property.

[Piotrek Koszuliński]

The version means the first version in which the problem is reproducible.

Let's give this bug a try in 4.4.2. I didn't have much time to debug it while working on Widgets System, so maybe now we'll spot the problem.

[Olek Nowodziński]

Debug code pushed to ​branch:t/11306. Works with attached debug sample.

The main difference between Windows and OSX starts after contextmenu.open() ​calls editor.selectionChange( 1 ), which has been introduced for #9362.

Since that moment, which is visible in the console as follows in OSX:

* editor.getSelection( forceRealSelection = 1 ) selection.js:946
* checkSelectionChange() #2 {
	startElement: <img alt="Saturn V" width="200" data-cke-saved-src="sample1.png" src="sample1.png">,
	isFake: NO,
	isHidden: NO,
	range: {
		startContainer: <span class="cke_image_resizer_wrapper">...</span>,
		startOffset: 0,
		endContainer: <span class="cke_image_resizer_wrapper">...</span>,
		endOffset: 1,
		collapsed: NO
	},
	native: {
		anchorNode: <span class="cke_image_resizer_wrapper">...</span>
	}
} 

and in Windows:

* editor.getSelection( forceRealSelection = 1 ) selection.js:946
* checkSelectionChange() #2 {
	startElement: <div data-cke-hidden-sel="1" data-cke-temp="1" style="position:fixed;top:0;left:-1000px">...</div>,
	isFake: NO,
	isHidden: HIDDEN,
	range: {
		startContainer: <div data-cke-hidden-sel="1" data-cke-temp="1" style="position:fixed;top:0;left:-1000px">...</div>,
		startOffset: 0,
		endContainer: <div data-cke-hidden-sel="1" data-cke-temp="1" style="position:fixed;top:0;left:-1000px">...</div>,
		endOffset: 1,
		collapsed: NO
	},
	native: {
		anchorNode: " "
	}
} 

it turns out that for some reason (on right-click, in OSX) selection is not properly anchored in fake selection container, but it remains in the widget. What happens next is just an effect of that – menu plugin reads start element and, since it is not a widget.wrapper but <img>, it renders a wrong set of context menu entries.

While the above pretty clear, I'm not able to figure out why Webkit in OSX is so different in terms of right-click. Something tells me that this is something out of our control, but perhaps some fix in selection.fake() would help us (assuming that my previous conclusions are right).

Anyway, this is a job for someone in whose family the Force is strong.

[Olek Nowodziński]

A playground compatible with t/11306

[Piotrek Koszuliński]

I didn't spent on this issue a lot of time, but I have one important finding. When on other browsers and systems mousedown can be prevented for left click and right click on Blink/Webkit on MacOS preventDefault has no effect. Browser moves selection to clicked word or element.

The reason why context menu works on other browsers is that widgets block mousedown, so refreshing selection in ctxmenu.open doesn't change anything, because selection is still faked or just has been faked. On MacOS real selection is moved to the image resize wrapper so fake selection is invalidated.

I think that the best fix will be to listen on native contextmenu event from widget plugin and fix the broken selection if non-editable part of widget is a target of the event. Alternatively this fix may land right in the contextmenu plugin and using elementPath.contains( element with ce=false ) or similar approach find first non-editable parent of the target and fake selection on it.

This will help because the selection is already in the wrong place inside the contextmenu event. I'm only worried about selectionChange event which will be fired twice - after use clicks but before contextmenu event and when we'll refake selection. But it should be ok, because ctxmenu.open fires selectionChange anyway.

[Piotrek Koszuliński]

var path = new CKEDITOR.dom.elementPath( domEvent.getTarget(), this.editor.editable() ),
	nonEditableParent = path.contains( function( el ) {
		return el.getAttribute( 'contenteditable' ) == 'false'
	} );

if ( nonEditableParent )
	this.editor.getSelection().fake( nonEditableParent );

This makes ctx menu working on widget when added after domEvent.preventDefault(); However, it needs work because it breaks ctx menu inside nested editable. Additionally, I'm not sure in which order path.contains check nodes - should go down to the root, not up.

[Olek Nowodziński]

Pushed ​branch:t/11306b (+tests) with an extension of the solution mentioned in comment:10.

It seems to solve the problem. However I noticed that if focused editor's editable, scrolled down to the last widget (plugins/image2/samples/image2.html) and right-clicked nested-editable, editor scrolls back to the top and displays wrong context menu (the context is <h1> – that's bad). It's strange but quite likely not related to this ticket (I'm able to reproduce it on master). If that's confirmed, I'll create a separate ticket for that issue.

[Piotrek Koszuliński]

I couldn't reproduce the issue with scrolling. For me the solution work perfectly on Chrome and Safari. I pushed additional commit simplifying the code.

[Piotrek Koszuliński]

Fixed on master with ​git:6413df4 on dev and c9af40d on tests.