GitLab

https://bugs.webkit.org/show_bug.cgi?id=99327

Reviewed by Yong Li.
Patch by Antonio Gomes <agomes@rim.com>

Remove more unneeded BackingStoreClient <-> WebPageClient integration
methods:
- BackingStoreClient* backingStoreClientForFrame(...)
- void addBackingStoreClientForFrame(...)
- void removeBackingStoreClientForFrame(...)

Change places calling WPPriv::backingStoreClientForFrame to directly
access WPPriv::backingStoreClient instead, since only the main frame will
have a BackingStoreClient instance associated with it, and it is owned by
the WKPriv.

Remove non-mainframe only references to BackingStoreClient completely,
since it is dead code now.

* Api/InRegionScroller.cpp:
(BlackBerry::WebKit::InRegionScrollerPrivate::setLayerScrollPosition):
* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::backingStoreClient):
(BlackBerry::WebKit::WebPage::destroy):
* Api/WebPage_p.h:
(WebPagePrivate):
* WebCoreSupport/ChromeClientBlackBerry.cpp:
(WebCore::ChromeClientBlackBerry::invalidateContentsForSlowScroll):
(WebCore::ChromeClientBlackBerry::scroll):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::transitionToCommittedForNewPage):
(WebCore::FrameLoaderClientBlackBerry::createFrame):
(WebCore::FrameLoaderClientBlackBerry::detachedFromParent2):
* WebKitSupport/BackingStoreClient.cpp:
(BlackBerry::WebKit::BackingStoreClient::create):
(BlackBerry::WebKit::BackingStoreClient::BackingStoreClient):
(BlackBerry::WebKit::BackingStoreClient::~BackingStoreClient):
* WebKitSupport/BackingStoreClient.h:
(BackingStoreClient):
* WebKitSupport/InputHandler.cpp:
(BlackBerry::WebKit::InputHandler::setBatchEditingActive):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131314 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Code inside FrameLoaderClient::canShowMIMEType() implementations can be shared among different WK ports
https://bugs.webkit.org/show_bug.cgi?id=97547

Patch by Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com> on 2012-09-28
Reviewed by Adam Barth.

Source/WebCore:

Added MIMETypeRegistry::canShowMIMEType() function which should to be used
to detect whether a given MIME type can be shown in a page.

No new tests. No new functionality.

* WebCore.exp.in: Added MIMETypeRegistry::canShowMIMEType(). Removed MIMETypeRegistry functions that no longer need to be exported.
* platform/MIMETypeRegistry.cpp:
(WebCore::MIMETypeRegistry::canShowMIMEType):
(WebCore):
* platform/MIMETypeRegistry.h:
(MIMETypeRegistry):

Source/WebKit/blackberry:

Newly added WebCore::MIMETypeRegistry::canShowMIMEType() function is used
inside WebCore::FrameLoaderClientBlackBerry::canShowMIMEType().

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::canShowMIMEType):

Source/WebKit/efl:

Newly added WebCore::MIMETypeRegistry::canShowMIMEType() function is used
inside WebCore::FrameLoaderClientEfl::canShowMIMEType().

* WebCoreSupport/FrameLoaderClientEfl.cpp:
(WebCore::FrameLoaderClientEfl::canShowMIMEType):

Source/WebKit/gtk:

Newly added WebCore::MIMETypeRegistry::canShowMIMEType() function is used
inside WebKit::FrameLoaderClient::canShowMIMEType().

* WebCoreSupport/FrameLoaderClientGtk.cpp:
(WebKit::FrameLoaderClient::canShowMIMEType):

Source/WebKit/qt:

Newly added WebCore::MIMETypeRegistry::canShowMIMEType() function is used
inside WebCore::FrameLoaderClientQt::canShowMIMEType().

* WebCoreSupport/FrameLoaderClientQt.cpp:
(WebCore::FrameLoaderClientQt::canShowMIMEType):

Source/WebKit/wince:

Newly added WebCore::MIMETypeRegistry::canShowMIMEType() function is used
inside WebKit::FrameLoaderClientWinCE::canShowMIMEType().

* WebCoreSupport/FrameLoaderClientWinCE.cpp:
(WebKit::FrameLoaderClientWinCE::canShowMIMEType):

Source/WebKit2:

Newly added WebCore::MIMETypeRegistry::canShowMIMEType() function is used
inside WebKit::WebPageProxy::canShowMIMEType() and WKBundlePageCanShowMIMEType().

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::canShowMIMEType):
* WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
(WKBundlePageCanShowMIMEType):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129924 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=97076

Reviewed by George Staikos.

Invalid URLs in iframe src results in an empty URL in platform request, we should reject
such URL as early as we identify it.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDecidePolicyForNavigationAction):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129853 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=97718

Reviewed by Antonio Gomes.

After the last calling sites of blitContents() have
been removed or reworked, the actual method itself
can now retire. All blits now go through
blitVisibleContents(). The knowledge that we always
blit the full visible surface can facilitate further
optimizations; we will get to that in time.

* Api/BackingStore.cpp:
(BlackBerry::WebKit::BackingStorePrivate::suspendScreenAndBackingStoreUpdates):
(BlackBerry::WebKit::BackingStorePrivate::resumeScreenAndBackingStoreUpdates):
(BlackBerry::WebKit::BackingStorePrivate::blitVisibleContents):
* Api/BackingStore.h:
* Api/BackingStore_p.h:
(BackingStorePrivate):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::transitionToCommittedForNewPage):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129706 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Need to merge didFirstVisuallyNonEmptyLayout and 
didNewFirstVisuallyNonEmptyLayout
-and corresponding-
<rdar://problem/10791680>

Reviewed by Sam Weinig.

Source/WebCore: 

This patch merges didFirstLayout, didFirstVisuallyNonEmptyLayout, 
and didNewFirstVisuallyNonEmptyLayout. Page keeps track of which 
layout milestones we are interested in with a bit mask, so that 
different ports/clients can opt-into different milestones. This 
will allow us to safely add more layout milestones in the future 
if that seems worthwhile.

Include new file LayoutMilestoneOptions.h
* GNUmakefile.list.am:
* Target.pri:
* WebCore.exp.in:
* WebCore.gypi:
* WebCore.xcodeproj/project.pbxproj:

Remove dispatchDidFirstLayout, 
dispatchDidFirstVisuallyNonEmptyLayout, and 
dispatchDidNewFirstVisuallyNonEmptyLayout. They are now replaced 
by dispatchDidLayout(LayoutMilestoneOptions)
* loader/EmptyClients.h:
(WebCore::EmptyFrameLoaderClient::dispatchDidLayout):
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::didLayout):
* loader/FrameLoader.h:
(FrameLoader):
* loader/FrameLoaderClient.h:
(FrameLoaderClient):
(WebCore::FrameLoaderClient::dispatchDidLayout):
* page/LayoutMilestoneOptions.h: Added.
(WebCore):

Check with Page to find out which layout milestones the client is 
interested in, and then dispatch the notifications when 
appropriate.
* page/FrameView.cpp:
(WebCore::FrameView::performPostLayoutTasks):

Remove setRelevantRepaintedObjectsCounterThreshold(). Instead keep 
track of the layout milestones bit mask.
* page/Page.cpp:
(WebCore::Page::Page):
(WebCore::Page::addLayoutMilestones):
(WebCore):
(WebCore::Page::isCountingRelevantRepaintedObjects):
(WebCore::Page::addRelevantRepaintedObject):
* page/Page.h:
(Page):
(WebCore::Page::layoutMilestones):

