Title: [118530] trunk/Source/WebKit/blackberry
- Revision
- 118530
- Author
- [email protected]
- Date
- 2012-05-25 08:49:19 -0700 (Fri, 25 May 2012)
Log Message
[BlackBerry] History navigation caused google.com scale not kept
https://bugs.webkit.org/show_bug.cgi?id=87438
Reviewed by Antonio Gomes.
Patch by Jacky Jiang <[email protected]>
PR: 159923
For back/forward history navigation, we were trying to keep the values
set by dispatchViewportDataDidChange. However, when we went back from
the previous page, if the current page didn't contain the meta viewport
tag, then those values set by previous page would never be reset.
Although the current page could get correct saved scale when restoring
view state, the scale would still be clamped by zoomToFitScale which
was based on the virtual viewport of the previous page which could make
the scale incorrect.
Since we know the viewport arguments of the current document before
setLoadState on back/forward history navigation, we can reset these
previous values if the document doesn't have viewport arguments during
setLoadState.
* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::setLoadState):
Modified Paths
Diff
Modified: trunk/Source/WebKit/blackberry/Api/WebPage.cpp (118529 => 118530)
--- trunk/Source/WebKit/blackberry/Api/WebPage.cpp 2012-05-25 15:40:55 UTC (rev 118529)
+++ trunk/Source/WebKit/blackberry/Api/WebPage.cpp 2012-05-25 15:49:19 UTC (rev 118530)
@@ -898,11 +898,17 @@
m_virtualViewportHeight = m_defaultLayoutSize.height();
}
// Check if we have already process the meta viewport tag, this only happens on history navigation.
+ // For back/forward history navigation, we should only keep these previous values if the document
+ // has the meta viewport tag when the state is Committed in setLoadState.
// Refreshing should keep these previous values as well.
+ static ViewportArguments defaultViewportArguments;
+ bool documentHasViewportArguments = false;
FrameLoadType frameLoadType = FrameLoadTypeStandard;
+ if (m_mainFrame && m_mainFrame->document() && !(m_mainFrame->document()->viewportArguments() == defaultViewportArguments))
+ documentHasViewportArguments = true;
if (m_mainFrame && m_mainFrame->loader())
frameLoadType = m_mainFrame->loader()->loadType();
- if (!m_didRestoreFromPageCache && !(frameLoadType == FrameLoadTypeReload || frameLoadType == FrameLoadTypeReloadFromOrigin)) {
+ if (!((m_didRestoreFromPageCache && documentHasViewportArguments) || (frameLoadType == FrameLoadTypeReload || frameLoadType == FrameLoadTypeReloadFromOrigin))) {
m_viewportArguments = ViewportArguments();
// At the moment we commit a new load, set the viewport arguments
Modified: trunk/Source/WebKit/blackberry/ChangeLog (118529 => 118530)
--- trunk/Source/WebKit/blackberry/ChangeLog 2012-05-25 15:40:55 UTC (rev 118529)
+++ trunk/Source/WebKit/blackberry/ChangeLog 2012-05-25 15:49:19 UTC (rev 118530)
@@ -1,3 +1,28 @@
+2012-05-24 Jacky Jiang <[email protected]>
+
+ [BlackBerry] History navigation caused google.com scale not kept
+ https://bugs.webkit.org/show_bug.cgi?id=87438
+
+ Reviewed by Antonio Gomes.
+ Patch by Jacky Jiang <[email protected]>
+
+ PR: 159923
+ For back/forward history navigation, we were trying to keep the values
+ set by dispatchViewportDataDidChange. However, when we went back from
+ the previous page, if the current page didn't contain the meta viewport
+ tag, then those values set by previous page would never be reset.
+ Although the current page could get correct saved scale when restoring
+ view state, the scale would still be clamped by zoomToFitScale which
+ was based on the virtual viewport of the previous page which could make
+ the scale incorrect.
+ Since we know the viewport arguments of the current document before
+ setLoadState on back/forward history navigation, we can reset these
+ previous values if the document doesn't have viewport arguments during
+ setLoadState.
+
+ * Api/WebPage.cpp:
+ (BlackBerry::WebKit::WebPagePrivate::setLoadState):
+
2012-05-25 Mary Wu <[email protected]>
[BlackBerry] Pass http headers to loader in download request
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes
