Opened 10 years ago

Closed 10 years ago

#11306 closed Bug (fixed)

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

Reported by: Olek Nowodziński Owned by: Olek Nowodziński
Priority: Normal Milestone: CKEditor 4.4.2
Component: UI : Context Menu Version: 4.3 Beta
Keywords: Mac Webkit Blink Cc: wim.leers@…


Use Chrome/Safari:

  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.

Attachments (1) (7.2 KB) - added by Olek Nowodziński 10 years ago.
A playground compatible with t/11306

Download all attachments as: .zip

Change History (15)

comment:1 Changed 10 years ago by Jakub Ś

Keywords: Mac added
Status: newconfirmed

comment:2 Changed 10 years ago by webbson

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

comment:3 Changed 10 years ago by Jakub Ś

Keywords: Webkit Blink added

This issue may be related to #11475.

comment:4 Changed 10 years ago by 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

comment:5 Changed 10 years ago by Wim Leers

Cc: wim.leers@… added

I ran into this while working on integrating CKEditor 4.4/image2 with Drupal 8 ( Thank to @reinmar for pointing me here.

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

comment:6 Changed 10 years ago by Wim Leers

Version: 4.3 Beta4.4.0

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.

comment:7 Changed 10 years ago by Piotrek Koszuliński

Milestone: CKEditor 4.4.2
Version: Beta

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.

comment:8 Changed 10 years ago by Olek Nowodziński

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

The main difference between Windows and OSX starts after 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.

Changed 10 years ago by Olek Nowodziński

Attachment: added

A playground compatible with t/11306

comment:9 Changed 10 years ago by 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 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 fires selectionChange anyway.

comment:10 Changed 10 years ago by 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.

comment:11 Changed 10 years ago by Olek Nowodziński

Owner: set to Olek Nowodziński
Status: confirmedassigned

comment:12 Changed 10 years ago by Olek Nowodziński

Status: assignedreview

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.

comment:13 Changed 10 years ago by Piotrek Koszuliński

Status: reviewreview_passed

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.

comment:14 Changed 10 years ago by Piotrek Koszuliński

Resolution: fixed
Status: review_passedclosed

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

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