Source/WebKit/blackberry: 

Remove dispatchDidFirstLayout, 
dispatchDidFirstVisuallyNonEmptyLayout, and 
dispatchDidNewFirstVisuallyNonEmptyLayout. Their functionality 
is now replaced by dispatchDidLayout(LayoutMilestoneOptions)
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidLayout):
* WebCoreSupport/FrameLoaderClientBlackBerry.h:
(FrameLoaderClientBlackBerry):

It is now necessary to opt into getting any of the 
"layout milestone" notifications.
* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::init):

Source/WebKit/chromium: 

Remove dispatchDidFirstLayout, 
dispatchDidFirstVisuallyNonEmptyLayout, and 
dispatchDidNewFirstVisuallyNonEmptyLayout. Their functionality 
is now replaced by dispatchDidLayout(LayoutMilestoneOptions)
* src/FrameLoaderClientImpl.cpp:
(WebKit::FrameLoaderClientImpl::dispatchDidLayout):
* src/FrameLoaderClientImpl.h:
(FrameLoaderClientImpl):

It is now necessary to opt into getting any of the 
"layout milestone" notifications.
* src/WebHelperPluginImpl.cpp:
(WebKit::WebHelperPluginImpl::initPage):
* src/WebPagePopupImpl.cpp:
(WebKit::WebPagePopupImpl::initPage):
* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::WebViewImpl):

Source/WebKit/efl: 

Remove dispatchDidFirstLayout, 
dispatchDidFirstVisuallyNonEmptyLayout, and 
dispatchDidNewFirstVisuallyNonEmptyLayout. Their functionality 
is now replaced by dispatchDidLayout(LayoutMilestoneOptions)
* WebCoreSupport/FrameLoaderClientEfl.cpp:
(WebCore::FrameLoaderClientEfl::dispatchDidLayout):
* WebCoreSupport/FrameLoaderClientEfl.h:
(FrameLoaderClientEfl):

It is now necessary to opt into getting any of the 
"layout milestone" notifications.
* ewk/ewk_view.cpp:
(_ewk_view_priv_new):

Source/WebKit/gtk: 

Remove dispatchDidFirstLayout, 
dispatchDidFirstVisuallyNonEmptyLayout, and 
dispatchDidNewFirstVisuallyNonEmptyLayout. Their functionality 
is now replaced by dispatchDidLayout(LayoutMilestoneOptions)
* WebCoreSupport/FrameLoaderClientGtk.cpp:
(WebKit::FrameLoaderClient::dispatchDidLayout):
* WebCoreSupport/FrameLoaderClientGtk.h:
(FrameLoaderClient):

It is now necessary to opt into getting any of the 
"layout milestone" notifications.
* webkit/webkitwebview.cpp:
(webkit_web_view_init):

Source/WebKit/mac: 

The new API has two parts. First, the client has to opt into which 
layout milestones they are interested in hearing about using 
[WebView _layoutMilestones]. Then, WebKit will call 
the WebFrameLoader delegate's didLayout(WebLayoutMilestones) 
callback when the specified layout milestones have fired. 
didLayout takes the WebLayoutMilestones bit mask, which will 
indicate which milestones have fired since it is possible for two 
to fire at the same time.

Remove dispatchDidFirstLayout, 
dispatchDidFirstVisuallyNonEmptyLayout, and 
dispatchDidNewFirstVisuallyNonEmptyLayout. They are now replaced 
by dispatchDidLayout(LayoutMilestones)
* WebCoreSupport/WebFrameLoaderClient.h:
(WebFrameLoaderClient):
* WebCoreSupport/WebFrameLoaderClient.mm:
(WebFrameLoaderClient::dispatchDidLayout):

Add new function to the delegate for didLayout.
* WebView/WebDelegateImplementationCaching.h:
(WebFrameLoadDelegateImplementationCache):

We need a delegate template that takes an NSUInteger.
* WebView/WebDelegateImplementationCaching.mm:
(CallDelegate):
(CallFrameLoadDelegate):

Convert between WebCore and WebKit versions of the bit mask.
* WebView/WebView.mm:
(coreLayoutMilestones):
(kitLayoutMilestones):

Add new delegate, and set the appropriate layout milestones in 
WebCore based on old delegates having implementations.
(-[WebView _cacheFrameLoadDelegateImplementations]):

Call into WebCore.
(-[WebView _listenForLayoutMilestones:]):
(-[WebView _layoutMilestones]):
* WebView/WebViewInternal.h:
* WebView/WebViewPrivate.h:

Source/WebKit/qt: 

Remove dispatchDidFirstLayout, 
dispatchDidFirstVisuallyNonEmptyLayout, and 
dispatchDidNewFirstVisuallyNonEmptyLayout. Their functionality 
is now replaced by dispatchDidLayout(LayoutMilestoneOptions)
* WebCoreSupport/FrameLoaderClientQt.cpp:
(WebCore::FrameLoaderClientQt::dispatchDidLayout):
* WebCoreSupport/FrameLoaderClientQt.h:
(FrameLoaderClientQt):

It is now necessary to opt into getting any of the 
"layout milestone" notifications.
* Api/qwebpage.cpp:
(QWebPagePrivate::QWebPagePrivate):

Source/WebKit/win: 

Remove dispatchDidFirstLayout, 
dispatchDidFirstVisuallyNonEmptyLayout, and 
dispatchDidNewFirstVisuallyNonEmptyLayout. Their functionality 
is now replaced by dispatchDidLayout(LayoutMilestoneOptions)
* WebCoreSupport/WebFrameLoaderClient.cpp:
(WebFrameLoaderClient::dispatchDidLayout):
* WebCoreSupport/WebFrameLoaderClient.h:
(WebFrameLoaderClient):

It is now necessary to opt into getting any of the 
"layout milestone" notifications.
* WebView.cpp:
(WebView::initWithFrame):

Source/WebKit/wince: 

Remove dispatchDidFirstLayout, 
dispatchDidFirstVisuallyNonEmptyLayout, and 
dispatchDidNewFirstVisuallyNonEmptyLayout. Their functionality 
is now replaced by dispatchDidLayout(LayoutMilestones)
* WebCoreSupport/FrameLoaderClientWinCE.cpp:
(WebKit::FrameLoaderClientWinCE::dispatchDidLayout):
* WebCoreSupport/FrameLoaderClientWinCE.h:
(FrameLoaderClientWinCE):

Source/WebKit/wx: 

Remove dispatchDidFirstLayout, 
dispatchDidFirstVisuallyNonEmptyLayout, and 
dispatchDidNewFirstVisuallyNonEmptyLayout. Their functionality 
is now replaced by dispatchDidLayout(LayoutMilestones)
* WebKitSupport/FrameLoaderClientWx.cpp:
(WebCore::FrameLoaderClientWx::dispatchDidLayout):
* WebKitSupport/FrameLoaderClientWx.h:
(FrameLoaderClientWx):

Source/WebKit2: 

The new API has two parts. First, the client has to opt into which 
layout milestones they are interested in hearing about using 
WKPageListenForLayoutMilestones or 
WKBundlePageListenForLayoutMilestones(). Then, WebKit will call 
the didLayout(WKLayoutMilestones) callback on the appropriate 
clients when the specified layout milestones have fired. didLayout 
takes the WKLayoutMilestones bit mask, which will indicate which 
milestones have fired since it is possible for two to fire at the 
same time.

