1. 15 Oct, 2012 1 commit
    • tonikitoo@webkit.org's avatar
      [BlackBerry] Clean up BackingStoreClient (part II) · ae434975
      tonikitoo@webkit.org authored
      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
      ae434975
  2. 13 Oct, 2012 1 commit
    • jpetsovits@rim.com's avatar
      [BlackBerry] Fetch blit rects from a viewport accessor · 7d0e6131
      jpetsovits@rim.com authored
      https://bugs.webkit.org/show_bug.cgi?id=98581
      RIM PR 173292
      
      Reviewed by George Staikos.
      Internally reviewed by Arvid Nilsson.
      
      Source/WebKit:
      
      Add new ViewportAccessor files to the build.
      See Source/WebKit/blackberry/ChangeLog for the
      verbose commit message.
      
      * PlatformBlackBerry.cmake:
      
      Source/WebKit/blackberry:
      
      The long-standing userInterfaceBlittedVisibleContentsRect()
      method in WebPageClient has long been a major annoyance,
      as it returns the source rect for WebKit contents but in
      backingstore pixel coordinates. This makes it not only
      unwieldy but also terribly fragile, especially when
      both pinch zoom and a backingstore re-render both deal
      with the same rectangle. On different threads, even.
      
      BlackBerry::Platform now exposes a ViewportAccessor
      interface, which can be used to get the various rects
      in document coordinates or target pixel coordinates,
      both being a better choice than the ones dependent
      on an implentation detail.
      
      This commit makes use of this new functionality.
      Instead of relying on the passed rectangle to contain
      implicit information about the scale factor, we now
      track the scale of each backingstore geometry by making
      a snapshot of the current WebKit-thread scale when the
      geometry is generated. Once the geometry is swapped to
      the front, we can then calculate the remaining
      backingstore-to-viewport transformation in a threadsafe
      way. We now only calculate this if we actually blit from
      backingstore tiles and don't go through a configuration
      of pure accelerated compositing.
      
      As a result, we are now a lot more robust against
      synchonization issues related to backingstore
      geometry changes. As an additional gimmick, the scale
      is also stored with each tile buffer to doubly secure
      that a tile rendered in one scale is not transferred
      to a different geometry and then rendered there without
      being rerendered at the new scale, even if the rendered
      pixel coordinates are still the same.
      
      Having per-geometry scale information also opens up
      opportunities to further improve backingstore rendering
      later. For instance, we could pre-render a low-res
      version of the page onto one buffer and combine that one
      with a higher-res array of tiles covering a smaller area.
      Or we could steal some tiles from the front geometry to
      render them at a new scale while a pinch-zoom operation
      is in progress.
      
      No such thing is implemented in this patch though.
      
      In adapting/fixing the backingstore visualization
      debug mode and the default background painting in
      renderDirectToWindow(), we also introduce new
      ViewportAccessor subclasses that can subsequently
      be used to replace methods from WebPage and elsewhere.
      
      * Api/BackingStore.cpp:
      (BlackBerry::WebKit::BackingStorePrivate::slowScroll):
      (BlackBerry::WebKit::BackingStorePrivate::scroll):
      (BlackBerry::WebKit::BackingStorePrivate::setBackingStoreRect):
      (BlackBerry::WebKit::BackingStorePrivate::scrollBackingStore):
      (BlackBerry::WebKit::BackingStorePrivate::renderDirectToWindow):
      (BlackBerry::WebKit::BackingStorePrivate::render):
      (BlackBerry::WebKit::BackingStorePrivate::paintDefaultBackground):
      (BlackBerry::WebKit::BackingStorePrivate::blitVisibleContents):
      (BlackBerry::WebKit::BackingStorePrivate::blitHorizontalScrollbar):
      (BlackBerry::WebKit::BackingStorePrivate::blitVerticalScrollbar):
      (BlackBerry::WebKit::BackingStorePrivate::updateTilesForScrollOrNotRenderedRegion):
      (BlackBerry::WebKit::BackingStorePrivate::updateTileMatrixIfNeeded):
      (BlackBerry::WebKit::BackingStorePrivate::orientationChanged):
      (BlackBerry::WebKit::BackingStorePrivate::createSurfaces):
      (BlackBerry::WebKit::BackingStorePrivate::invalidateWindow):
      * Api/BackingStore_p.h:
      (BlackBerry):
      (Platform):
      (BlackBerry::WebKit::BackingStoreGeometry::BackingStoreGeometry):
      (BlackBerry::WebKit::BackingStoreGeometry::scale):
      (BlackBerry::WebKit::BackingStoreGeometry::setScale):
      (BackingStoreGeometry):
      (BackingStorePrivate):
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::~WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::init):
      (BlackBerry::WebKit::WebPage::webkitThreadViewportAccessor):
      (WebKit):
      * Api/WebPage.h:
      (Platform):
      * Api/WebPageClient.h:
      (Platform):
      * Api/WebPageCompositor.cpp:
      (BlackBerry::WebKit::WebPageCompositorPrivate::animationFrameChanged):
      * Api/WebPage_p.h:
      (WebKit):
      (WebPagePrivate):
      * WebKitSupport/BackingStoreTile.cpp:
      (BlackBerry::WebKit::TileBuffer::TileBuffer):
      (BlackBerry::WebKit::TileBuffer::isRendered):
      * WebKitSupport/BackingStoreTile.h:
      (TileBuffer):
      (BlackBerry::WebKit::TileBuffer::scale):
      (BlackBerry::WebKit::TileBuffer::setScale):
      * WebKitSupport/BackingStoreVisualizationViewportAccessor.cpp: Added.
      (WebKit):
      (BlackBerry::WebKit::BackingStoreVisualizationViewportAccessor::BackingStoreVisualizationViewportAccessor):
      (BlackBerry::WebKit::BackingStoreVisualizationViewportAccessor::pixelContentsSize):
      (BlackBerry::WebKit::BackingStoreVisualizationViewportAccessor::documentContentsSize):
      (BlackBerry::WebKit::BackingStoreVisualizationViewportAccessor::pixelScrollPosition):
      (BlackBerry::WebKit::BackingStoreVisualizationViewportAccessor::documentScrollPosition):
      (BlackBerry::WebKit::BackingStoreVisualizationViewportAccessor::pixelViewportSize):
      (BlackBerry::WebKit::BackingStoreVisualizationViewportAccessor::documentViewportSize):
      (BlackBerry::WebKit::BackingStoreVisualizationViewportAccessor::destinationSurfaceOffset):
      (BlackBerry::WebKit::BackingStoreVisualizationViewportAccessor::scale):
      (BlackBerry::WebKit::BackingStoreVisualizationViewportAccessor::state):
      * WebKitSupport/BackingStoreVisualizationViewportAccessor.h: Added.
      (BlackBerry):
      (Platform):
      (WebKit):
      (BackingStoreVisualizationViewportAccessor):
      (BlackBerry::WebKit::BackingStoreVisualizationViewportAccessor::~BackingStoreVisualizationViewportAccessor):
      * WebKitSupport/WebKitThreadViewportAccessor.cpp: Added.
      (WebKit):
      (BlackBerry::WebKit::WebKitThreadViewportAccessor::WebKitThreadViewportAccessor):
      (BlackBerry::WebKit::WebKitThreadViewportAccessor::pixelContentsSize):
      (BlackBerry::WebKit::WebKitThreadViewportAccessor::documentContentsSize):
      (BlackBerry::WebKit::WebKitThreadViewportAccessor::pixelScrollPosition):
      (BlackBerry::WebKit::WebKitThreadViewportAccessor::documentScrollPosition):
      (BlackBerry::WebKit::WebKitThreadViewportAccessor::pixelViewportSize):
      (BlackBerry::WebKit::WebKitThreadViewportAccessor::documentViewportSize):
      (BlackBerry::WebKit::WebKitThreadViewportAccessor::destinationSurfaceOffset):
      (BlackBerry::WebKit::WebKitThreadViewportAccessor::scale):
      * WebKitSupport/WebKitThreadViewportAccessor.h: Added.
      (BlackBerry):
      (Platform):
      (WebKit):
      (WebKitThreadViewportAccessor):
      (BlackBerry::WebKit::WebKitThreadViewportAccessor::~WebKitThreadViewportAccessor):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131257 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7d0e6131
  3. 10 Oct, 2012 1 commit
    • commit-queue@webkit.org's avatar
      [BlackBerry] Fix assertion in NetworkJob::notifyChallengeResult. · 5d361657
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=97397
      Internal PR: 186597.
      
      Internally reviewed by Yong Li, Joe Mason.
      Patch by Lianghui Chen <liachen@rim.com> on 2012-10-10
      Reviewed by George Staikos.
      
      Source/WebCore:
      
      Add a singleton AuthenticationChallengeManager to manage authentication
      challenge dialog. It does following things:
      Record page creation/deletion, so it knows what page is present or not.
      Record page visibility change so it knows when to display a dialog or not.
      Accept authentication challenge, and decide whether to postpone the
          challenge dialog based on whether there is active authentication challenge
          dialog already and whether its page is visible or not.
      When a challenge result comes back, notify the result to all clients
          authenticating for the same protection space, and then start the next
          authentication challenge from the same page, if there is one.
      When a page becomes visible, start the first authentication challenge
          dialog that has been blocked before.
      When an authentication challenge is requested, the NetworkJob will be
          deferred so its initial response will be saved while waiting for
          user decision on the challenge.
      
      No new tests for platform specific internal change.
      
      * PlatformBlackBerry.cmake:
      * platform/blackberry/AuthenticationChallengeManager.cpp: Added.
      (WebCore):
      (ChallengeInfo):
      (WebCore::ChallengeInfo::ChallengeInfo):
      (AuthenticationChallengeManagerPrivate):
      (WebCore::AuthenticationChallengeManagerPrivate::AuthenticationChallengeManagerPrivate):
      (WebCore::AuthenticationChallengeManagerPrivate::resumeAuthenticationChallenge):
      (WebCore::AuthenticationChallengeManagerPrivate::startAuthenticationChallenge):
      (WebCore::AuthenticationChallengeManagerPrivate::pageExists):
      (WebCore::AuthenticationChallengeManager::AuthenticationChallengeManager):
      (WebCore::AuthenticationChallengeManager::pageCreated):
      (WebCore::AuthenticationChallengeManager::pageDeleted):
      (WebCore::AuthenticationChallengeManager::pageVisibilityChanged):
      (WebCore::AuthenticationChallengeManager::authenticationChallenge):
      (WebCore::AuthenticationChallengeManager::cancelAuthenticationChallenge):
      (WebCore::AuthenticationChallengeManager::notifyChallengeResult):
      (WebCore::AuthenticationChallengeManager::instance):
      (WebCore::AuthenticationChallengeManager::init):
      * platform/blackberry/AuthenticationChallengeManager.h:
      (WebCore):
      (AuthenticationChallengeManager):
      * platform/blackberry/PageClientBlackBerry.h:
      * platform/graphics/blackberry/MediaPlayerPrivateBlackBerry.cpp:
      (WebCore::MediaPlayerPrivate::MediaPlayerPrivate):
      (WebCore::MediaPlayerPrivate::~MediaPlayerPrivate):
      (WebCore::MediaPlayerPrivate::onAuthenticationNeeded):
      (WebCore::MediaPlayerPrivate::notifyChallengeResult):
      * platform/graphics/blackberry/MediaPlayerPrivateBlackBerry.h:
      (MediaPlayerPrivate):
      * platform/network/blackberry/NetworkJob.cpp:
      (WebCore::NetworkJob::NetworkJob):
      (WebCore::NetworkJob::~NetworkJob):
      (WebCore):
      (WebCore::NetworkJob::handleNotifyStatusReceived):
      (WebCore::NetworkJob::handleNotifyClose):
      (WebCore::NetworkJob::shouldReleaseClientResource):
      (WebCore::NetworkJob::sendRequestWithCredentials):
      (WebCore::NetworkJob::notifyChallengeResult):
      * platform/network/blackberry/NetworkJob.h:
      (NetworkJob):
      
      Source/WebKit/blackberry:
      
      Update WebPage to use new AuthenticationChallengeManager.
      Register page creation/deletion and visibility change to the new
          AuthenticationChallengeManager.
      Initialize AuthenticationChallengeManager in GlobalInitialize() function.
      
      * Api/BlackBerryGlobal.cpp:
      (BlackBerry::WebKit::globalInitialize):
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::~WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::authenticationChallenge):
      (BlackBerry::WebKit::WebPage::setVisible):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131014 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5d361657
  4. 05 Oct, 2012 1 commit
    • tonikitoo@webkit.org's avatar
      [BlackBerry] Find a proper fix for the... · 7bca18f4
      tonikitoo@webkit.org authored
      [BlackBerry] Find a proper fix for the WebPagePrivate::enqueueRenderingOfClippedContentOfScrollableNodeAfterInRegionScrolling hack
      https://bugs.webkit.org/show_bug.cgi?id=98517
      PR #137382
      
      Reviewed by Yong Li.
      Patch by Antonio Gomes <agomes@rim.com>
      
      We've generalized composited in-region scrolling, originally only applicable
      to block elements, to inner frames (see PR #197093). Past that, we no longer
      need to force repaints of offscreen areas when we finish scrolling, since translating
      the Layer takes care of properly invalidating it. Thus, remove this method.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::notifyInRegionScrollStopped):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130501 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7bca18f4
  5. 04 Oct, 2012 1 commit
    • simon.fraser@apple.com's avatar
      Final part of "sync" to "flush" renaming · df44c011
      simon.fraser@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=98430
      
      Reviewed by Tim Horton.
      
      Change method names on GraphicsLayer and GraphicsLayerClient that
      refer to "sync" to use the term "flush" instead, to be consistent
      with the rest of the code.
      
      Source/WebCore:
      
      * platform/graphics/GraphicsLayer.h:
      (WebCore::GraphicsLayer::flushCompositingState):
      (WebCore::GraphicsLayer::flushCompositingStateForThisLayerOnly):
      * platform/graphics/GraphicsLayerClient.h:
      (GraphicsLayerClient):
      * platform/graphics/blackberry/GraphicsLayerBlackBerry.h:
      (WebCore::GraphicsLayerBlackBerry::notifyFlushRequired):
      * platform/graphics/blackberry/LayerWebKitThread.cpp:
      (WebCore::LayerWebKitThread::setNeedsCommit):
      * platform/graphics/ca/GraphicsLayerCA.cpp:
      (WebCore::GraphicsLayerCA::flushCompositingState):
      (WebCore::GraphicsLayerCA::flushCompositingStateForThisLayerOnly):
      (WebCore::GraphicsLayerCA::platformCALayerDidCreateTiles):
      (WebCore::GraphicsLayerCA::positionForCloneRootLayer):
      (WebCore::GraphicsLayerCA::noteLayerPropertyChanged):
      * platform/graphics/ca/GraphicsLayerCA.h:
      (GraphicsLayerCA):
      * platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:
      (WebCore::GraphicsLayerTextureMapper::notifyChange):
      (WebCore::GraphicsLayerTextureMapper::flushCompositingStateForThisLayerOnly):
      (WebCore::GraphicsLayerTextureMapper::flushCompositingState):
      * platform/graphics/texmap/GraphicsLayerTextureMapper.h:
      (GraphicsLayerTextureMapper):
      * platform/graphics/texmap/TextureMapperLayer.cpp:
      (WebCore::TextureMapperLayer::flushCompositingState):
      (WebCore::TextureMapperLayer::flushCompositingStateSelf):
      * platform/graphics/texmap/TextureMapperLayer.h:
      (TextureMapperLayer):
      * rendering/RenderLayerBacking.cpp:
      (WebCore::RenderLayerBacking::notifyFlushRequired):
      * rendering/RenderLayerBacking.h:
      (RenderLayerBacking):
      * rendering/RenderLayerCompositor.cpp:
      (WebCore::RenderLayerCompositor::flushPendingLayerChanges):
      * rendering/RenderLayerCompositor.h:
      (WebCore::RenderLayerCompositor::notifyFlushRequired):
      
      Source/WebKit/blackberry:
      
      * Api/WebOverlay.cpp:
      (BlackBerry::WebKit::WebOverlayPrivateWebKitThread::notifyFlushRequired):
      * Api/WebOverlay_p.h:
      (WebOverlayPrivateWebKitThread):
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::notifyFlushRequired):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebKitSupport/DefaultTapHighlight.cpp:
      (BlackBerry::WebKit::DefaultTapHighlight::notifyFlushRequired):
      * WebKitSupport/DefaultTapHighlight.h:
      (DefaultTapHighlight):
      * WebKitSupport/InspectorOverlayBlackBerry.cpp:
      (BlackBerry::WebKit::InspectorOverlay::notifyFlushRequired):
      * WebKitSupport/InspectorOverlayBlackBerry.h:
      (InspectorOverlay):
      * WebKitSupport/SelectionOverlay.cpp:
      (BlackBerry::WebKit::SelectionOverlay::notifyFlushRequired):
      * WebKitSupport/SelectionOverlay.h:
      (SelectionOverlay):
      
      Source/WebKit/efl:
      
      * WebCoreSupport/AcceleratedCompositingContextEfl.cpp:
      (WebCore::AcceleratedCompositingContext::syncLayersNow):
      (WebCore::AcceleratedCompositingContext::attachRootGraphicsLayer):
      
      Source/WebKit/gtk:
      
      * WebCoreSupport/AcceleratedCompositingContext.h:
      (AcceleratedCompositingContext):
      * WebCoreSupport/AcceleratedCompositingContextCairo.cpp:
      (WebKit::AcceleratedCompositingContext::attachRootGraphicsLayer):
      (WebKit::AcceleratedCompositingContext::resizeRootLayer):
      (WebKit::AcceleratedCompositingContext::syncLayersNow):
      (WebKit::AcceleratedCompositingContext::notifyFlushRequired):
      * WebCoreSupport/AcceleratedCompositingContextClutter.cpp:
      (WebKit::AcceleratedCompositingContext::flushPendingLayerChanges):
      (WebKit::AcceleratedCompositingContext::notifyFlushRequired):
      * WebCoreSupport/AcceleratedCompositingContextGL.cpp:
      (WebKit::AcceleratedCompositingContext::flushPendingLayerChanges):
      (WebKit::AcceleratedCompositingContext::notifyFlushRequired):
      
      Source/WebKit/mac:
      
      * WebView/WebView.mm:
      
      Source/WebKit/qt:
      
      * WebCoreSupport/PageClientQt.cpp:
      (WebCore::TextureMapperLayerClientQt::syncRootLayer):
      
      Source/WebKit/win:
      
      * WebView.cpp:
      (WebView::notifyFlushRequired):
      (WebView::flushPendingGraphicsLayerChanges):
      * WebView.h:
      
      Source/WebKit2:
      
      * UIProcess/CoordinatedGraphics/LayerTreeRenderer.cpp:
      (WebKit::LayerTreeRenderer::paintToCurrentGLContext):
      (WebKit::LayerTreeRenderer::flushLayerChanges):
      * UIProcess/CoordinatedGraphics/LayerTreeRenderer.h:
      (WebKit::LayerTreeRenderer::notifyFlushRequired):
      * WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.cpp:
      (WebCore::CoordinatedGraphicsLayer::didChangeLayerState):
      (WebCore::CoordinatedGraphicsLayer::didChangeAnimatedProperties):
      (WebCore::CoordinatedGraphicsLayer::didChangeChildren):
      (WebCore::CoordinatedGraphicsLayer::didChangeFilters):
      (WebCore::CoordinatedGraphicsLayer::setContentsNeedsDisplay):
      (WebCore::CoordinatedGraphicsLayer::setContentsToCanvas):
      (WebCore::CoordinatedGraphicsLayer::flushCompositingState):
      (WebCore::CoordinatedGraphicsLayer::flushCompositingStateForThisLayerOnly):
      * WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.h:
      (CoordinatedGraphicsLayer):
      * WebProcess/WebPage/CoordinatedGraphics/LayerTreeCoordinator.cpp:
      (WebKit::LayerTreeCoordinator::flushPendingLayerChanges):
      (WebKit::LayerTreeCoordinator::notifyFlushRequired):
      * WebProcess/WebPage/CoordinatedGraphics/LayerTreeCoordinator.h:
      (LayerTreeCoordinator):
      * WebProcess/WebPage/ca/LayerTreeHostCA.cpp:
      (WebKit::LayerTreeHostCA::notifyFlushRequired):
      (WebKit::LayerTreeHostCA::flushPendingLayerChanges):
      * WebProcess/WebPage/ca/LayerTreeHostCA.h:
      (LayerTreeHostCA):
      * WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp:
      (WebKit::LayerTreeHostGtk::notifyFlushRequired):
      (WebKit::LayerTreeHostGtk::flushPendingLayerChanges):
      * WebProcess/WebPage/gtk/LayerTreeHostGtk.h:
      (LayerTreeHostGtk):
      * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h:
      (TiledCoreAnimationDrawingArea):
      * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
      (WebKit::TiledCoreAnimationDrawingArea::notifyFlushRequired):
      (WebKit::TiledCoreAnimationDrawingArea::flushLayers):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@130439 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      df44c011
  6. 28 Sep, 2012 1 commit
  7. 24 Sep, 2012 2 commits
    • commit-queue@webkit.org's avatar
      [BlackBerry] Reverting implementation for 407 error pages · 6c65e821
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=97455
      
      Patch by Otto Derek Cheung <otcheung@rim.com> on 2012-09-24
      Reviewed by Rob Buis.
      
      Source/WebCore:
      
      Revert "[BlackBerry] Reverting implementation for 407 error pages"
      This reverts commit fda0a1b6.
      
      This revert also reverts commit 0cffe019
      due to dependency issues.
      
      * PlatformBlackBerry.cmake:
      * platform/blackberry/AuthenticationChallengeManager.cpp: Removed.
      * platform/blackberry/AuthenticationChallengeManager.h:
      * platform/blackberry/PageClientBlackBerry.h:
      * platform/graphics/blackberry/MediaPlayerPrivateBlackBerry.cpp:
      (WebCore::MediaPlayerPrivate::MediaPlayerPrivate):
      (WebCore::MediaPlayerPrivate::~MediaPlayerPrivate):
      (WebCore::MediaPlayerPrivate::onAuthenticationNeeded):
      (WebCore::MediaPlayerPrivate::notifyChallengeResult):
      * platform/graphics/blackberry/MediaPlayerPrivateBlackBerry.h:
      (MediaPlayerPrivate):
      * platform/network/blackberry/NetworkJob.cpp:
      (WebCore::NetworkJob::NetworkJob):
      (WebCore::NetworkJob::handleNotifyStatusReceived):
      (WebCore::NetworkJob::notifyAuthReceived):
      (WebCore::NetworkJob::handleNotifyClose):
      (WebCore::NetworkJob::sendRequestWithCredentials):
      (WebCore::NetworkJob::notifyChallengeResult):
      * platform/network/blackberry/NetworkJob.h:
      (NetworkJob):
      
      Source/WebKit/blackberry:
      
      Revert "[BlackBerry] Really fix bug 95488 that user can get the
      authentication challenge dialog while the other tab has focus."
      https://bugs.webkit.org/show_bug.cgi?id=97348
      
      This reverts commit 0cffe019.
      
      * Api/BlackBerryGlobal.cpp:
      (BlackBerry::WebKit::globalInitialize):
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::~WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::authenticationChallenge):
      (BlackBerry::WebKit::WebPage::setVisible):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129419 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6c65e821
    • anilsson@rim.com's avatar
      [BlackBerry] Add cookie database API · 117cd7a8
      anilsson@rim.com authored
      https://bugs.webkit.org/show_bug.cgi?id=97102
      
      Reviewed by Antonio Gomes.
      
      Source/WebCore:
      
      Add a CookieManager method that takes a list of strings to parse
      instead of just one string. Expose CookieParser::parseOneCookie.
      
      Reviewed internally by Otto D. Cheung.
      
      No change in behavior, no new tests.
      
      * platform/blackberry/CookieManager.cpp:
      (WebCore::CookieManager::setCookies):
      (WebCore):
      * platform/blackberry/CookieManager.h:
      * platform/blackberry/CookieParser.cpp:
      (WebCore::CookieParser::parseOneCookie):
      (WebCore):
      * platform/blackberry/CookieParser.h:
      (CookieParser):
      
      Source/WebKit:
      
      Add cookie database file to build system.
      
      Reviewed internally by Otto D. Cheung.
      
      * PlatformBlackBerry.cmake:
      
      Source/WebKit/blackberry:
      
      The cookie database is exposed through WebCookieJar, which has only two
      methods: cookies() and setCookies().
      
      Also add a new WebString::fromUTF8 overload that takes a const char*
      and a length, in order to avoid a strlen call when converting from
      other string classes to WebString. This is useful for callers of the
      new cookie API when converting cookies to WebString.
      
      Reviewed internally by Otto D. Cheung.
      
      PR 209282
      
      * Api/WebCookieJar.cpp: Added.
      (WebKit):
      (BlackBerry::WebKit::WebCookieJar::WebCookieJar):
      (BlackBerry::WebKit::WebCookieJar::cookies):
      (BlackBerry::WebKit::WebCookieJar::setCookies):
      * Api/WebCookieJar.h: Added.
      (WebKit):
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::~WebPagePrivate):
      (BlackBerry::WebKit::WebPage::cookieJar):
      (WebKit):
      * Api/WebPage.h:
      (WebKit):
      * Api/WebPage_p.h:
      (WebKit):
      (WebPagePrivate):
      * Api/WebString.cpp:
      (BlackBerry::WebKit::WebString::fromUtf8):
      (WebKit):
      * Api/WebString.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129356 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      117cd7a8
  8. 21 Sep, 2012 2 commits
    • commit-queue@webkit.org's avatar
      [BlackBerry] Really fix bug 95488 that user can get the authentication... · 0cffe019
      commit-queue@webkit.org authored
      [BlackBerry] Really fix bug 95488 that user can get the authentication challenge dialog while the other tab has focus.
      https://bugs.webkit.org/show_bug.cgi?id=97348
      Internal PR: 186597.
      
      Internally reviewed by Yong Li, Joe Mason.
      Patch by Lianghui Chen <liachen@rim.com> on 2012-09-21
      Reviewed by Yong Li.
      
      Source/WebCore:
      
      Add a singleton AuthenticationChallengeManager to manage authentication
      challenge dialog. It does following things:
      Record page creation/deletion, so it knows what page is present or not.
      Record page visibility change so it knows when to display a dialog or not.
      Accept authentication challenge, and decide whether to postpone the
          challenge dialog based on whether there is active authentication challenge
          dialog already and whether its page is visible or not.
      When a challenge result comes back, notify the result to all clients
          authenticating for the same protection space, and then start the next
          authentication challenge from the same page, if there is one.
      When a page becomes visible, start the first authentication challenge
          dialog that has been blocked before.
      
      And to support this new AuthenticationChallengeManager, and making the
          challenge really asynchronous, NetworkJob has been updated to support
          the concept of "freeze", which means buffering all network loading status
          change but don't send them to NetworkJob clients.
      This is necessary when authentication challenge is asynchronous, as the
          previous network loading status will likely come before user make any
          decision.
      
      No new tests for platform specific internal change.
      
      * PlatformBlackBerry.cmake:
      * platform/blackberry/AuthenticationChallengeManager.cpp: Added.
      (WebCore):
      (ChallengeInfo):
      (WebCore::ChallengeInfo::ChallengeInfo):
      (AuthenticationChallengeManagerPrivate):
      (WebCore::AuthenticationChallengeManagerPrivate::AuthenticationChallengeManagerPrivate):
      (WebCore::AuthenticationChallengeManagerPrivate::resumeAuthenticationChallenge):
      (WebCore::AuthenticationChallengeManagerPrivate::startAuthenticationChallenge):
      (WebCore::AuthenticationChallengeManagerPrivate::pageExists):
      (WebCore::AuthenticationChallengeManager::AuthenticationChallengeManager):
      (WebCore::AuthenticationChallengeManager::pageCreated):
      (WebCore::AuthenticationChallengeManager::pageDeleted):
      (WebCore::AuthenticationChallengeManager::pageVisibilityChanged):
      (WebCore::AuthenticationChallengeManager::authenticationChallenge):
      (WebCore::AuthenticationChallengeManager::cancelAuthenticationChallenge):
      (WebCore::AuthenticationChallengeManager::notifyChallengeResult):
      (WebCore::AuthenticationChallengeManager::instance):
      (WebCore::AuthenticationChallengeManager::init):
      * platform/blackberry/AuthenticationChallengeManager.h:
      (WebCore):
      (AuthenticationChallengeManager):
      * platform/blackberry/PageClientBlackBerry.h:
      * platform/graphics/blackberry/MediaPlayerPrivateBlackBerry.cpp:
      (WebCore::MediaPlayerPrivate::MediaPlayerPrivate):
      (WebCore::MediaPlayerPrivate::~MediaPlayerPrivate):
      (WebCore::MediaPlayerPrivate::onAuthenticationNeeded):
      (WebCore::MediaPlayerPrivate::notifyChallengeResult):
      * platform/graphics/blackberry/MediaPlayerPrivateBlackBerry.h:
      (MediaPlayerPrivate):
      * platform/network/blackberry/NetworkJob.cpp:
      (WebCore::NetworkJob::NetworkJob):
      (WebCore::NetworkJob::~NetworkJob):
      (WebCore):
      (WebCore::NetworkJob::handleNotifyStatusReceived):
      (WebCore::NetworkJob::handleNotifyClose):
      (WebCore::NetworkJob::sendRequestWithCredentials):
      (WebCore::NetworkJob::notifyChallengeResult):
      * platform/network/blackberry/NetworkJob.h:
      (NetworkJob):
      
      Source/WebKit/blackberry:
      
      Update WebPage to use new AuthenticationChallengeManager.
      Register page creation/deletion and visibility change to the new
          AuthenticationChallengeManager.
      Initialize AuthenticationChallengeManager in GlobalInitialize() function.
      
      * Api/BlackBerryGlobal.cpp:
      (BlackBerry::WebKit::globalInitialize):
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::~WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::authenticationChallenge):
      (BlackBerry::WebKit::WebPage::setVisible):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129251 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0cffe019
    • anilsson@rim.com's avatar
      [BlackBerry] Remove obsolete compositing surface code · 90b016e3
      anilsson@rim.com authored
      https://bugs.webkit.org/show_bug.cgi?id=97314
      
      Reviewed by Antonio Gomes.
      
      Source/WebKit:
      
      Remove compositing surface code from build system.
      
      PR 208038.
      
      * PlatformBlackBerry.cmake:
      
      Source/WebKit/blackberry:
      
      The removed code allowed rendering of sublayers to a separate offscreen
      surface.
      
      Now that we composite root layer and all sublayers to the window
      surface, this code is not needed anymore. In addition, we save some
      memory by not allocating the unused offscreen surface.
      
      PR 208038.
      
      * Api/BackingStore.cpp:
      (BlackBerry::WebKit::BackingStorePrivate::suspendScreenAndBackingStoreUpdates):
      (BlackBerry::WebKit::BackingStorePrivate::blitContents):
      (BlackBerry::WebKit::BackingStorePrivate::drawAndBlendLayersForDirectRendering):
      * Api/BackingStore_p.h:
      (BackingStorePrivate):
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::setLoadState):
      (BlackBerry::WebKit::WebPagePrivate::suspendBackingStore):
      (BlackBerry::WebKit::WebPagePrivate::resizeSurfaceIfNeeded):
      (BlackBerry::WebKit::WebPagePrivate::rootLayerCommitTimerFired):
      (BlackBerry::WebKit::WebPagePrivate::setRootLayerCompositingThread):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebKitSupport/BackingStoreCompositingSurface.cpp: Removed.
      * WebKitSupport/BackingStoreCompositingSurface.h: Removed.
      * WebKitSupport/GLES2Context.cpp:
      (BlackBerry::WebKit::GLES2Context::buffer):
      (BlackBerry::WebKit::GLES2Context::surfaceSize):
      (BlackBerry::WebKit::GLES2Context::swapBuffers):
      * WebKitSupport/GLES2Context.h:
      (GLES2Context):
      * WebKitSupport/SurfacePool.cpp:
      (WebKit):
      (BlackBerry::WebKit::SurfacePool::SurfacePool):
      (BlackBerry::WebKit::SurfacePool::initialize):
      * WebKitSupport/SurfacePool.h:
      (SurfacePool):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129222 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      90b016e3
  9. 19 Sep, 2012 1 commit
    • commit-queue@webkit.org's avatar
      [BlackBerry] Add function playerId() in class PageClientBlackBerry · dd155e08
      commit-queue@webkit.org authored
      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
      dd155e08
  10. 17 Sep, 2012 1 commit
  11. 14 Sep, 2012 1 commit
    • tonikitoo@webkit.org's avatar
      [BlackBerry] Remove the ability to schedule a zoom about point call. · 3cd3fcb9
      tonikitoo@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=96696
      
      [FullScreen] entering/leaving fullscreen results in temporary glitches on the screen (Part I)
      PR #180866
      
      Reviewed by Rob Buis.
      Patch by Antonio Gomes <agomes@rim.com>
      
      Internally reviewed by Jacky Hajiang and Arvid Nilsson.
      
      Patch replaces the async call to zoomAboutPoint (via scheduling it with a one-shot-0-timer).
      Instead, at its single call site, we inline most of the previous scheduleZoomAboutPoint code,
      and in the end call zoomAboutPoint directly.
      
      Change was estimulated by Arvid's comment on PRzilla: "There is no longer any reason to have
      "zoom about point" be async.. That was a hack I did for BB6, back when we were doing everything
      on the WK read and needed manual time slicing betwren rendering and user interaction."
      
      The bigger goal though is to be able to remove screen glitches while entering/leaving
      fullscreen mode: since we could accurately use the count-based suspend/resume backing
      store mechanism to prevent it.
      
      * Api/WebPage.cpp:
      (WebKit):
      (BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::setLoadState):
      (BlackBerry::WebKit::WebPagePrivate::setViewportSize):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128603 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3cd3fcb9
  12. 07 Sep, 2012 1 commit
    • commit-queue@webkit.org's avatar
      [BlackBerry] when one of multiple tabs uses authentication, user can get the... · ea5358c7
      commit-queue@webkit.org authored
      [BlackBerry] when one of multiple tabs uses authentication, user can get the auth dialog while the other tab has focus.
      https://bugs.webkit.org/show_bug.cgi?id=95488
      PR: 186597.
      
      Internally reviewed by Joe Mason.
      Patch by Lianghui Chen <liachen@rim.com> on 2012-09-07
      Reviewed by Yong Li.
      
      Source/WebCore:
      
      The fix for this PR will come as 2 patches. This is the first patch which
      will make the authentication challenge asynchronous inside WebKit. The
      bext patch will add an AuthenticationChallengeManager that manages these
      authentication requests asynchronously.
      
      This patch add AuthenticationChallengeClient interface to define asynchronous
      authentication challenge callback. And MediaPlayerPrivateBlackBerry and
      NetworkJob are changed to inherit from AuthenticationChallengeClient to
      support asynchronous authentication challenge.
      
      Note: there is also an accompanying platform patch to make our PlatformPlayer
      to support asychronous authentication, see PR 186597 for details.
      
      No new tests as this is platform specific change.
      
      * platform/blackberry/AuthenticationChallengeManager.h: Added.
      (WebCore):
      (AuthenticationChallengeClient):
      * platform/blackberry/PageClientBlackBerry.h:
      (WebCore):
      * platform/graphics/blackberry/MediaPlayerPrivateBlackBerry.cpp:
      (WebCore::MediaPlayerPrivate::onAuthenticationNeeded):
      (WebCore::MediaPlayerPrivate::notifyChallengeResult):
      * platform/graphics/blackberry/MediaPlayerPrivateBlackBerry.h:
      (MediaPlayerPrivate):
      * platform/network/blackberry/NetworkJob.cpp:
      (WebCore::NetworkJob::sendRequestWithCredentials):
      (WebCore::NetworkJob::notifyChallengeResult):
      (WebCore):
      * platform/network/blackberry/NetworkJob.h:
      (WebCore):
      (NetworkJob):
      
      Source/WebKit/blackberry:
      
      Use new AuthenticationChallengeClient interface to make authentication
      challenge asynchronous to NetworkJob, MediaPlayerPrivateBlackBerry, and
      other module that will use HTTP authentication. WebPage itself still use
      synchronous authentication though. Switching to asynchronous authentication
      in WebPage will require bigger platform layer change and not very necessary
      at the moment for this bug.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::authenticationChallenge):
      * Api/WebPage_p.h:
      (WebCore):
      (WebPagePrivate):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127884 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ea5358c7
  13. 28 Aug, 2012 1 commit
    • commit-queue@webkit.org's avatar
      [BlackBerry] One shot drawing synchronization broken · 22ebe27b
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=95179
      
      Patch by Andrew Lo <anlo@rim.com> on 2012-08-28
      Reviewed by Antonio Gomes.
      Internally reviewed by Arvid Nilsson.
      
      Make sure no backing store blits happen during one shot drawing
      synchronization.
      Since we always blit during commit now, make sure we don't blit if
      we commit after a render.
      We no longer need a deferred blit since we don't commit during renderContents
      now. Instead, we only commit & blit once after a full render job.
      
      * Api/BackingStore.cpp:
      (BlackBerry::WebKit::BackingStorePrivate::BackingStorePrivate):
      (BlackBerry::WebKit::BackingStorePrivate::repaint):
      (BlackBerry::WebKit::BackingStorePrivate::slowScroll):
      (BlackBerry::WebKit::BackingStorePrivate::renderJob):
      (BlackBerry::WebKit::BackingStorePrivate::blitVisibleContents):
      (BlackBerry::WebKit::BackingStorePrivate::blitContents):
      (BlackBerry::WebKit::BackingStorePrivate::renderContents):
      (WebKit):
      (BlackBerry::WebKit::BackingStorePrivate::drawAndBlendLayersForDirectRendering):
      (BlackBerry::WebKit::BackingStorePrivate::didRenderContent):
      * Api/BackingStore_p.h:
      (BackingStorePrivate):
      * Api/WebPage.cpp:
      (WebKit):
      (BlackBerry::WebKit::WebPagePrivate::rootLayerCommitTimerFired):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebKitSupport/RenderQueue.cpp:
      (BlackBerry::WebKit::RenderQueue::renderAllCurrentRegularRenderJobs):
      (BlackBerry::WebKit::RenderQueue::renderRegularRenderJob):
      (BlackBerry::WebKit::RenderQueue::visibleScrollJobsCompleted):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126878 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      22ebe27b
  14. 27 Aug, 2012 1 commit
    • tonikitoo@webkit.org's avatar
      [BlackBerry] Remove the 'in region scrollable starting node' concept from InRegionScroller · e5b7e6e2
      tonikitoo@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=95020
      
      Reviewed by Rob Buis.
      Patch by Antonio Gomes <agomes@rim.com>
      
      'In-region start scrolling node' is an obsolete concept, and we can remove it
      in favor of using the information from the cached layers.
      
      * Api/InRegionScroller.cpp:
      (WebKit):
      (BlackBerry::WebKit::InRegionScrollerPrivate::reset): Adjusted as it used to clear
      the cached 'node'.
      (BlackBerry::WebKit::InRegionScrollerPrivate::isActive): Added method to be
      checked directly instead of only null-checking the previously cached 'node'.
      (BlackBerry::WebKit::InRegionScrollerPrivate::clearDocumentData): New method to
      clear the cached resources if its document is done.
      (BlackBerry::WebKit::InRegionScrollerPrivate::pushBackInRegionScrollable): Adjusted
      to not care about the cached 'node' anymore.
      * Api/InRegionScroller_p.h:
      (InRegionScrollerPrivate):
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::notifyInRegionScrollStopped): Check ::isActive instead
      of ::hasNode, since the later is gone.
      (BlackBerry::WebKit::WebPagePrivate::enqueueRenderingOfClippedContentOfScrollableAreaAfterInRegionScrolling):
      Changed the method signature, given that we do have a cached 'node' to pass in as parameter anymore.
      (BlackBerry::WebKit::WebPagePrivate::clearDocumentData): Delegate all the related work to InRegionScroller.
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebKitSupport/TouchEventHandler.cpp:
      (BlackBerry::WebKit::TouchEventHandler::drawTapHighlight):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126768 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e5b7e6e2
  15. 23 Aug, 2012 2 commits
    • tonikitoo@webkit.org's avatar
      [BlackBerry] Obsolete the in-region scroll codepath prior to BB10's · f00bed9e
      tonikitoo@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=94839
      PR #197775
      
      Reviewed by George Staikos.
      Patch by Antonio Gomes <agomes@rim.com>
      
      This codepath is not needed anymore, so lets let it RIP.
      
      The only code addition is due to some code I've moved from WebPagePrivate::scrollNodeRecursively
      and WebPagePrivate::scrollBy to InRegionScrollerPrivate::setLayerScrollPosition.
      Rest is code removal ...
      
      * Api/InRegionScroller.cpp:
      (BlackBerry::WebKit::InRegionScrollerPrivate::setLayerScrollPosition):
      * Api/InRegionScroller_p.h:
      (InRegionScrollerPrivate):
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::scrollBy):
      (BlackBerry::WebKit::WebPage::scrollBy):
      * Api/WebPage.h:
      * Api/WebPage_p.h:
      (WebPagePrivate):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126514 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      f00bed9e
    • zhajiang@rim.com's avatar
      [BlackBerry] Web pages are zoomed out to much on initial load · e77bce75
      zhajiang@rim.com authored
      https://bugs.webkit.org/show_bug.cgi?id=94830
      
      Reviewed by Adam Treat.
      Patch by Jacky Jiang <zhajiang@rim.com>
      
      PR: 193943
      Browser continuously adds paddings to the left and right sides of the
      main contents which makes the main contents even smaller.
      The issue can be reproduced on the desktop websites such as
      huffingtonpost.ca, bloomberg.com, online.wsj.com, nytimes.com,
      yahoo.com, thestar.com, sina.com.cn, sohu.com and so on.
      The root cause is that we layout those contents at the width of 1280
      although the fixed width of the main contents of those websites is
      less than 1000, which results in adding the paddings.
      To fix this, we need to get back to the default max layout size
      1024 * 768, which will make the main contents of those popular websites
      take full advantage of the screen real estate and look much better.
      
      Internally reviewed by Adam Treat.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::fixedLayoutSize):
      (BlackBerry::WebKit::WebPagePrivate::recomputeVirtualViewportFromViewportArguments):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebKitSupport/RenderQueue.cpp:
      (BlackBerry::WebKit::RenderQueue::splittingFactor):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126470 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e77bce75
  16. 22 Aug, 2012 1 commit
    • commit-queue@webkit.org's avatar
      [BlackBerry] Make all pickers non-zoomable · 34f3ade6
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=94729
      
      Patch by Crystal Zhang <haizhang@rim.com> on 2012-08-22
      Reviewed by Antonio Gomes.
      
      Move HTML header initialization to PagePopupBlackBerry as that part are all the same, and make all pickers non-zoomable.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::screenSize):
      (WebKit):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebCoreSupport/DatePickerClient.cpp:
      (WebCore::DatePickerClient::generateHTML):
      (WebCore::DatePickerClient::writeDocument):
      * WebCoreSupport/PagePopupBlackBerry.cpp:
      (WebCore::PagePopupBlackBerry::init):
      (WebCore::PagePopupBlackBerry::generateHTML):
      (WebCore):
      * WebCoreSupport/PagePopupBlackBerry.h:
      (PagePopupBlackBerry):
      * WebCoreSupport/SelectPopupClient.cpp:
      (WebCore::SelectPopupClient::generateHTML):
      (WebCore::SelectPopupClient::writeDocument):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126338 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      34f3ade6
  17. 21 Aug, 2012 2 commits
  18. 16 Aug, 2012 2 commits
    • commit-queue@webkit.org's avatar
      [BlackBerry] Remove Mobile mode from WebPage.cpp and WebPage_p.h · 792e2982
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=94223
      PR #192773
      
      Patch by Leo Yang <leoyang@rim.com> on 2012-08-16
      Reviewed by Rob Buis.
      Reviewed internally by Arvid Nilsson.
      
      Remove Mobile mode as it's not been used. Also remove code that
      handle top-level SVG document because now we can handle it in Desktop mode.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::setLoadState):
      (BlackBerry::WebKit::WebPagePrivate::fixedLayoutSize):
      * Api/WebPage_p.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125796 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      792e2982
    • commit-queue@webkit.org's avatar
      [BlackBerry] WebGL and Canvas fail to display after being restored from page cache · 2623a66e
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=94105
      
      Patch by Arvid Nilsson <anilsson@rim.com> on 2012-08-16
      Reviewed by George Staikos.
      
      The EGLImage was being destroyed when releasing layer resources on the
      compositing thread, but the WebKit thread layer never found out and
      failed to create a new image.
      
      Fixed by extending the release layer resources mechanism to also make a
      pass on the WebKit thread so that thread's layers have a chance to
      delete their textures and related resources.
      
      Source/WebCore:
      
      WebGL and canvas layers now take this opportunity to release their
      textures so the EGLImage gets recreated when compositing commits
      resume.
      
      The only detail that deserves extra explanation is the ownership of the
      EGLImage.
      
      Since the EGLImage is created in updateTextureContentsIfNeeded() and
      that one is always followed by commitPendingTextureUploads() which
      transfers the EGLImage to the compositing thread layer's custody, the
      EGLImage currently referenced by EGLImageLayerWebKitThread::m_image
      should never be deleted by the WebKit thread layer.
      
      Thus all we have to do in deleteFrontBuffer() is to set the m_image
      member to 0 so the image gets recreated on the next commit. It will be
      deleted by the part of releaseLayerResources() that executes on the
      compositing thread (which, if you recall, was the original source of
      this bug).
      
      Reviewed internally by Filip Spacek.
      
      PR 192899
      
      Not currently testable by the BlackBerry testing infrastructure.
      
      * platform/graphics/blackberry/CanvasLayerWebKitThread.cpp:
      (WebCore::CanvasLayerWebKitThread::deleteTextures):
      (WebCore):
      * platform/graphics/blackberry/CanvasLayerWebKitThread.h:
      (CanvasLayerWebKitThread):
      * platform/graphics/blackberry/EGLImageLayerWebKitThread.cpp:
      (WebCore::EGLImageLayerWebKitThread::~EGLImageLayerWebKitThread):
      (WebCore::EGLImageLayerWebKitThread::deleteFrontBuffer):
      * platform/graphics/blackberry/EGLImageLayerWebKitThread.h:
      (EGLImageLayerWebKitThread):
      * platform/graphics/blackberry/LayerWebKitThread.cpp:
      (WebCore::LayerWebKitThread::releaseLayerResources):
      (WebCore):
      * platform/graphics/blackberry/LayerWebKitThread.h:
      (LayerWebKitThread):
      (WebCore::LayerWebKitThread::deleteTextures):
      * platform/graphics/blackberry/WebGLLayerWebKitThread.cpp:
      (WebCore::WebGLLayerWebKitThread::~WebGLLayerWebKitThread):
      (WebCore::WebGLLayerWebKitThread::deleteTextures):
      (WebCore):
      * platform/graphics/blackberry/WebGLLayerWebKitThread.h:
      (WebGLLayerWebKitThread):
      
      Source/WebKit/blackberry:
      
      Reviewed internally by Filip Spacek.
      
      PR 192899
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::setLoadState):
      (BlackBerry::WebKit::WebPagePrivate::releaseLayerResources):
      (WebKit):
      (BlackBerry::WebKit::WebPagePrivate::releaseLayerResourcesCompositingThread):
      (BlackBerry::WebKit::WebPagePrivate::suspendRootLayerCommit):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebKitSupport/FrameLayers.cpp:
      (BlackBerry::WebKit::FrameLayers::releaseLayerResources):
      (WebKit):
      * WebKitSupport/FrameLayers.h:
      (FrameLayers):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125770 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2623a66e
  19. 14 Aug, 2012 2 commits
    • zhajiang@rim.com's avatar
      [BlackBerry] Double-tap zoom on blocks on cnn.com desktop page doesn't work · 2d345e16
      zhajiang@rim.com authored
      https://bugs.webkit.org/show_bug.cgi?id=93895
      
      Reviewed by Antonio Gomes.
      Patch by Jacky Jiang  <zhajiang@rim.com>
      
      PR: 188232
      When adjusting block zoom node, don't choose a node if the width of the
      node size is very close to the width of the actual visible size as
      block zoom can do nothing on such kind of node. This condition is more
      restrictive than the one based on area and can bail out early.
      In this way, we can get a better node for double-tap zoom.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::bestNodeForZoomUnderPoint):
      (BlackBerry::WebKit::WebPagePrivate::adjustedBlockZoomNodeForZoomAndExpandingRatioLimits):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125574 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2d345e16
    • commit-queue@webkit.org's avatar
      [BlackBerry] Get rid of glCopyTexImage2D in Canvas and WebGL code paths · fa0bb6d9
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=93614
      
      Patch by Arvid Nilsson <anilsson@rim.com> on 2012-08-14
      Reviewed by Antonio Gomes.
      
      We used to set up resource sharing between the compositing thread
      context and the Canvas and WebGL contexts, and use glCopyTexImage2D to
      get a copy of the framebuffer to use as front buffer for compositing
      purposes.
      
      Now we instead create an EGLImage and blit the Canvas/WebGL output to
      it. The compositing thread creates a texture from the EGLImage in order
      to composite the output.
      
      Source/WebCore:
      
      Created a new EGLImageLayerWebKitThread base class that handles the
      EGLImage and does the blitting. CanvasLayerWebKitThread and
      WebGLLayerWebKitThread now inherit from this new base class.
      
      However, we need to be careful to restore state after the blit because
      it's done using the Canvas/WebGL context.
      
      The BlackBerry implementation of GraphicsContext3D::prepareTexture()
      was changed to no longer call glCopyTexImage, and
      GraphicsContext3D::platformLayer() now returns the target texture
      directly.
      
      Reviewed internally by Filip Spacek.
      
      PR 188472
      
      No change in behavior, new tests.
      
      * PlatformBlackBerry.cmake:
      * platform/graphics/blackberry/CanvasLayerWebKitThread.cpp:
      (WebCore::CanvasLayerWebKitThread::CanvasLayerWebKitThread):
      (WebCore::CanvasLayerWebKitThread::~CanvasLayerWebKitThread):
      (WebCore::CanvasLayerWebKitThread::setDevice):
      (WebCore::CanvasLayerWebKitThread::makeContextCurrent):
      (WebCore::CanvasLayerWebKitThread::textureSize):
      (WebCore):
      (WebCore::CanvasLayerWebKitThread::textureID):
      * platform/graphics/blackberry/CanvasLayerWebKitThread.h:
      (CanvasLayerWebKitThread):
      * platform/graphics/blackberry/EGLImageLayerCompositingThreadClient.cpp: Added.
      (WebCore):
      (WebCore::EGLImageLayerCompositingThreadClient::~EGLImageLayerCompositingThreadClient):
      (WebCore::EGLImageLayerCompositingThreadClient::uploadTexturesIfNeeded):
      (WebCore::EGLImageLayerCompositingThreadClient::drawTextures):
      (WebCore::EGLImageLayerCompositingThreadClient::deleteTextures):
      (WebCore::EGLImageLayerCompositingThreadClient::bindContentsTexture):
      (WebCore::EGLImageLayerCompositingThreadClient::setImage):
      * platform/graphics/blackberry/EGLImageLayerCompositingThreadClient.h: Added.
      (WebCore):
      (EGLImageLayerCompositingThreadClient):
      (WebCore::EGLImageLayerCompositingThreadClient::create):
      (WebCore::EGLImageLayerCompositingThreadClient::layerCompositingThreadDestroyed):
      (WebCore::EGLImageLayerCompositingThreadClient::layerVisibilityChanged):
      (WebCore::EGLImageLayerCompositingThreadClient::EGLImageLayerCompositingThreadClient):
      * platform/graphics/blackberry/EGLImageLayerWebKitThread.cpp: Added.
      (WebCore):
      (WebCore::EGLImageLayerWebKitThread::EGLImageLayerWebKitThread):
      (WebCore::EGLImageLayerWebKitThread::~EGLImageLayerWebKitThread):
      (WebCore::EGLImageLayerWebKitThread::setNeedsDisplay):
      (WebCore::EGLImageLayerWebKitThread::makeContextCurrent):
      (WebCore::EGLImageLayerWebKitThread::updateTextureContentsIfNeeded):
      (WebCore::EGLImageLayerWebKitThread::commitPendingTextureUploads):
      (WebCore::EGLImageLayerWebKitThread::createImageIfNeeded):
      (WebCore::EGLImageLayerWebKitThread::createShaderIfNeeded):
      (WebCore::EGLImageLayerWebKitThread::drawTexture):
      * platform/graphics/blackberry/EGLImageLayerWebKitThread.h: Copied from Source/WebCore/platform/graphics/blackberry/CanvasLayerWebKitThread.h.
      (WebCore):
      (EGLImageLayerWebKitThread):
      * platform/graphics/blackberry/GraphicsContext3DBlackBerry.cpp:
      (WebCore::GraphicsContext3D::prepareTexture):
      (WebCore):
      (WebCore::GraphicsContext3D::platformTexture):
      * platform/graphics/blackberry/LayerCompositingThread.cpp:
      (WebCore::LayerCompositingThread::drawTextures):
      (WebCore::LayerCompositingThread::releaseTextureResources):
      * platform/graphics/blackberry/LayerCompositingThread.h:
      (WebCore::LayerCompositingThread::setClient):
      (LayerCompositingThread):
      * platform/graphics/blackberry/LayerData.h:
      (WebCore::LayerData::LayerData):
      (LayerData):
      * platform/graphics/blackberry/LayerWebKitThread.cpp:
      (WebCore::LayerWebKitThread::~LayerWebKitThread):
      (WebCore::LayerWebKitThread::updateTextureContentsIfNeeded):
      (WebCore::LayerWebKitThread::commitPendingTextureUploads):
      (WebCore::LayerWebKitThread::commitOnCompositingThread):
      * platform/graphics/blackberry/LayerWebKitThread.h:
      (LayerWebKitThread):
      * platform/graphics/blackberry/WebGLLayerWebKitThread.cpp:
      (WebCore::WebGLLayerWebKitThread::WebGLLayerWebKitThread):
      (WebCore::WebGLLayerWebKitThread::updateTextureContentsIfNeeded):
      (WebCore::WebGLLayerWebKitThread::makeContextCurrent):
      (WebCore):
      (WebCore::WebGLLayerWebKitThread::textureSize):
      (WebCore::WebGLLayerWebKitThread::textureID):
      * platform/graphics/blackberry/WebGLLayerWebKitThread.h:
      (WebGLLayerWebKitThread):
      * platform/graphics/opengl/GraphicsContext3DOpenGLCommon.cpp:
      (WebCore):
      (WebCore::GraphicsContext3D::prepareTexture):
      
      Source/WebKit/blackberry:
      
      This allows us to turn off resource sharing, so the WebPageCompositor
      no longer needs to pass the compositing thread context to the webkit
      thread.
      
      Reviewed internally by Filip Spacek.
      
      PR 188472
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::setCompositor):
      (BlackBerry::WebKit::WebPagePrivate::setCompositorHelper):
      * Api/WebPageCompositor.cpp:
      (BlackBerry::WebKit::WebPageCompositor::WebPageCompositor):
      (BlackBerry::WebKit::WebPageCompositor::~WebPageCompositor):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125563 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      fa0bb6d9
  20. 08 Aug, 2012 1 commit
  21. 07 Aug, 2012 1 commit
  22. 03 Aug, 2012 3 commits
    • commit-queue@webkit.org's avatar
      [BlackBerry] FrameLoaderClient::restoreViewState() shouldn't trigger painting · bfe43b65
      commit-queue@webkit.org authored
      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
      bfe43b65
    • kpiascik@rim.com's avatar
      [BlackBerry] InspectorOverlay class duplicated in WebCore · b66c8115
      kpiascik@rim.com authored
      https://bugs.webkit.org/show_bug.cgi?id=93124
      
      Reviewed by Rob Buis.
      
      Changed namespace of InspectorOverlay from WebCore to
      BlackBerry::WebKit
      
      * Api/WebPage.cpp:
      (WebKit):
      (BlackBerry::WebKit::WebPagePrivate::setInspectorOverlayClient):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebCoreSupport/InspectorClientBlackBerry.h:
      * WebCoreSupport/InspectorOverlay.cpp:
      (BlackBerry::WebKit::InspectorOverlay::create):
      (BlackBerry::WebKit::InspectorOverlay::InspectorOverlay):
      (BlackBerry::WebKit::InspectorOverlay::notifySyncRequired):
      (BlackBerry::WebKit::InspectorOverlay::paintContents):
      (BlackBerry::WebKit::InspectorOverlay::showDebugBorders):
      (BlackBerry::WebKit::InspectorOverlay::showRepaintCounter):
      (BlackBerry::WebKit::InspectorOverlay::contentsVisible):
      (BlackBerry::WebKit::InspectorOverlay::update):
      * WebCoreSupport/InspectorOverlay.h:
      (WebKit):
      (InspectorOverlayClient):
      (InspectorOverlay):
      (BlackBerry::WebKit::InspectorOverlay::notifyAnimationStarted):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124639 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b66c8115
    • commit-queue@webkit.org's avatar
      [BlackBerry] Overlays display checkerboard that doesn't resolve · 0d89a76a
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=93099
      
      Patch by Arvid Nilsson <anilsson@rim.com> on 2012-08-03
      Reviewed by Antonio Gomes.
      
      The WebKit-thread overlays, like tap highlight, inspector highlight and
      selection are all part of a separate graphics layer tree rooted in
      WebPagePrivate::m_overlayLayer.
      
      When LayerRenderer needs to schedule a commit to reactively render
      tiles and resolve checkerboard, it does so through the root layer.
      Since the overlay layer root didn't have a GraphicsLayerClient, there
      was no implementation of GraphicsLayerClient::notifySyncRequired() to
      call, and a commit was never scheduled, thus checkerboard never
      resolved.
      
      Fixed by adding a fallback implementation of GraphicsLayerClient in
      WebPagePrivate and hooking up the overlay root to it. Also, this
      implementation can be shared by the various overlays to avoide code
      duplication, specifically to implement notifySyncRequired(),
      showDebugBorders() and showRepaintCounter() only once.
      
      Fixing this revealed a bug where the web page would get stuck in an
      endless sequence of commits. It turned out that
      WebPagePrivate::updateDelegatedOverlays() was called right in the
      middle of the commit operation, after performing the webkit thread part
      of the commit operation but before we continued on the compositing
      thread. Since updateDelegatedOverlays() typically mutates layers, this
      is very bad (layers should not be mutated mid-commit). The mutations
      also cause a new commit to scheduled from within the current, which
      results in an endless sequence of commits.
      
      Fixed this latter bug by moving the updateDelegatedOverlays() call to
      the beginning of the method where it can cause no harm. This is before
      we mark the web page as no longer needing commit, so even if the
      implementation flips the "needs commit" bit, we will immediately flip
      it back and proceed with commit as usual.
      
      PR 187458, 184377
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::overlayLayer):
      (BlackBerry::WebKit::WebPagePrivate::commitRootLayerIfNeeded):
      (WebKit):
      (BlackBerry::WebKit::WebPagePrivate::notifySyncRequired):
      (BlackBerry::WebKit::WebPagePrivate::showDebugBorders):
      (BlackBerry::WebKit::WebPagePrivate::showRepaintCounter):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::notifyAnimationStarted):
      (BlackBerry::WebKit::WebPagePrivate::paintContents):
      * WebCoreSupport/InspectorOverlay.cpp:
      (WebCore::InspectorOverlay::notifySyncRequired):
      (WebCore::InspectorOverlay::showDebugBorders):
      (WebCore::InspectorOverlay::showRepaintCounter):
      * WebKitSupport/DefaultTapHighlight.cpp:
      (BlackBerry::WebKit::DefaultTapHighlight::notifySyncRequired):
      (BlackBerry::WebKit::DefaultTapHighlight::showDebugBorders):
      (WebKit):
      (BlackBerry::WebKit::DefaultTapHighlight::showRepaintCounter):
      * WebKitSupport/DefaultTapHighlight.h:
      (DefaultTapHighlight):
      * WebKitSupport/SelectionOverlay.cpp:
      (BlackBerry::WebKit::SelectionOverlay::notifySyncRequired):
      (BlackBerry::WebKit::SelectionOverlay::showDebugBorders):
      (WebKit):
      (BlackBerry::WebKit::SelectionOverlay::showRepaintCounter):
      * WebKitSupport/SelectionOverlay.h:
      (SelectionOverlay):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124615 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0d89a76a
  23. 02 Aug, 2012 1 commit
    • tonikitoo@webkit.org's avatar
      [BlackBerry] Implement InRegionScroller class as a in-region scroll controller · 80fd790d
      tonikitoo@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=92889
      PR #186587
      
      Reviewed by Yong Li.
      Patch by Antonio Gomes <agomes@rim.com>
      
      Internally reviewed by Arvid Nilsson.
      
      Source/WebKit:
      
      * PlatformBlackBerry.cmake: Added InRegionScroller.cpp|h to the build system.
      
      Source/WebKit/blackberry:
      
      Moved all in-region scrolling code out of WebPagePrivate to the just
      created InRegionScroller class. This class aims to:
      
      1) Centralize all in-region scroll code and clean up WebPagePrivate as a consequence.
      2) Be the bases to add UI/Compositing thread driven scrolls to in-region.
      
      The patch does not change any functionallity change.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::init):
      (BlackBerry::WebKit::WebPagePrivate::scrollBy):
      (BlackBerry::WebKit::WebPagePrivate::notifyInRegionScrollStatusChanged):
      (BlackBerry::WebKit::WebPagePrivate::clearDocumentData):
      (BlackBerry::WebKit::WebPagePrivate::setScrollOriginPoint):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebKitSupport/InRegionScrollableArea.cpp:
      (BlackBerry::WebKit::InRegionScrollableArea::layer):
      * WebKitSupport/InRegionScroller.cpp: Added.
      (WebKit):
      (BlackBerry::WebKit::canScrollInnerFrame):
      (BlackBerry::WebKit::canScrollRenderBox):
      (BlackBerry::WebKit::parentLayer):
      (BlackBerry::WebKit::enclosingLayerNode):
      (BlackBerry::WebKit::isNonRenderViewFixedPositionedContainer):
      (BlackBerry::WebKit::pushBackInRegionScrollable):
      (BlackBerry::WebKit::InRegionScroller::InRegionScroller):
      (BlackBerry::WebKit::InRegionScroller::setNode):
      (BlackBerry::WebKit::InRegionScroller::node):
      (BlackBerry::WebKit::InRegionScroller::reset):
      (BlackBerry::WebKit::InRegionScroller::isNull):
      (BlackBerry::WebKit::InRegionScroller::scrollBy):
      (BlackBerry::WebKit::InRegionScroller::inRegionScrollableAreasForPoint):
      (BlackBerry::WebKit::InRegionScroller::scrollNodeRecursively):
      (BlackBerry::WebKit::InRegionScroller::scrollRenderer):
      (BlackBerry::WebKit::InRegionScroller::adjustScrollDelta):
      * WebKitSupport/InRegionScroller.h: Added.
      (WebCore):
      (WebKit):
      (InRegionScroller):
      * WebKitSupport/TouchEventHandler.cpp:
      (BlackBerry::WebKit::TouchEventHandler::drawTapHighlight):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124470 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      80fd790d
  24. 01 Aug, 2012 1 commit
  25. 23 Jul, 2012 1 commit
    • commit-queue@webkit.org's avatar
      [BlackBerry] Move about: URL handling out of WebCore · 13fd82c6
      commit-queue@webkit.org authored
      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
      13fd82c6
  26. 19 Jul, 2012 1 commit
    • jpetsovits@rim.com's avatar
      [BlackBerry] Suspend when there's no target buffer until an external compositor is set · fb8222d8
      jpetsovits@rim.com authored
      https://bugs.webkit.org/show_bug.cgi?id=91686
      RIM PR 174365
      
      Reviewed by Antonio Gomes.
      
      If we don't have a client window (i.e. rendering to
      GL directly) and a WebPageCompositor is only set
      after a rendering operation, then we'll try to render
      to BackingStorePrivate::buffer() which doesn't exist
      at this point. That's bad, and gets us various
      assertions and possibly worse.
      
      Fix it by starting in a screen-suspended state and only
      resuming screen and backingstore once a compositor is
      actually set.
      
      So, in effect, with this patch applied, the sequence
      of events will look like this:
      
      1) WebPage & BackingStore are initialize, neither window
         nor compositor exists, therefore buffer() returns 0.
         createSurface() therefore suspends screen and
         backingstore.
      2) loadURL() or loadData() is called, web page is
         fully loaded, however we don't try to render because
         we're still suspended, still have no target buffer.
      3) A WebPageCompositor is being set from outside.
         At the beginning of WebPage::setCompositor() we still
         don't have a buffer() so there's nothing to suspend,
         however, after the sync call to setCompositorHelper()
         the compositor is set so buffer() will return a
         nonzero value, causing us to resume at this point.
      
      Using the existence of a target buffer to determine
      whether or not to enable rendering or keep it suspended
      seems like a good idea, and the implementation (while
      not quite perfect yet) is a step forward from before.
      
      * Api/BackingStore.cpp:
      (BlackBerry::WebKit::BackingStorePrivate::createSurfaces):
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::setCompositor):
      (BlackBerry::WebKit::WebPagePrivate::setCompositorHelper):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123172 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      fb8222d8
  27. 18 Jul, 2012 1 commit
    • commit-queue@webkit.org's avatar
      [BlackBerry] Move about: URL handling out of WebCore · a2ddbf5c
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=91541
      
      Patch by Yong Li <yoli@rim.com> on 2012-07-18
      Reviewed by Rob Buis.
      
      Source/WebCore:
      
      Remove about URL handling from our NetworkJob.
      
      * platform/network/blackberry/NetworkJob.cpp:
      (WebCore::NetworkJob::NetworkJob):
      (WebCore::NetworkJob::initialize):
      (WebCore::NetworkJob::cancelJob):
      (WebCore::NetworkJob::sendResponseIfNeeded):
      * platform/network/blackberry/NetworkJob.h:
      (NetworkJob):
      * platform/network/blackberry/NetworkManager.cpp:
      (WebCore::NetworkManager::startJob):
      
      Source/WebKit:
      
      AboutData.cpp is moved from WebCoreSupport to WebKitSupport.
      
      * PlatformBlackBerry.cmake:
      
      Source/WebKit/blackberry:
      
      Move about URL handling code to WebKit/blackberry. Now when WebPage is asked to load an about URL,
      it directly calls loadString() with the generated source.
      
      Also move AboutData.h/cpp from WebCoreSupport to WebKitSupport and change their namespace from WebCore
      to BlackBerry::WebKit.
      
      The change is very mechanical except "procss total memory usage" in about:memory now only accounts used
      bytes and ignore free spaces in malloc.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::loadAbout):
      (WebKit):
      (BlackBerry::WebKit::WebPage::load):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebKitSupport/AboutData.cpp: Renamed from Source/WebKit/blackberry/WebCoreSupport/AboutData.cpp.
      (WebKit):
      (BlackBerry::WebKit::writeFeatures):
      (BlackBerry::WebKit::numberToHTMLTr):
      (BlackBerry::WebKit::bool):
      (BlackBerry::WebKit::configPage):
      (BlackBerry::WebKit::cacheTypeStatisticToHTMLTr):
      (BlackBerry::WebKit::dumpJSCTypeCountSetToTableHTML):
      (BlackBerry::WebKit::memoryPage):
      * WebKitSupport/AboutData.h: Renamed from Source/WebKit/blackberry/WebCoreSupport/AboutData.h.
      (WebKit):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122992 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a2ddbf5c
  28. 17 Jul, 2012 1 commit
    • commit-queue@webkit.org's avatar
      Web Inspector: refactor InspectorController::connectFrontend() to accept InspectorFrontendChannel. · c517ae09
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=91196
      
      Patch by Vivek Galatage <vivekgalatage@gmail.com> on 2012-07-17
      Reviewed by Pavel Feldman.
      
      Source/WebCore:
      
      Refactoring InspectorClients. InspectorClient::openInspectorFrontend
      now returning the InspectorFrontendChannel. Also refactored
      InspectorController::connectFrontend() to receive
      InspectorFrontendChannel.
      
      No new test as code refactoring done.
      
      * inspector/InspectorClient.h:
      (WebCore):
      (InspectorClient):
      * inspector/InspectorController.cpp:
      (WebCore::InspectorController::InspectorController):
      (WebCore::InspectorController::connectFrontend):
      (WebCore::InspectorController::show):
      (WebCore::InspectorController::reconnectFrontend):
      * inspector/InspectorController.h:
      (WebCore):
      (InspectorController):
      * loader/EmptyClients.h:
      (WebCore::EmptyInspectorClient::openInspectorFrontend):
      (WebCore::EmptyInspectorClient::hideHighlight):
      
      Source/WebKit/blackberry:
      
      Refactoring InspectorClients. InspectorClient::openInspectorFrontend
      now returning the InspectorFrontendChannel.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
      (BlackBerry::WebKit::WebPagePrivate::init):
      (BlackBerry::WebKit::WebPage::enableWebInspector):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebCoreSupport/InspectorClientBlackBerry.cpp:
      (WebCore::InspectorClientBlackBerry::openInspectorFrontend):
      * WebCoreSupport/InspectorClientBlackBerry.h:
      (InspectorClientBlackBerry):
      
      Source/WebKit/chromium:
      
      Refactoring InspectorClients. InspectorClient::openInspectorFrontend
      now returning the InspectorFrontendChannel.
      
      * src/InspectorClientImpl.cpp:
      (WebKit::InspectorClientImpl::openInspectorFrontend):
      * src/InspectorClientImpl.h:
      (InspectorClientImpl):
      * src/WebDevToolsAgentImpl.cpp:
      (WebKit::WebDevToolsAgentImpl::reattach):
      (WebKit::WebDevToolsAgentImpl::openInspectorFrontend):
      * src/WebDevToolsAgentImpl.h:
      (WebDevToolsAgentImpl):
      
      Source/WebKit/efl:
      
      Refactoring InspectorClients. InspectorClient::openInspectorFrontend
      now returning the InspectorFrontendChannel.
      
      * WebCoreSupport/InspectorClientEfl.cpp:
      (WebCore::InspectorClientEfl::openInspectorFrontend):
      * WebCoreSupport/InspectorClientEfl.h:
      (InspectorClientEfl):
      
      Source/WebKit/gtk:
      
      Refactoring InspectorClients. InspectorClient::openInspectorFrontend
      now returning the InspectorFrontendChannel.
      
      * WebCoreSupport/InspectorClientGtk.cpp:
      (WebKit::InspectorClient::openInspectorFrontend):
      * WebCoreSupport/InspectorClientGtk.h:
      (InspectorClient):
      
      Source/WebKit/mac:
      
      Refactoring InspectorClients. InspectorClient::openInspectorFrontend
      now returning the InspectorFrontendChannel.
      
      * WebCoreSupport/WebInspectorClient.h:
      (WebInspectorClient):
      * WebCoreSupport/WebInspectorClient.mm:
      (WebInspectorClient::openInspectorFrontend):
      
      Source/WebKit/qt:
      
      Refactoring InspectorClients. InspectorClient::openInspectorFrontend
      now returning the InspectorFrontendChannel.
      
      * WebCoreSupport/InspectorClientQt.cpp:
      (WebCore::InspectorClientQt::openInspectorFrontend):
      (WebCore::InspectorClientQt::attachAndReplaceRemoteFrontend):
      * WebCoreSupport/InspectorClientQt.h:
      (InspectorClientQt):
      
      Source/WebKit/win:
      
      Refactoring InspectorClients. InspectorClient::openInspectorFrontend
      now returning the InspectorFrontendChannel.
      
      * WebCoreSupport/WebInspectorClient.cpp:
      (WebInspectorClient::openInspectorFrontend):
      * WebCoreSupport/WebInspectorClient.h:
      (WebInspectorClient):
      
      Source/WebKit/wince:
      
      Refactoring InspectorClients. InspectorClient::openInspectorFrontend
      now returning the InspectorFrontendChannel.
      
      * WebCoreSupport/InspectorClientWinCE.cpp:
      (WebKit::InspectorClientWinCE::openInspectorFrontend):
      * WebCoreSupport/InspectorClientWinCE.h:
      (InspectorClientWinCE):
      
      Source/WebKit/wx:
      
      Refactoring InspectorClients. InspectorClient::openInspectorFrontend
      now returning the InspectorFrontendChannel.
      
      * WebKitSupport/InspectorClientWx.cpp:
      (WebCore::InspectorClientWx::openInspectorFrontend):
      * WebKitSupport/InspectorClientWx.h:
      (InspectorClientWx):
      
      Source/WebKit2:
      
      Refactoring InspectorClients. InspectorClient::openInspectorFrontend
      now returning the InspectorFrontendChannel.
      
      * WebProcess/WebCoreSupport/WebInspectorClient.cpp:
      (WebKit::WebInspectorClient::openInspectorFrontend):
      * WebProcess/WebCoreSupport/WebInspectorClient.h:
      (WebInspectorClient):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122838 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c517ae09
  29. 13 Jul, 2012 1 commit
    • zhajiang@rim.com's avatar
      [BlackBerry] resetBitmapZoomScale called while zooming preventing pinch zoom · 6d4fb363
      zhajiang@rim.com authored
      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
      6d4fb363
  30. 12 Jul, 2012 1 commit
    • commit-queue@webkit.org's avatar
      [BlackBerry] Cannot use digest proxy auth and NTLM auth at the same time · 9e083379
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=91054
      
      Patch by Jonathan Dong <jonathan.dong@torchmobile.com.cn> on 2012-07-12
      Reviewed by George Staikos.
      
      Source/WebCore:
      
      Added an interface function syncProxyCredential() in class
      PageClientBlackBerry, which is responsible to notify WebPageClient
      to synchronize proxy credential to the chrome process.
      
      Internally reviewed by Jason Liu <jason.liu@torchmobile.com.cn>
      
      No new tests since there's no functional change.
      
      * platform/blackberry/PageClientBlackBerry.h:
      * platform/network/blackberry/NetworkJob.cpp:
      (WebCore::NetworkJob::storeCredentials): Remember the accepted proxy
      credential and notify webpage client to synchronize it.
      
      Source/WebKit/blackberry:
      
      Implemented interface function syncProxyCredential() derived
      from class PageClientBlackBerry.
      
      Internally reviewed by Jason Liu <jason.liu@torchmobile.com.cn>
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::syncProxyCredential):
      (WebKit):
      * Api/WebPageClient.h:
      * Api/WebPage_p.h:
      (WebPagePrivate):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122444 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9e083379
  31. 09 Jul, 2012 1 commit
    • commit-queue@webkit.org's avatar
      [BlackBerry] PagePopupBlackBerry::closePopup() should always clear the pointer in WebPagePrivate · d54ab84d
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=90817
      
      Patch by Yong Li <yoli@rim.com> on 2012-07-09
      Reviewed by Rob Buis.
      
      PR# 174085.
      PagePopupBlackBerry::closePopup() should always clear the pointer in WebPagePrivate to avoid crashes.
      This patch also removes unused variable m_parentPopup and its setter.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::WebPagePrivate): Remove m_parentPopup.
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebCoreSupport/ChromeClientBlackBerry.cpp:
      (WebCore::ChromeClientBlackBerry::closePagePopup):
      * WebCoreSupport/PagePopupBlackBerry.cpp:
      (WebCore::PagePopupBlackBerry::init): Remove the setParentPopup() call.
      (WebCore::PagePopupBlackBerry::closePopup): Clear the reference in WebPagePrivate.
      * WebCoreSupport/SelectPopupClient.cpp:
      (WebCore::SelectPopupClient::setValueAndClosePopup): Add an assert for valid m_element.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122162 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d54ab84d
  32. 04 Jul, 2012 1 commit
    • commit-queue@webkit.org's avatar
      [BlackBerry] Implement device metrics for blackberry. · 1e811c7f
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=90494
      RIM PR #159034
      
      Patch by Hanna Ma <Hanma@rim.com> on 2012-07-04
      Reviewed by Rob Buis.
      
      Implement calls to the application to change the device metrics for
      the web inspector.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::applySizeOverride):
      (WebKit):
      (BlackBerry::WebKit::WebPagePrivate::setTextZoomFactor):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      * WebCoreSupport/InspectorClientBlackBerry.cpp:
      (WebCore::InspectorClientBlackBerry::InspectorClientBlackBerry):
      (WebCore::InspectorClientBlackBerry::canOverrideDeviceMetrics):
      (WebCore):
      (WebCore::InspectorClientBlackBerry::overrideDeviceMetrics):
      (WebCore::InspectorClientBlackBerry::supportsFrameInstrumentation):
      * WebCoreSupport/InspectorClientBlackBerry.h:
      (InspectorClientBlackBerry):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@121872 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      1e811c7f