Title: [137049] trunk/Source/WebKit/blackberry
Revision
137049
Author
[email protected]
Date
2012-12-08 15:07:31 -0800 (Sat, 08 Dec 2012)

Log Message

[BlackBerry] Google results page rendering issue with RTL languages like arabic/hebrew
https://bugs.webkit.org/show_bug.cgi?id=104451

Patch by Jacky Jiang  <[email protected]>.
Reviewed by Rob Buis.

PR: 206372
On Google results page, we layout the contents at the width of 833.
However, "appbar" and "top_nav" elements which have width 980 cause
overflow during the last layout and make the contents width larger.
The other renderers still stay at the old width unfortunately which
results in blank areas on the left side of the Google results RTL page.
Give it a chance to request another layout if overflow exceeds the
contents size and the page doesn't have virtual viewport, as this
layout will pick up the absolute visible overflow width within
DEFAULT_MAX_LAYOUT_WIDTH and update the other renderers.

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::overflowExceedsContentsSize):
(WebKit):
* Api/WebPage_p.h:
(WebPagePrivate):

Modified Paths

Diff

Modified: trunk/Source/WebKit/blackberry/Api/WebPage.cpp (137048 => 137049)


--- trunk/Source/WebKit/blackberry/Api/WebPage.cpp	2012-12-08 21:47:56 UTC (rev 137048)
+++ trunk/Source/WebKit/blackberry/Api/WebPage.cpp	2012-12-08 23:07:31 UTC (rev 137049)
@@ -1554,6 +1554,17 @@
 #endif
 }
 
+void WebPagePrivate::overflowExceedsContentsSize()
+{
+    m_overflowExceedsContentsSize = true;
+    if (absoluteVisibleOverflowSize().width() < DEFAULT_MAX_LAYOUT_WIDTH && !hasVirtualViewport()) {
+        if (setViewMode(viewMode())) {
+            setNeedsLayout();
+            requestLayoutIfNeeded();
+        }
+    }
+}
+
 void WebPagePrivate::layoutFinished()
 {
     if (!m_contentsSizeChanged && !m_overflowExceedsContentsSize)

Modified: trunk/Source/WebKit/blackberry/Api/WebPage_p.h (137048 => 137049)


--- trunk/Source/WebKit/blackberry/Api/WebPage_p.h	2012-12-08 21:47:56 UTC (rev 137048)
+++ trunk/Source/WebKit/blackberry/Api/WebPage_p.h	2012-12-08 23:07:31 UTC (rev 137049)
@@ -221,7 +221,7 @@
     void exitFullScreenForElement(WebCore::Element*);
 #endif
     void contentsSizeChanged(const WebCore::IntSize&);
-    void overflowExceedsContentsSize() { m_overflowExceedsContentsSize = true; }
+    void overflowExceedsContentsSize();
     void layoutFinished();
     void setNeedTouchEvents(bool);
     void notifyPopupAutofillDialog(const Vector<String>&);

Modified: trunk/Source/WebKit/blackberry/ChangeLog (137048 => 137049)


--- trunk/Source/WebKit/blackberry/ChangeLog	2012-12-08 21:47:56 UTC (rev 137048)
+++ trunk/Source/WebKit/blackberry/ChangeLog	2012-12-08 23:07:31 UTC (rev 137049)
@@ -1,3 +1,27 @@
+2012-12-08  Jacky Jiang  <[email protected]>
+
+        [BlackBerry] Google results page rendering issue with RTL languages like arabic/hebrew
+        https://bugs.webkit.org/show_bug.cgi?id=104451
+
+        Reviewed by Rob Buis.
+
+        PR: 206372
+        On Google results page, we layout the contents at the width of 833.
+        However, "appbar" and "top_nav" elements which have width 980 cause
+        overflow during the last layout and make the contents width larger.
+        The other renderers still stay at the old width unfortunately which
+        results in blank areas on the left side of the Google results RTL page.
+        Give it a chance to request another layout if overflow exceeds the
+        contents size and the page doesn't have virtual viewport, as this
+        layout will pick up the absolute visible overflow width within
+        DEFAULT_MAX_LAYOUT_WIDTH and update the other renderers.
+
+        * Api/WebPage.cpp:
+        (BlackBerry::WebKit::WebPagePrivate::overflowExceedsContentsSize):
+        (WebKit):
+        * Api/WebPage_p.h:
+        (WebPagePrivate):
+
 2012-12-08  Mike Fenton  <[email protected]>
 
         [BlackBerry] Enforce selection of last work when triggering caret based selection
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to