fixup! Disambiguate ShowContextMenu implementation.

In case one right clicks with say a bluetooth mouse or on
on desktop builds, context menu should be shown right way.

Patch fixes the broken assuption that
WebContentsViewDelegateEwk::ShowContextMenu should always enter
selection mode. This is only valid in case of touch-based event
source, i.e. on Mobile or ubrowser --mobile.

Patch also fixes utc_blink_cb_contextmenu_allowed.cpp.

Bug: http://107.108.218.239/bugzilla/show_bug.cgi?id=14304

Reviewed by: a.renevier, a1.gomes, djmix.kim

Change-Id: Ib409bb5d9ec2492cf622c43eddd710eebb4aabfc
Signed-off-by: Antonio Gomes <a1.gomes@samsung.com>

diff --git a/tizen_src/ewk/efl_integration/web_contents_view_delegate_ewk.cc b/tizen_src/ewk/efl_integration/web_contents_view_delegate_ewk.cc
index b69f4b355bd49e0420b3b1e5b48e23e97bf233f1..315059075936187c9181ad2f383286c2cff065f7 100644 (file)
--- a/tizen_src/ewk/efl_integration/web_contents_view_delegate_ewk.cc
+++ b/tizen_src/ewk/efl_integration/web_contents_view_delegate_ewk.cc
@@ -11,11 +11,19 @@ WebContentsViewDelegateEwk::WebContentsViewDelegateEwk(EWebView* wv)
 }
 
 // Note: WebContentsViewDelegate::ShowContextMenu is the hook called
-// by chromium in response to a long press gesture.
-// However, in EWK apps, browser enters in selection mode in response
-// to it.
+// by chromium in response to either a long press gesture (in case of
+// touch-based input event is the source) or a right button mouse click
+// (in case source is mouse-based).
+// For the former, EWK apps enter selection mode, whereas for the
+// later, context menu is shown right way.
 void WebContentsViewDelegateEwk::ShowContextMenu(
     content::RenderFrameHost* render_frame_host,
     const content::ContextMenuParams& params) {
-  web_view_->HandleLongPressGesture(params);
+
+  if (params.source_type == ui::MENU_SOURCE_TOUCH) {
+    CHECK(web_view_->TouchEventsEnabled());
+    web_view_->HandleLongPressGesture(params);
+  } else {
+    web_view_->ShowContextMenu(params);
+  }
 }