Define WKLayoutMilestoneOptions.
* Shared/API/c/WKPageLoadTypes.h:

Define conversions between WKLayoutMilestoneOptions and 
WebCore::LayoutMilestoneOptions
* Shared/API/c/WKSharedAPICast.h:
(WebKit::toWKLayoutMilestoneOptions):
(WebKit):
(WebKit::toLayoutMilestoneOptions):

New API.
* UIProcess/API/C/WKPage.cpp:
(WKPageListenForLayoutMilestones):
* UIProcess/API/C/WKPage.h:
* UIProcess/WebLoaderClient.cpp:
(WebKit::WebLoaderClient::didLayout):
(WebKit):
* UIProcess/WebLoaderClient.h:
(WebLoaderClient):

didFirstLayoutForFrame, didFirstVisuallyNonEmptyLayoutForFrame, 
and didNewFirstVisuallyNonEmptyLayout are now implemented with 
didLayout under the hood. So if those old callbacks have been 
defined, be sure to add the appropriate layout milestones here for 
backwards-compatibility.
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::initializeLoaderClient):

New API.
(WebKit::WebPageProxy::listenForLayoutMilestones):
(WebKit):
(WebKit::WebPageProxy::didLayout):
* UIProcess/WebPageProxy.h:
(WebPageProxy):
* UIProcess/WebPageProxy.messages.in:

New API. And remove the now-unnecessary 
WKBundlePageSetPaintedObjectsCounterThreshold. 
* WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
(WKBundlePageListenForLayoutMilestones):
* WebProcess/InjectedBundle/API/c/WKBundlePage.h:
* WebProcess/InjectedBundle/API/c/WKBundlePagePrivate.h:

New API.
* WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.cpp:
(WebKit::InjectedBundlePageLoaderClient::didNewFirstVisuallyNonEmptyLayout):
(WebKit):
(WebKit::InjectedBundlePageLoaderClient::didLayout):
* WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.h:
(InjectedBundlePageLoaderClient):

Remove dispatchDidFirstLayout, 
dispatchDidFirstVisuallyNonEmptyLayout, and 
dispatchDidNewFirstVisuallyNonEmptyLayout. They are now replaced 
by dispatchDidLayout(LayoutMilestoneOptions)
* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::dispatchDidLayout):
* WebProcess/WebCoreSupport/WebFrameLoaderClient.h:
(WebFrameLoaderClient):

didFirstLayoutForFrame, didFirstVisuallyNonEmptyLayoutForFrame, 
and didNewFirstVisuallyNonEmptyLayout are now implemented with 
didLayout under the hood. So if those old callbacks have been 
defined, be sure to add the appropriate layout milestones here for 
backwards-compatibility.
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::initializeInjectedBundleLoaderClient):
(WebKit):

Call into WebCore to set the layout milestones.
(WebKit::WebPage::listenForLayoutMilestones):
* WebProcess/WebPage/WebPage.h:
(WebPage):
* WebProcess/WebPage/WebPage.messages.in:

Account for the new member of PageLoadClient.
* WebProcess/qt/QtBuiltinBundlePage.cpp:
(WebKit::QtBuiltinBundlePage::QtBuiltinBundlePage):

Tools: 

Account for the new member of the PageLoadClient.
* MiniBrowser/mac/BrowserWindowController.m:
(-[BrowserWindowController awakeFromNib]):
* WebKitTestRunner/InjectedBundle/InjectedBundlePage.cpp:
(WTR::InjectedBundlePage::InjectedBundlePage):
* WebKitTestRunner/TestController.cpp:
(WTR::TestController::initialize):

The NewFirstVisuallyNonEmptyLayoutForImages has existed for a while, 
but it did not have the right target membership.
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:

Use new didLayout API instead of old 
didNewFirstVisuallyNonEmptyLayout API.
* TestWebKitAPI/Tests/WebKit2/NewFirstVisuallyNonEmptyLayout.cpp:
(TestWebKitAPI):
(TestWebKitAPI::didLayout):
(TestWebKitAPI::setPageLoaderClient):
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WebKit2/NewFirstVisuallyNonEmptyLayoutFails.cpp:
(TestWebKitAPI):
(TestWebKitAPI::didLayout):
(TestWebKitAPI::setPageLoaderClient):
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WebKit2/NewFirstVisuallyNonEmptyLayoutForImages.cpp:
(TestWebKitAPI):
(TestWebKitAPI::didLayout):
(TestWebKitAPI::setPageLoaderClient):
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WebKit2/NewFirstVisuallyNonEmptyLayoutFrames.cpp:
(TestWebKitAPI):
(TestWebKitAPI::didLayout):
(TestWebKitAPI::setPageLoaderClient):
(TestWebKitAPI::TEST):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129545 268f45cc-cd09-0410-ab3c-d52691b4dbfc

[BlackBerry] Basic authentication challenge credentials for stored credentials again after restarting browser
https://bugs.webkit.org/show_bug.cgi?id=96362

Patch by Sean Wang <Xuewen.Wang@torchmobile.com.cn> on 2012-09-19
Reviewed by Rob Buis.

Source/WebCore:

This patch enable reading credentials from the persistent credential storage
when it is not private browsing mode and there is not a credential in the RAM
for the requested resource.

Since we don't load persistent stored credentials into RAM at the starting time,
even we have saved the credentials at the last browsing, after restarting the browser,
it will still challenge for credentials for the requesting resources.

No new tests, it uses the original authentication tests. There is no way to
clear all credentials or restarting browsers to test this feature.

* platform/network/blackberry/CredentialBackingStore.cpp:
(WebCore::CredentialBackingStore::getProtectionSpace):
(WebCore):
* platform/network/blackberry/CredentialBackingStore.h:
(CredentialBackingStore):
* platform/network/blackberry/NetworkManager.cpp:
(WebCore::NetworkManager::startJob):

Source/WebKit/blackberry:

Make the FrameLoaderClient use credential storage according to the macro
BLACKBERRY_CREDENTIAL_PERSIST

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::shouldUseCredentialStorage):
(WebCore):
* WebCoreSupport/FrameLoaderClientBlackBerry.h:
(FrameLoaderClientBlackBerry):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129087 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=97099

Patch by Jonathan Dong <jonathan.dong@torchmobile.com.cn> on 2012-09-19
Reviewed by Yong Li.

Source/WebCore:

Added function playerID() in class PageClientBlackBerry.

Internally reviewed by Charles Wei.

No new tests since there's no functional change.

* platform/blackberry/PageClientBlackBerry.h:

Source/WebKit/blackberry:

Implemented PageClientBlackBerry::playerID() in class WebPagePrivate,
and replaced the implementation of FrameLoaderClientBlackBerry::playerId().

Internally reviewed by Charles Wei.

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::playerID):
(WebKit):
* Api/WebPage_p.h:
(WebPagePrivate):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::playerId):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129010 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=96410

Reviewed by Rob Buis.

Fix how history navigation handles restoring view state when navigating between error pages.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::FrameLoaderClientBlackBerry):
(WebCore::FrameLoaderClientBlackBerry::saveViewStateToItem):
(WebCore::FrameLoaderClientBlackBerry::restoreViewState):
* WebCoreSupport/FrameLoaderClientBlackBerry.h:
(FrameLoaderClientBlackBerry):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128211 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=95870

Reviewed by George Staikos.
Reviewed internally by Jacky Jiang.

Use the new zoom to fit scale if the page was zoomed to fit initial scale
When a page is reloaded the layout size may be changed. So the contents
size on which the initial scale depends may be changed. Use the new initial
scale in this case to make sure the page will be zoomed to correct scale.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::restoreViewState):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127628 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=95766

Reviewed by Rob Buis.

Passing the frame status through will allow the client to make better
decisions about how to act on the onload.

* Api/WebPageClient.h:
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidHandleOnloadEvents):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127489 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=94621

Patch by Benjamin C Meyer <bmeyer@rim.com> on 2012-08-21
Reviewed by Yong Li.

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPage::enableQnxJavaScriptObject):
(WebKit):
(BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
* Api/WebPage.h:
* Api/WebPage_p.h:
(WebPagePrivate):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidClearWindowObjectInWorld):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126232 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=94123

Reviewed by Antonio Gomes.

Reviewed internally by Leo Yang, Jacky Jiang.
PR 178305

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::setLoadState):Reset the scales and
the user scalable flag if we're reloading from an error page.
(BlackBerry::WebKit::WebPagePrivate::updateViewportSize): Don't update the
viewport size if we're still in the WebPagePrivate::init method.
(BlackBerry::WebKit::WebPagePrivate::zoomToInitialScaleOnLoad):
Properly set the shouldZoom flag if we're not going to restore the
view state.
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::FrameLoaderClientBlackBerry):
(WebCore::FrameLoaderClientBlackBerry::dispatchDidCommitLoad): Set the
ViewState's shouldSaveViewState flag if we're coming from an error page.
(WebCore::FrameLoaderClientBlackBerry::saveViewStateToItem): Set the
new member variable m_shouldRestoreViewState based on the ViewState's
shouldSaveViewState flag.
(WebCore::FrameLoaderClientBlackBerry::restoreViewState): Added early
return if m_shouldRestoreViewState is false.
* WebCoreSupport/FrameLoaderClientBlackBerry.h: Add new method to have
the client track whether we should restore the view state.
(WebCore::FrameLoaderClientBlackBerry::shouldRestoreViewState):
(FrameLoaderClientBlackBerry):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125803 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=94139

Patch by Yong Li <yoli@rim.com> on 2012-08-15
Reviewed by Antonio Gomes.

Keep same security origin when a file URL automatically redirects to its child folder.
This patch will be reverted when we finish the better solution.
PR# 172333 and PR# 180590.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::FrameLoaderClientBlackBerry):
(WebCore::FrameLoaderClientBlackBerry::dispatchDidStartProvisionalLoad):
(WebCore::FrameLoaderClientBlackBerry::securityOriginForNewDocument):
(WebCore):
* WebCoreSupport/FrameLoaderClientBlackBerry.h:
(FrameLoaderClientBlackBerry):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125714 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=94018

Patch by Leo Yang <leoyang@rim.com> on 2012-08-14
Reviewed by Yong Li.
Reviewed internally by Yong Li.

The backing store need to be suspended before the
WebPagePrivate::restoreHistoryViewState() is called to avoid UI thread
drawing checkerboard.

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::restoreHistoryViewState):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::restoreViewState):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125611 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=93283

Reviewed by Eric Seidel.

Source/WebCore:

Chromium has a refptr that needs to be NULLed at this point.

The approach is to change the client redirectDataToPlugin method(s) to expect
the possibility of a NULL argument, and the use this to clear the refptr on
the chromium platform.  Other platforms can merely ignore the NULL case, thereby
maintaining the existing behaviour.

Formal testing is nearly impossible without some chrome-specific plugins.

* html/PluginDocument.cpp:
(WebCore::PluginDocument::detach):

Source/WebKit/blackberry:

Change the client redirectDataToPlugin method(s) to expect the possibility of
a NULL argument, keeping existing behaviour otherwise.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::redirectDataToPlugin):

Source/WebKit/chromium:

Change the client redirectDataToPlugin method(s) to expect the possibility of
a NULL argument, NULLing Chromium's refptr that needs to be NULLed.

* src/FrameLoaderClientImpl.cpp:
(WebKit::FrameLoaderClientImpl::redirectDataToPlugin):

Source/WebKit/efl:

Change the client redirectDataToPlugin method(s) to expect the possibility of
a NULL argument, keeping existing behaviour otherwise.

* WebCoreSupport/FrameLoaderClientEfl.cpp:
(WebCore::FrameLoaderClientEfl::redirectDataToPlugin):

Source/WebKit/gtk:

Change the client redirectDataToPlugin method(s) to expect the possibility of
a NULL argument, keeping existing behaviour otherwise.

* WebCoreSupport/FrameLoaderClientGtk.cpp:
(WebKit::FrameLoaderClient::redirectDataToPlugin):

Source/WebKit/qt:

Change the client redirectDataToPlugin method(s) to expect the possibility of
a NULL argument, keeping existing behaviour otherwise.

* WebCoreSupport/FrameLoaderClientQt.cpp:
(WebCore::FrameLoaderClientQt::redirectDataToPlugin):

Source/WebKit/win:

Change the client redirectDataToPlugin method(s) to expect the possibility of
a NULL argument, keeping existing behaviour otherwise.

* WebCoreSupport/WebFrameLoaderClient.cpp:
(WebFrameLoaderClient::redirectDataToPlugin):

Source/WebKit/wince:

Change the client redirectDataToPlugin method(s) to expect the possibility of
a NULL argument, keeping existing behaviour otherwise.

* WebCoreSupport/FrameLoaderClientWinCE.cpp:
(WebKit::FrameLoaderClientWinCE::redirectDataToPlugin):

Source/WebKit/wx:

Chromium has a refptr that needs to be NULLed at this point.

Change the client redirectDataToPlugin method(s) to expect the possibility of
a NULL argument, keeping existing behaviour otherwise.

* WebKitSupport/FrameLoaderClientWx.cpp:
(WebCore::FrameLoaderClientWx::redirectDataToPlugin):

Source/WebKit2:

Chromium has a refptr that needs to be NULLed at this point.

Change the client redirectDataToPlugin method(s) to expect the possibility of
a NULL argument, keeping existing behaviour otherwise.

* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::redirectDataToPlugin):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125500 268f45cc-cd09-0410-ab3c-d52691b4dbfc

[BlackBerry] always set PolicyAction to PolicyIgnore if the chrome returns false for acceptNavigationRequest
https://bugs.webkit.org/show_bug.cgi?id=93251

Reviewed by George Staikos.

In acceptNavigationRequest(), webkit will ask if the chrome will accept the navigation request.
We will take this chance to see if the request is an internal-webkit protocol, otherwise,
we will try to launch an external application to handle the request, and ask webkit to ignore
the request by returning false in acceptNavigationRequest().

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDecidePolicyForNavigationAction):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124982 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=93383

Reviewed by Rob Buis.

Base64 moved from platform/text to wtf/text, need to add mssing
include.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124911 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=93141

Patch by Yong Li <yoli@rim.com> on 2012-08-03
Reviewed by Rob Buis.

PR# 172041.
It is not always safe to render the page at this point. So we post a message
instead.

* Api/WebPage.cpp:
(WebKit):
(BlackBerry::WebKit::WebPagePrivate::restoreHistoryViewState):
* Api/WebPage_p.h:
(WebPagePrivate):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::restoreViewState):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124643 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=92857

Reviewed by George Staikos.

The current implementation just passes the internal of SkPixels data to the client,
which can't be passed accross the process boundary to chrome for processing.
This patch makes the favicon Base64 encoded so that can be passed to chrome in another process.

* Api/WebPageClient.h:
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidReceiveIcon):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124403 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=92233

