Title: [111000] trunk/Source/WebKit/blackberry
- Revision
- 111000
- Author
- [email protected]
- Date
- 2012-03-16 06:35:37 -0700 (Fri, 16 Mar 2012)
Log Message
[BlackBerry] Can not open certain links from bridge applications
https://bugs.webkit.org/show_bug.cgi?id=81197
Patch by Robin Cao <[email protected]> on 2012-03-16
Reviewed by Rob Buis.
Currently, the engine asks the client to handle some type of requests externally.
But WebPageClient::handleStringPattern is not yet implemented and exposed to
the client. Before that, we still need to give the client a chance to decide
how to handle requests such as 'mailto:'.
To address this problem, r108763 introduced a change that ask the client to
decide how to handle the navigation in dispatchDecidePolicyForNewWindowAction().
This is not intuitive and will bring troubles, because this navigation will
happen in the new page. So the new page client is to decide how to handle
the navigation, not the old one.
This patch reverts r108763 and skips calling WebPageClient::handleStringPattern
since it's not implemented.
This way the new window action will continue, and the logic in
dispatchDecidePolicyForNavigationAction() will handle the navigation correctly.
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDecidePolicyForNewWindowAction):
(WebCore::FrameLoaderClientBlackBerry::decidePolicyForExternalLoad):
Modified Paths
Diff
Modified: trunk/Source/WebKit/blackberry/ChangeLog (110999 => 111000)
--- trunk/Source/WebKit/blackberry/ChangeLog 2012-03-16 13:34:46 UTC (rev 110999)
+++ trunk/Source/WebKit/blackberry/ChangeLog 2012-03-16 13:35:37 UTC (rev 111000)
@@ -1,3 +1,31 @@
+2012-03-16 Robin Cao <[email protected]>
+
+ [BlackBerry] Can not open certain links from bridge applications
+ https://bugs.webkit.org/show_bug.cgi?id=81197
+
+ Reviewed by Rob Buis.
+
+ Currently, the engine asks the client to handle some type of requests externally.
+ But WebPageClient::handleStringPattern is not yet implemented and exposed to
+ the client. Before that, we still need to give the client a chance to decide
+ how to handle requests such as 'mailto:'.
+
+ To address this problem, r108763 introduced a change that ask the client to
+ decide how to handle the navigation in dispatchDecidePolicyForNewWindowAction().
+ This is not intuitive and will bring troubles, because this navigation will
+ happen in the new page. So the new page client is to decide how to handle
+ the navigation, not the old one.
+
+ This patch reverts r108763 and skips calling WebPageClient::handleStringPattern
+ since it's not implemented.
+
+ This way the new window action will continue, and the logic in
+ dispatchDecidePolicyForNavigationAction() will handle the navigation correctly.
+
+ * WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
+ (WebCore::FrameLoaderClientBlackBerry::dispatchDecidePolicyForNewWindowAction):
+ (WebCore::FrameLoaderClientBlackBerry::decidePolicyForExternalLoad):
+
2012-03-16 Leo Yang <[email protected]>
[BlackBerry] Crash when going back from an xhtml document containing <img>
Modified: trunk/Source/WebKit/blackberry/WebCoreSupport/FrameLoaderClientBlackBerry.cpp (110999 => 111000)
--- trunk/Source/WebKit/blackberry/WebCoreSupport/FrameLoaderClientBlackBerry.cpp 2012-03-16 13:34:46 UTC (rev 110999)
+++ trunk/Source/WebKit/blackberry/WebCoreSupport/FrameLoaderClientBlackBerry.cpp 2012-03-16 13:35:37 UTC (rev 111000)
@@ -268,29 +268,13 @@
delayPolicyCheckUntilFragmentExists(fragment, function);
}
-void FrameLoaderClientBlackBerry::dispatchDecidePolicyForNewWindowAction(FramePolicyFunction function, const NavigationAction& action, const ResourceRequest& request, PassRefPtr<FormState>, const String& frameName)
+void FrameLoaderClientBlackBerry::dispatchDecidePolicyForNewWindowAction(FramePolicyFunction function, const NavigationAction&, const ResourceRequest& request, PassRefPtr<FormState>, const String& frameName)
{
if (request.isRequestedByPlugin() && ScriptController::processingUserGesture() && !m_webPagePrivate->m_pluginMayOpenNewTab)
(m_frame->loader()->policyChecker()->*function)(PolicyIgnore);
// A new window can never be a fragment scroll.
PolicyAction decision = decidePolicyForExternalLoad(request, false);
- // Let the client have a chance to say whether this navigation should
- // be ignored or not.
- BlackBerry::Platform::NetworkRequest platformRequest;
- request.initializePlatformRequest(platformRequest, false /*isInitial*/);
- if (isMainFrame() && !m_webPagePrivate->m_client->acceptNavigationRequest(
- platformRequest, BlackBerry::Platform::NavigationType(action.type()))) {
- if (action.type() == NavigationTypeFormSubmitted || action.type() == NavigationTypeFormResubmitted)
- m_frame->loader()->resetMultipleFormSubmissionProtection();
-
- if (action.type() == NavigationTypeLinkClicked && request.url().hasFragmentIdentifier()) {
- ResourceRequest emptyRequest;
- m_frame->loader()->activeDocumentLoader()->setLastCheckedRequest(emptyRequest);
- }
- decision = PolicyIgnore;
- }
-
(m_frame->loader()->policyChecker()->*function)(decision);
}
@@ -1077,12 +1061,18 @@
PolicyAction FrameLoaderClientBlackBerry::decidePolicyForExternalLoad(const ResourceRequest& request, bool isFragmentScroll)
{
+#if 0
+ // FIXME: Enable these commented out when WebPageClient::handleStringPattern is implemented
+ // and exposed to client. Before that, don't return PolicyIgnore so we can continue to
+ // create new window and get to dispatchDecidePolicyForNavigationAction() where the client
+ // is given a chance to decide how to handle patterns such as 'mailto:'.
const KURL& url = ""
String pattern = m_webPagePrivate->findPatternStringForUrl(url);
if (!pattern.isEmpty()) {
m_webPagePrivate->m_client->handleStringPattern(pattern.characters(), pattern.length());
return PolicyIgnore;
}
+#endif
if (m_webPagePrivate->m_webSettings->areLinksHandledExternally()
&& isMainFrame()
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes
