[Webkit-unassigned] [Bug 50762] [EFL] ContextMenu implementation is broken

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=50762





--- Comment #6 from Leandro Pereira <leandro at profusion.mobi>  2010-12-15 11:14:24 PST ---
(In reply to comment #5)
> 
> Could you pass the ContextMenuClient instead of the ContextMenuController? I 
> think that would be okay, but would need to see a patch to know for sure.
> 

This seems possible, yes. I'll give it a try.

> One option would be to hook into the new USE(CROSS_PLATFORM_CONTEXT_MENUS) 
> macro, which gives you a representation of ContextMenus and ContextMenuItems 
> not using native types, and all you need to do is write functions that convert 
> from ContextMenu <-> Native EFL Menus, and ContextMenuItem <-> Native EFL Menu 
> Items. If you want to see how that is done currently, look at
> ContextMenu{.h|.cpp}, ContextMenuItem{.h|.cpp}, ContextMenuItemWin.cpp and 
> ContextMenuWin.cpp.
> 

Already looked at it. The problem is: EFL does not have a native widget set. 

Our current implementation delegates the responsibility to create the menu UI to the browser, so it can use whatever UI toolkit it is already using, by choosing the appropriate widget for the task (pop-up menus on desktop, lists on mobile/touch screen devices, etc).

This delegation is currently implemented on EWK (short for EFL-WebKit), so we can't really expose those functions to WebCore as it would be way nastier than HitTestResult being there :)

I'll see if I can do that with ContextMenuClient, by creating a façade to our menu-delegating functions in EWK.

Does this sound OK?

If so, to get rid of all those #ifdefs inside platform-independent code I could add a ContextMenuClient* to ContextMenu; most ports don't use this, however, so I'm on a bit of impasse here.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.