Patch by Jonathan Dong <jonathan.dong@torchmobile.com.cn> on 2012-07-25
Reviewed by Rob Buis.

Handle URL scheme "rtsp://" before creating the DocumentLoader
and send the request to webkit. As we don't have any application
which can deal with rtsp invocation for now, we need to create
a media document to wrap the rtsp url within a video tag which
makes it load as a normal video clip.

RIM PR: 169669
Internally reviewed by Charles Wei <charles.wei@torchmobile.com.cn>.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::createDocumentLoader):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123693 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=92153
RIM PR 173340

Reviewed by Antonio Gomes.

In dispatchDidFirstVisualLayout() and repaint() in
immediate mode, we render but don't notify the
WebPageClient that the content was modified.

In the long run, we should probably keep track of
the modified reason from within render() itself
and use this to automatically notify the client
from within blitContents() and/or invalidateWindow(),
depending on the rendering path. That's somewhat of
a medium-size undertaking though; for now, adding
the call directly to the renderVisibleContents()
call sites will do.

This patch also adds a blitVisibleContents() to
dispatchDidFirstVisualLayout() where it was
inexplicably missing, probably on account of
old code that was never updated.

* Api/BackingStore.cpp:
(BlackBerry::WebKit::BackingStorePrivate::repaint):
* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::resumeBackingStore):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidFirstVisuallyNonEmptyLayout):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123610 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=91541

Patch by Yong Li <yoli@rim.com> on 2012-07-23
Reviewed by Rob Buis.

PR# 181304.
Move about: URL handling to the right place (FrameLoaderClientBlackBerry::createDocumentLoader), so
reload and history navigation can work.
Other changes: Remove about:version which makes little sense. Make about:memory partially visible.

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPage::load): Remove the call to loadAbout()
* Api/WebPage_p.h: Remove loadAbout()
(WebPagePrivate):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::createDocumentLoader): Construct about: data here.
* WebKitSupport/AboutData.cpp:
(BlackBerry::WebKit::numberToHTMLTr): Make it static
(BlackBerry::WebKit::configPage): Make it static
(BlackBerry::WebKit::memoryPage): Make it static
(BlackBerry::WebKit::cachePage):
(BlackBerry::WebKit::buildPage):
(BlackBerry::WebKit::creditsPage):
(BlackBerry::WebKit::cookiePage):
(BlackBerry::WebKit::aboutData): The only export function that returns HTML source for a given about: URL.
(WebKit):
* WebKitSupport/AboutData.h:
(WebKit):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123391 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=91808

Reviewed by George Staikos.

When go back/forward, if the page was in page cache, it would have no chance
to send favicon. So we'll send it in commitLoad right after send the blank
icon.
RIM PR# 177495

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidCommitLoad):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123179 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=91644
RIM PR 174365

Reviewed by Adam Treat and Antonio Gomes.

We expose suspendScreenAndBackingStoreUpdates() to the
outside API, but also use it internally when reacting
to a number of happenings, i.e. zooming, viewport resize,
resetting view state on Committed state or when restoring
it from previous pages, etc.

These two can clash. For instance, if we get a suspend
call from outside that suspends us for app inactivity,
or we are told to suspend because the main target surface
is not available at the time, and while being suspended
we try to rotate, finish loading a page, the we'll end up
resuming operations even though we shouldn't.

This patch changes the suspend flag to be a counter
instead, allowing nested suspend/resume calls and making
suspend/resume more robust this way. It also changes
several call sites to make sure suspend/resume calls are
paired up correctly.

* Api/BackingStore.cpp:
(BlackBerry::WebKit::BackingStorePrivate::BackingStorePrivate):
(BlackBerry::WebKit::BackingStorePrivate::suspendScreenAndBackingStoreUpdates):
(BlackBerry::WebKit::BackingStorePrivate::resumeScreenAndBackingStoreUpdates):
* Api/BackingStore_p.h:
(BackingStorePrivate):
* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::shouldZoomAboutPoint):
(BlackBerry::WebKit::WebPagePrivate::zoomAboutPointTimerFired):
(BlackBerry::WebKit::WebPagePrivate::blockZoomRectForNode):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::restoreViewState):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123129 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=91162

Reviewed by Adam Barth.

Source/WebCore:

No new tests. Files moving only.

* CMakeLists.txt:
* GNUmakefile.list.am:
* Modules/websockets/WebSocketHandshake.cpp:
(WebCore::generateSecWebSocketKey):
(WebCore::WebSocketHandshake::getExpectedWebSocketAccept):
* Target.pri:
* WebCore.gypi:
* WebCore.order:
* WebCore.vcproj/WebCore.vcproj:
* WebCore.xcodeproj/project.pbxproj:
* fileapi/FileReaderLoader.cpp:
(WebCore::FileReaderLoader::convertToDataURL):
* inspector/DOMPatchSupport.cpp:
(WebCore::DOMPatchSupport::createDigest):
* inspector/InspectorFileSystemAgent.cpp:
(WebCore):
* inspector/InspectorPageAgent.cpp:
(WebCore::InspectorPageAgent::cachedResourceContent):
(WebCore::InspectorPageAgent::sharedBufferContent):
* loader/archive/mhtml/MHTMLArchive.cpp:
(WebCore::MHTMLArchive::generateMHTMLData):
* loader/archive/mhtml/MHTMLParser.cpp:
(WebCore::MHTMLParser::parseNextPart):
* page/DOMWindow.cpp:
(WebCore::DOMWindow::btoa):
(WebCore::DOMWindow::atob):
* page/Page.cpp:
(WebCore::Page::userStyleSheetLocationChanged):
* platform/graphics/cairo/ImageBufferCairo.cpp:
(WebCore::ImageBuffer::toDataURL):
* platform/graphics/cg/ImageBufferCG.cpp:
(WebCore::CGImageToDataURL):
* platform/graphics/gtk/ImageBufferGtk.cpp:
(WebCore::ImageBuffer::toDataURL):
* platform/graphics/skia/FontCustomPlatformData.cpp:
(WebCore::createUniqueFontName):
* platform/graphics/skia/ImageBufferSkia.cpp:
(WebCore::ImageBuffer::toDataURL):
(WebCore::ImageDataToDataURL):
* platform/graphics/win/FontCustomPlatformData.cpp:
(WebCore::createUniqueFontName):
* platform/graphics/wince/FontCustomPlatformData.cpp:
(WebCore::createUniqueFontName):
* platform/graphics/wince/ImageBufferWinCE.cpp:
* platform/graphics/wx/ImageBufferWx.cpp:
* platform/network/DataURL.cpp:
(WebCore::handleDataURL):
* platform/network/cf/ResourceHandleCFNet.cpp:
(WebCore::applyBasicAuthorizationHeader):
* platform/network/mac/ResourceHandleMac.mm:
(WebCore::applyBasicAuthorizationHeader):
* platform/network/soup/ResourceHandleSoup.cpp:
* platform/win/SSLKeyGeneratorWin.cpp:
(WebCore::WebCore::signedPublicKeyAndChallengeString):

Source/WebKit/blackberry:

* Api/WebKitTextCodec.cpp:
(BlackBerry::WebKit::base64DecodePolicyForWTF):
(BlackBerry::WebKit::base64Decode):
(BlackBerry::WebKit::base64EncodePolicyForWTF):
(BlackBerry::WebKit::base64Encode):
* Api/WebSettings.cpp:
(BlackBerry::WebKit::WebSettings::setUserStyleSheetString):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:

Source/WTF:

* GNUmakefile.list.am:
* WTF.gypi:
* WTF.pro:
* WTF.vcproj/WTF.vcproj:
* WTF.xcodeproj/project.pbxproj:
* wtf/CMakeLists.txt:
* wtf/text/Base64.cpp: Renamed from Source/WebCore/platform/text/Base64.cpp.
(WTF):
(WTF::base64Encode):
(WTF::base64Decode):
(WTF::base64DecodeInternal):
* wtf/text/Base64.h: Renamed from Source/WebCore/platform/text/Base64.h.
(WTF):
(WTF::base64Encode):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122652 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=91247

Reviewed by Antonio Gomes.
Patch by Jacky Jiang <zhajiang@rim.com>

PR: 175432
On yahoo.com, the web page stopped zooming while trying to pinch as
WebPageClient::resetBitmapZoomScale(double) was being called by
WebPagePrivate::zoomToInitialScaleOnLoad() after load finished.
And also yahoo.com was keeping updating layout, which made it really
bad that zoomToInitialScaleOnLoad() was called many times when load
finished and the load type was FrameLoadTypeStandard or FrameLoadTypeSame.
As we only care about the situation that dispatchDidFirstVisuallyNonEmptyLayout()
happens after load finished, we can move the code to that method and
set a flag for WebPage layoutFinished() and zoomToInitialScaleOnLoad()
instead. In this way, we can ensure that the flag is only enabled when
dispatchDidFirstVisuallyNonEmptyLayout() is called after load finished
and get rid of calling zoomToInitialScaleOnLoad() lots of times when
keeping updating layout in such kind of situation.

Internally reviewed by Arvid Nilsson

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
(BlackBerry::WebKit::WebPagePrivate::setLoadState):
(BlackBerry::WebKit::WebPagePrivate::layoutFinished):
* Api/WebPage_p.h:
(BlackBerry::WebKit::WebPagePrivate::shouldZoomToInitialScaleOnLoad):
(BlackBerry::WebKit::WebPagePrivate::setShouldZoomToInitialScaleAfterLoadFinished):
(WebPagePrivate):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidFirstVisuallyNonEmptyLayout):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122589 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=67582

Reviewed by David Levin.

Source/WebCore:

Added a new synchronous method to the IconDatabase that returns a
native image for the platform instead of a WebCore::Image*.

* loader/icon/IconDatabase.cpp:
(WebCore::IconDatabase::synchronousNativeIconForPageURL):
(WebCore):
* loader/icon/IconDatabase.h:
(IconDatabase):
* loader/icon/IconDatabaseBase.h:
(WebCore::IconDatabaseBase::synchronousNativeIconForPageURL):
(IconDatabaseBase):

Source/WebKit/blackberry:

Use synchronousNativeIconForPageURL() to retrieve favicons.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidReceiveIcon):

Source/WebKit/cf:

Fixes windows build.

* WebCoreSupport/WebInspectorClientCF.cpp:

Source/WebKit/efl:

Use synchronousNativeIconForPageURL() to retrieve favicons.

* ewk/ewk_history.cpp:
(ewk_history_item_icon_surface_get):
(ewk_history_item_icon_object_add):
* ewk/ewk_settings.cpp:
(ewk_settings_icon_database_icon_surface_get):
(ewk_settings_icon_database_icon_object_add):

Source/WebKit/gtk:

Use synchronousNativeIconForPageURL() to retrieve favicons.

* webkit/webkitfavicondatabase.cpp:
(getIconPixbufSynchronously):

Source/WebKit/qt:

Use synchronousNativeIconForPageURL() to retrieve favicons.

* Api/qwebhistory.cpp:
(QWebHistoryItem::icon):
* Api/qwebsettings.cpp:
(QWebSettings::iconForUrl):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@120694 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=89091

Reviewed by Rob Buis.

Add check before clean pluginView in FrameLoaderBlackBerry in case
it didn't have any content.
RIM PR# 165336
Reviewed internally by George Staikos

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::finishedLoading):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@120399 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=88889

Reviewed by Adam Treat.
Patch by Jacky Jiang <zhajiang@rim.com>

PR: 164442
When we were reloading a web page with the load type FrameLoadTypeSame
after the initial load, the first layout timer was fired after the load
Finished state, in which case the web page would have no chance to zoom
to the initial scale during the layout as it was only for load
Committed state. This patch takes care of it.

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::layoutFinished):
(BlackBerry::WebKit::WebPagePrivate::shouldZoomToInitialScaleOnLoad):
(WebKit):
(BlackBerry::WebKit::WebPagePrivate::zoomToInitialScaleOnLoad):
* Api/WebPage_p.h:
(WebPagePrivate):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidFirstVisuallyNonEmptyLayout):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@120124 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=85577

Patch by Jonathan Dong <jonathan.dong@torchmobile.com.cn> on 2012-06-11
Reviewed by Rob Buis.

Remove the autofill saving procedure out of dispatchWillSubmitForm, this procedure
is same as the procedure in dispatchWillSendSubmitEvent.
Some sites will redirect to other url in its login process, which will cause the
user get notified to save credentials for this provisional redirecting url if we
put this saving procedure in dispatchWillSubmitForm. So we should remove it to make
sure we only save the autofill data before the submit event is fired.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchWillSubmitForm):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@120022 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=88513

Patch by Jonathan Dong <jonathan.dong@torchmobile.com.cn> on 2012-06-07
Reviewed by Rob Buis.

RIM PR: #163391
Implemented credential autofill setting and form autofill setting.

Internally reviewed by Leo Yang <leo.yang@torchmobile.com.cn>.

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPage::autofillTextField):
(BlackBerry::WebKit::WebPagePrivate::authenticationChallenge):
(BlackBerry::WebKit::WebPage::clearCredentials):
(BlackBerry::WebKit::WebPage::clearAutofillData):
(BlackBerry::WebKit::WebPage::clearNeverRememberSites):
* Api/WebSettings.cpp:
(WebKit):
(BlackBerry::WebKit::WebSettings::standardSettings):
(BlackBerry::WebKit::WebSettings::isCredentialAutofillEnabled):
(BlackBerry::WebKit::WebSettings::setCredentialAutofillEnabled):
(BlackBerry::WebKit::WebSettings::isFormAutofillEnabled):
(BlackBerry::WebKit::WebSettings::setFormAutofillEnabled):
* Api/WebSettings.h:
* WebCoreSupport/EditorClientBlackBerry.cpp:
(WebCore::EditorClientBlackBerry::textFieldDidEndEditing):
(WebCore::EditorClientBlackBerry::textDidChangeInTextField):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDidFinishLoad):
(WebCore::FrameLoaderClientBlackBerry::dispatchWillSubmitForm):
(WebCore::FrameLoaderClientBlackBerry::dispatchWillSendSubmitEvent):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@119713 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=87116

Patch by Chris Guan <chris.guan@torchmobile.com.cn> on 2012-05-22
Reviewed by George Staikos.

There is not any reason to disable pageCache for video/audio
tags probably. By my testing, Back and Forward are working for
those pages contain video and audio tags.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::canCachePage):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@118109 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=85577

