Title: [131816] trunk/Source/WebKit/blackberry
- Revision
- 131816
- Author
- zhaji...@rim.com
- Date
- 2012-10-18 15:29:19 -0700 (Thu, 18 Oct 2012)
Log Message
[BlackBerry] Page viewport aspect ratio not kept on navigating back
https://bugs.webkit.org/show_bug.cgi?id=99760
Reviewed by Rob Buis.
Patch by Jacky Jiang <zhaji...@rim.com>.
Internally reviewed by Konrad Piascik.
PR: 190469
This was added in r127628 which was trying to fix some rendering
defects on maps.google.com and news.qq.com, however it was very harmful
and caused regressions.
zoomToFitScale() depends on the current contents size. During history
navigation and device rotation, if zoomToFitScale() is based on the
final contents size which is expected, there will still be a scale
calculation like this afterwards
screenSize.width()/screenSize.height()*zoomToFitScale() which will
result in a wrong scale. During the history navigation, if
zoomToFitScale() isn't based on the final contents size, then we will
get the wrong scale as well for sure.
This issue will be fixed by removing the wrong calculation.
The original issue of r127628 was fixed by the patch of PR225981.
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::restoreViewState):
Modified Paths
Diff
Modified: trunk/Source/WebKit/blackberry/ChangeLog (131815 => 131816)
--- trunk/Source/WebKit/blackberry/ChangeLog 2012-10-18 22:24:32 UTC (rev 131815)
+++ trunk/Source/WebKit/blackberry/ChangeLog 2012-10-18 22:29:19 UTC (rev 131816)
@@ -1,3 +1,29 @@
+2012-10-18 Jacky Jiang <zhaji...@rim.com>
+
+ [BlackBerry] Page viewport aspect ratio not kept on navigating back
+ https://bugs.webkit.org/show_bug.cgi?id=99760
+
+ Reviewed by Rob Buis.
+ Internally reviewed by Konrad Piascik.
+
+ PR: 190469
+ This was added in r127628 which was trying to fix some rendering
+ defects on maps.google.com and news.qq.com, however it was very harmful
+ and caused regressions.
+ zoomToFitScale() depends on the current contents size. During history
+ navigation and device rotation, if zoomToFitScale() is based on the
+ final contents size which is expected, there will still be a scale
+ calculation like this afterwards
+ screenSize.width()/screenSize.height()*zoomToFitScale() which will
+ result in a wrong scale. During the history navigation, if
+ zoomToFitScale() isn't based on the final contents size, then we will
+ get the wrong scale as well for sure.
+ This issue will be fixed by removing the wrong calculation.
+ The original issue of r127628 was fixed by the patch of PR225981.
+
+ * WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
+ (WebCore::FrameLoaderClientBlackBerry::restoreViewState):
+
2012-10-18 John Griggs <jgri...@rim.com>
2012-10-18 John Griggs <jgri...@rim.com>
Modified: trunk/Source/WebKit/blackberry/WebCoreSupport/FrameLoaderClientBlackBerry.cpp (131815 => 131816)
--- trunk/Source/WebKit/blackberry/WebCoreSupport/FrameLoaderClientBlackBerry.cpp 2012-10-18 22:24:32 UTC (rev 131815)
+++ trunk/Source/WebKit/blackberry/WebCoreSupport/FrameLoaderClientBlackBerry.cpp 2012-10-18 22:29:19 UTC (rev 131816)
@@ -1083,12 +1083,6 @@
// Also, try to keep the users zoom if any.
double scale = viewState.scale;
- // If it was zoomToFitScale use the new zoomToFitScale because
- // the new one may be different to the old one due to contents
- // size change (e.g. after reloaded).
- if (viewState.isZoomToFitScale)
- scale = m_webPagePrivate->zoomToFitScale();
-
bool shouldReflowBlock = viewState.shouldReflowBlock;
if (m_webPagePrivate->m_userPerformedManualZoom) {
scale = m_webPagePrivate->currentScale();
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-changes
