A tricky fix for Issue 1845 (Take 2).

This is almost the same change as <http://codereview.chromium.org/39252/show>, which caused a build break on a Linux buildbot while compiling my new template function in "chrome/common/render_messages.h".
Even though I was not able to reproduce the build errors on my Linux box, I removed this function and use the int type in my IPC message 'ViewMsg_SetTextDirection'.

BUG=1845
Review URL: http://codereview.chromium.org/42495

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12434 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 31 insertions, 0 deletions

diff --git a/webkit/glue/webview_impl.cc b/webkit/glue/webview_impl.cc
index 98c33fe..27d66c6 100644
--- a/webkit/glue/webview_impl.cc
+++ b/webkit/glue/webview_impl.cc
@@ -1236,6 +1236,37 @@ bool WebViewImpl::ImeUpdateStatus(bool* enable_ime,
   return true;
 }
 
+void WebViewImpl::SetTextDirection(WebTextDirection direction) {
+  // The Editor::setBaseWritingDirection() function checks if we can change
+  // the text direction of the selected node and updates its DOM "dir"
+  // attribute and its CSS "direction" property.
+  // So, we just call the function as Safari does.
+  const Frame* focused = GetFocusedWebCoreFrame();
+  if (!focused)
+    return;
+  Editor* editor = focused->editor();
+  if (!editor || !editor->canEdit())
+    return;
+
+  switch (direction) {
+    case WEB_TEXT_DIRECTION_DEFAULT:
+      editor->setBaseWritingDirection(WebCore::NaturalWritingDirection);
+      break;
+
+    case WEB_TEXT_DIRECTION_LTR:
+      editor->setBaseWritingDirection(WebCore::LeftToRightWritingDirection);
+      break;
+
+    case WEB_TEXT_DIRECTION_RTL:
+      editor->setBaseWritingDirection(WebCore::RightToLeftWritingDirection);
+      break;
+
+    default:
+      NOTIMPLEMENTED();
+      break;
+  }
+}
+
 void WebViewImpl::RestoreFocus() {
   if (last_focused_frame_.get()) {
     if (last_focused_frame_->page()) {