Patch by Jonathan Dong <jonathan.dong@torchmobile.com.cn> on 2012-05-09
Reviewed by Rob Buis.

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPage::autofillTextField): Added this interface
function to auto fill the inputting text field when user selects
a autofill candidate value from autofill context dialog.
(WebKit):
(BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
(BlackBerry::WebKit::WebPagePrivate::notifyPopupAutofillDialog): Added
this interface function to notify WebPageClient to pop up the autofill
context dialog with the suggested input items.
(BlackBerry::WebKit::WebPage::clearAutofillData):
* Api/WebPage.h:
* Api/WebPageClient.h:
* Api/WebPage_p.h:
(WebCore):
(WebPagePrivate):
* WebCoreSupport/AutofillManager.cpp:
(WebCore::AutofillManager::didChangeInTextField):
* WebCoreSupport/EditorClientBlackBerry.cpp:
(WebCore::EditorClientBlackBerry::textDidChangeInTextField): Implemented
this function to listen to the notification of text field change, and
notify AutofillManager to handle the autofill.
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchWillSubmitForm):
(WebCore::FrameLoaderClientBlackBerry::dispatchWillSendSubmitEvent):
Save the name and value pair of every autofillable input text field when
user submitting a form.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116603 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=84559

Patch by Chris Guan <chris.guan@torchmobile.com.cn> on 2012-05-08
Reviewed by Antonio Gomes.

Source/WebCore:

ResourceRequest is a network level abstraction, and it should
not know anything about web concepts such as plug-ins, and Blackberry
does not need m_isRequestedByPlugin any longer, So clean up all related
code.

Tested on a website of http://edition.cnn.com, a new window should be
opened only when user has a singe tap gesture on a plugin element.

* platform/network/blackberry/ResourceRequest.h:
(WebCore::ResourceRequest::ResourceRequest):
(ResourceRequest):
(CrossThreadResourceRequestData):
* platform/network/blackberry/ResourceRequestBlackBerry.cpp:
(WebCore::ResourceRequest::doPlatformCopyData):
(WebCore::ResourceRequest::doPlatformAdopt):

Source/WebKit/blackberry:

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchDecidePolicyForNewWindowAction):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116418 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=85044

Reviewed by Antonio Gomes.

Source/WebCore:

Pass download attribute filename to networkJob and it could be
overridden by the Content-Disposition HTTP header's filename parameter.

* platform/network/blackberry/NetworkJob.cpp:
(WebCore::NetworkJob::initialize):
* platform/network/blackberry/ResourceRequest.h:
(WebCore::ResourceRequest::setSuggestSaveName):
(WebCore::ResourceRequest::suggestSaveName):
(ResourceRequest):
* platform/network/blackberry/ResourceRequestBlackBerry.cpp:
(WebCore::ResourceRequest::initializePlatformRequest):

Source/WebKit/blackberry:

If a link has download attribute, we should pass that value and be able to
save file with the name according to HTML5:
http://updates.html5rocks.com/2011/08/Downloading-resources-in-HTML5-a-download

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::load):
(BlackBerry::WebKit::WebPage::download):
* Api/WebPage_p.h:
(WebPagePrivate):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::startDownload):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116265 268f45cc-cd09-0410-ab3c-d52691b4dbfc

[BlackBerry] Rendering bmp file as text file when Content-Type:image/x-ms-bmp from apache web server.
https://bugs.webkit.org/show_bug.cgi?id=85036

Reviewed by Antonio Gomes.

Source/WebCore:

Move getNormalizedMIMEType from WebKit into MIMETypeRegistry. This way we support uncommon mime types like image/pjpeg
and image/x-ms-bmp out of the box since we map to the more common image/jpeg and image/bmp respectively.

* platform/MIMETypeRegistry.cpp:
(WebCore::initializeSupportedImageMIMETypes):
(WebCore::MIMETypeRegistry::isSupportedImageMIMEType):
(WebCore::MIMETypeRegistry::isSupportedImageResourceMIMEType):
(WebCore):
(WebCore::mimeTypeAssociationMap):
(WebCore::MIMETypeRegistry::getNormalizedMIMEType):
* platform/MIMETypeRegistry.h:
(MIMETypeRegistry):

Source/WebKit/blackberry:

Move getNormalizedMIMEType into WebCore::MIMETypeRegistry.

* Api/WebSettings.cpp:
(WebKit):
(BlackBerry::WebKit::WebSettings::isSupportedObjectMIMEType):
* Api/WebSettings.h:
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::createPlugin):
(WebCore::FrameLoaderClientBlackBerry::canShowMIMEType):
(WebCore::FrameLoaderClientBlackBerry::objectContentType):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116145 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=85533

Reviewed by Alexey Proskuryakov.

Source/WebKit/blackberry:

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::finishedLoading):

Source/WebKit/chromium:

* src/FrameLoaderClientImpl.cpp:
(WebKit::FrameLoaderClientImpl::FrameLoaderClientImpl):
(WebKit):
(WebKit::FrameLoaderClientImpl::finishedLoading):
* src/FrameLoaderClientImpl.h:
(WebKit::FrameLoaderClientImpl::makeRepresentation):
(WebKit::FrameLoaderClientImpl::revertToProvisionalState):
(FrameLoaderClientImpl):

Source/WebKit/efl:

* WebCoreSupport/FrameLoaderClientEfl.cpp:
(WebCore::FrameLoaderClientEfl::FrameLoaderClientEfl):
(WebCore):
(WebCore::FrameLoaderClientEfl::finishedLoading):
* WebCoreSupport/FrameLoaderClientEfl.h:
(WebCore::FrameLoaderClientEfl::makeRepresentation):
(WebCore::FrameLoaderClientEfl::revertToProvisionalState):
(FrameLoaderClientEfl):

Source/WebKit/gtk:

* WebCoreSupport/FrameLoaderClientGtk.cpp:
(WebKit::FrameLoaderClient::FrameLoaderClient):
(WebKit):
(WebKit::FrameLoaderClient::finishedLoading):
* WebCoreSupport/FrameLoaderClientGtk.h:
(WebKit::FrameLoaderClient::makeRepresentation):
(WebKit::FrameLoaderClient::revertToProvisionalState):
(FrameLoaderClient):

Source/WebKit/mac:

* WebView/WebHTMLRepresentation.mm:
(-[WebHTMLRepresentation finishedLoadingWithDataSource:]): Calling commitData when finishing is no longer necessary,
    as WebCore will take care of simulating the receipt of data and ensuring the requisite work gets done in the blank document case.

Source/WebKit/qt:

* WebCoreSupport/FrameLoaderClientQt.cpp:
(WebCore::FrameLoaderClientQt::FrameLoaderClientQt):
(WebCore):
(WebCore::FrameLoaderClientQt::finishedLoading):
* WebCoreSupport/FrameLoaderClientQt.h:
(WebCore::FrameLoaderClientQt::makeRepresentation):
(WebCore::FrameLoaderClientQt::revertToProvisionalState):
(FrameLoaderClientQt):

Source/WebKit/win:

* WebCoreSupport/WebFrameLoaderClient.cpp:
(WebFrameLoaderClient::finishedLoading):

Source/WebKit/wince:

* WebCoreSupport/FrameLoaderClientWinCE.cpp:
(WebKit::FrameLoaderClientWinCE::finishedLoading):

Source/WebKit/wx:

* WebKitSupport/FrameLoaderClientWx.cpp:
(WebCore::FrameLoaderClientWx::finishedLoading):
(WebCore::FrameLoaderClientWx::setMainDocumentError):
(WebCore::FrameLoaderClientWx::dispatchDidReceiveResponse):
(WebCore::FrameLoaderClientWx::dispatchDidFailLoading):
* WebKitSupport/FrameLoaderClientWx.h:
(FrameLoaderClientWx):

Source/WebKit2:

* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::finishedLoading):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116121 268f45cc-cd09-0410-ab3c-d52691b4dbfc

information about the form being submitted
https://bugs.webkit.org/show_bug.cgi?id=84297

Reviewed by Andy Estes.

Source/WebCore:

* html/HTMLFormElement.cpp:
(WebCore::HTMLFormElement::prepareForSubmission):
Get the form field names and values, and use them to create a FormState
object. Pass this object when calling dispatchWillSendSubmitEvent().
(WebCore::HTMLFormElement::getTextFieldValues):
Loop over the associated elements, looking for <input> elements.
Collect their names and values.

* html/HTMLFormElement.h:
Declare getTextFieldData().

* loader/EmptyClients.h:
(WebCore::EmptyFrameLoaderClient::dispatchWillSendSubmitEvent):
Updated declaration for new parameter type.

* loader/FrameLoaderClient.h:
Updated declaration of dispatchWillSendSubmitEvent() for new param
type.

Source/WebKit/blackberry:

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::dispatchWillSendSubmitEvent):
Updated to use the FormState.

* WebCoreSupport/FrameLoaderClientBlackBerry.h:
(FrameLoaderClientBlackBerry):
Updated method declaration.

Source/WebKit/chromium:

* src/FrameLoaderClientImpl.cpp:
(WebKit::FrameLoaderClientImpl::dispatchWillSendSubmitEvent):
Updated to use the FormState.

* src/FrameLoaderClientImpl.h:
(FrameLoaderClientImpl):
Updated method declaration.

Source/WebKit/efl:

* WebCoreSupport/FrameLoaderClientEfl.h:
(WebCore::FrameLoaderClientEfl::dispatchWillSendSubmitEvent):
Updated method declaration.

Source/WebKit/gtk:

* WebCoreSupport/FrameLoaderClientGtk.h:
(WebKit::FrameLoaderClient::dispatchWillSendSubmitEvent):
Updated method declaration.

Source/WebKit/mac:

* WebCoreSupport/WebFrameLoaderClient.h:
Updated method declaration.

Source/WebKit/qt:

* WebCoreSupport/FrameLoaderClientQt.h:
(WebCore::FrameLoaderClientQt::dispatchWillSendSubmitEvent):
Updated method declaration.

Source/WebKit/win:

* WebFrame.h:
Fix function stub for new parameter.

Source/WebKit/wince:

* WebCoreSupport/FrameLoaderClientWinCE.h:
(WebKit::FrameLoaderClientWinCE::dispatchWillSendSubmitEvent):
Updated method declaration.

Source/WebKit/wx:

* WebKitSupport/FrameLoaderClientWx.h:
(WebCore::FrameLoaderClientWx::dispatchWillSendSubmitEvent):
Updated method declaration.

Source/WebKit2:

* WebProcess/WebCoreSupport/WebFrameLoaderClient.h:
(WebFrameLoaderClient):
Updated method declaration.

* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebFrameLoaderClient::willSendSubmitEvent):
Stubbed.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@115926 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=84862

Patch by Yong Li <yoli@rim.com> on 2012-04-25
Reviewed by Antonio Gomes.

1. block UI events when running in nested event loop
2. defer some tasks we still want to perform when it is safe to do,
   with cached data.
3. deferred task can be cancelled by clearing the flag. duplicate tasks
   is not a problem because they share same flag and data.
4. move deferred manual script from FrameLoaderClientBlackBerry to WebPagePrivate
   and make it a deferred task

* Api/WebPage.cpp:
(WebKit):
(BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
(BlackBerry::WebKit::WebPagePrivate::load):
(BlackBerry::WebKit::WebPagePrivate::stopCurrentLoad):
(BlackBerry::WebKit::WebPagePrivate::willDeferLoading):
(BlackBerry::WebKit::WebPagePrivate::didResumeLoading):
(BlackBerry::WebKit::WebPagePrivate::deferredTasksTimerFired):
(BlackBerry::WebKit::WebPage::assignFocus):
(BlackBerry::WebKit::WebPagePrivate::setPageVisibilityState):
(BlackBerry::WebKit::WebPage::setInputSelection):
(BlackBerry::WebKit::WebPage::popupListClosed):
(BlackBerry::WebKit::WebPage::setDateTimeInput):
(BlackBerry::WebKit::WebPage::setColorInput):
(BlackBerry::WebKit::WebPage::mouseEvent):
(BlackBerry::WebKit::WebPage::touchEvent):
(BlackBerry::WebKit::WebPage::touchPointAsMouseEvent):
(BlackBerry::WebKit::WebPage::touchEventCancel):
(BlackBerry::WebKit::WebPage::touchEventCancelAndClearFocusedNode):
(BlackBerry::WebKit::WebPage::keyEvent):
(BlackBerry::WebKit::WebPage::deleteTextRelativeToCursor):
(BlackBerry::WebKit::WebPage::setComposingText):
(BlackBerry::WebKit::WebPage::commitText):
(BlackBerry::WebKit::WebPage::selectionCancelled):
(BlackBerry::WebKit::WebPage::cutSelectedText):
(BlackBerry::WebKit::WebPage::insertText):
(BlackBerry::WebKit::WebPage::clearCurrentInputField):
(BlackBerry::WebKit::WebPage::cut):
(BlackBerry::WebKit::WebPage::paste):
(BlackBerry::WebKit::WebPage::setSelection):
(BlackBerry::WebKit::WebPage::setCaretPosition):
(BlackBerry::WebKit::WebPage::selectAtPoint):
(BlackBerry::WebKit::WebPage::setFocused):
* Api/WebPage.h:
* Api/WebPage_p.h:
(WebCore):
(WebPagePrivate):
(DeferredTaskBase):
(BlackBerry::WebKit::WebPagePrivate::DeferredTaskBase::perform):
(BlackBerry::WebKit::WebPagePrivate::DeferredTaskBase::DeferredTaskBase):
* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::FrameLoaderClientBlackBerry):
(WebCore::FrameLoaderClientBlackBerry::~FrameLoaderClientBlackBerry):
(WebCore::FrameLoaderClientBlackBerry::willDeferLoading):
(WebCore::FrameLoaderClientBlackBerry::didResumeLoading):
* WebCoreSupport/FrameLoaderClientBlackBerry.h:
(FrameLoaderClientBlackBerry):
* WebKitSupport/InputHandler.cpp:
(BlackBerry::WebKit::InputHandler::setPopupListIndexes):
* WebKitSupport/InputHandler.h:
(InputHandler):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@115245 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=84535

Use the existing PluginDatabase to query for the plugins we can handle.

The original implemention of FrameLoaderClientBlackBerry::createPlugin
was a partial copy from another port.  In the Qt port there is some
workarounds for flash which is why this exists there.  Sadly the bits
that were copied made it so only flash worked, but as flash was the only
plugin on the system this issue was not noticed until QNX tried to get
jnext working.  Tracing it down to this bit of code rather then
correcting it they hardcoded the jnext into the same block as flash was.

The blackberry port isn't specifically suppose to only allow jnext and
flash, but was an accident due to the way this code was developed.

Patch by Benjamin C Meyer <bmeyer@rim.com> on 2012-04-21
Reviewed by Adam Treat.

* WebCoreSupport/FrameLoaderClientBlackBerry.cpp:
(WebCore::FrameLoaderClientBlackBerry::createPlugin):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@114849 268f45cc-cd09-0410-ab3c-d52691b4dbfc