1. 11 Jan, 2013 40 commits
    • fpizlo@apple.com's avatar
      If you use Phantom to force something to be live across an OSR exit, you... · 895e5bbc
      fpizlo@apple.com authored
      If you use Phantom to force something to be live across an OSR exit, you should put it after the OSR exit
      https://bugs.webkit.org/show_bug.cgi?id=106724
      
      Reviewed by Oliver Hunt.
              
      In cases where we were getting it wrong, I think it was benign because we would either already have an
      OSR exit prior to there, or the operand would be a constant.  But still, it's good to get this right.
      
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139540 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      895e5bbc
    • eae@chromium.org's avatar
      offsetWidth/height incorrect for images when zoomed · 2190f514
      eae@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106624
      
      Source/WebCore:
      
      Reviewed by Levi Weintraub.
      
      offsetWidth and height are incorrect for images at certain zoom
      levels due to flooring the values ones adjusted for zoom.
      By rounding the value instead we avoid the problem and return
      the right size.
      
      Test: fast/images/zoomed-offset-size.html
      
      * dom/Element.cpp:
      (WebCore::Element::offsetWidth):
      (WebCore::Element::offsetHeight):
      (WebCore::Element::clientWidth):
      (WebCore::Element::clientHeight):
      Change to round (as opposed to floor) the zoom adjusted value.
      
      * rendering/RenderObject.h:
      (WebCore::adjustLayoutUnitForAbsoluteZoom):
      * rendering/style/RenderStyle.h:
      (WebCore::adjustLayoutUnitForAbsoluteZoom):
      Add LayoutUnit version of adjustForAbsoluteZoom to avoid float
      conversion.
      
      LayoutTests:
      
      Reviewed by Levi Weintraub.
      
      Add test for offsetWidth/Height for zoomed image.
      
      * fast/images/zoomed-offset-size-expected.txt: Added.
      * fast/images/zoomed-offset-size.html: Added.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139537 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2190f514
    • ojan@chromium.org's avatar
      Fixed width overrides intrinsic min-width/max-width for text inputs and listboxes · ec03f916
      ojan@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106675
      
      Reviewed by Emil A Eklund.
      
      Source/WebCore:
      
      Implement computeIntrinsicLogicalWidths so that RenderBox::computeLogicalWidthInRegionUsing
      can get the correct intrinsic sizes instead of the preferred sizes.
      
      Test: fast/forms/select/listbox-intrinsic-min-width-applies-with-fixed-width.html
      
      * rendering/RenderListBox.cpp:
      (WebCore::RenderListBox::computeIntrinsicLogicalWidths):
      (WebCore):
      (WebCore::RenderListBox::computePreferredLogicalWidths):
      * rendering/RenderListBox.h:
      (RenderListBox):
      * rendering/RenderTextControl.cpp:
      (WebCore::RenderTextControl::computeIntrinsicLogicalWidths):
      (WebCore):
      (WebCore::RenderTextControl::computePreferredLogicalWidths):
      * rendering/RenderTextControl.h:
      (RenderTextControl):
      
      LayoutTests:
      
      * fast/forms/file/intrinsic-min-width-overrides-width-expected.html:
      * fast/forms/file/intrinsic-min-width-overrides-width.html:
      * fast/forms/select/listbox-intrinsic-min-width-applies-with-fixed-width-expected.html: Added.
      * fast/forms/select/listbox-intrinsic-min-width-applies-with-fixed-width.html: Added.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139536 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ec03f916
    • ojan@chromium.org's avatar
      Setting width overrides intrinsic min-width/max-width on flexboxes and their subclasses · 0b873891
      ojan@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106617
      
      Reviewed by Tony Chang.
      
      Source/WebCore:
      
      Override computeIntrinsicLogicalWidths for all RenderFlexibleBox and RenderDeprecatedFlexibleBox
      classes that override computePreferredLogicalWidths so that RenderBox can use
      computeIntrinsicLogicalWidths in order to get the correct intrinsic values.
      
      Tests: css3/flexbox/intrinsic-min-width-applies-with-fixed-width.html
             fast/flexbox/intrinsic-min-width-applies-with-fixed-width.html
             fast/forms/select/intrinsic-min-width-applies-with-fixed-width.html
      
      * rendering/RenderBox.cpp:
      (WebCore::RenderBox::computeLogicalWidthInRegionUsing):
      fit-content needs to use the intrinsic sizes not the preferred sizes
      since a fixed width overrides the preferred size.
      As best I can tell, the sizesLogicalWidthToFitContent codepath can keep
      using preferred widths, which are considerably faster, since that's only used
      computing width values. Added a clause to that if-statement to make this more
      explicit.
      
      * rendering/RenderDeprecatedFlexibleBox.cpp:
      (WebCore::RenderDeprecatedFlexibleBox::computeIntrinsicLogicalWidths):
      (WebCore::RenderDeprecatedFlexibleBox::computePreferredLogicalWidths):
      * rendering/RenderDeprecatedFlexibleBox.h:
      (RenderDeprecatedFlexibleBox):
      * rendering/RenderFlexibleBox.cpp:
      (WebCore::RenderFlexibleBox::computeIntrinsicLogicalWidths):
      (WebCore):
      (WebCore::RenderFlexibleBox::computePreferredLogicalWidths):
      * rendering/RenderFlexibleBox.h:
      * rendering/RenderMenuList.cpp:
      (WebCore::RenderMenuList::computeIntrinsicLogicalWidths):
      (WebCore):
      (WebCore::RenderMenuList::computePreferredLogicalWidths):
      * rendering/RenderMenuList.h:
      (RenderMenuList):
      * rendering/RenderSlider.cpp:
      (WebCore::RenderSlider::computeIntrinsicLogicalWidths):
      (WebCore):
      (WebCore::RenderSlider::computePreferredLogicalWidths):
      * rendering/RenderSlider.h:
      (RenderSlider):
      No logic changes in any of these computeIntrinsic methods. Just moving
      the code over from the computePreferred methods.
      
      LayoutTests:
      
      * css3/flexbox/intrinsic-min-width-applies-with-fixed-width-expected.txt: Added.
      * css3/flexbox/intrinsic-min-width-applies-with-fixed-width.html: Added.
      * fast/flexbox/intrinsic-min-width-applies-with-fixed-width-expected.txt: Added.
      * fast/flexbox/intrinsic-min-width-applies-with-fixed-width.html: Added.
      * fast/forms/select/intrinsic-min-width-applies-with-fixed-width-expected.html: Added.
      * fast/forms/select/intrinsic-min-width-applies-with-fixed-width.html: Added.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139535 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0b873891
    • tonyg@chromium.org's avatar
      Move HTMLTokenTypes to its own file · 04511b4a
      tonyg@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106722
      
      Reviewed by Levi Weintraub.
      
      Also mark AtomicHTMLToken ctor as explicit.
      
      No new tests because no new functionality.
      
      * GNUmakefile.list.am:
      * Target.pri:
      * WebCore.gypi:
      * WebCore.vcproj/WebCore.vcproj:
      * WebCore.xcodeproj/project.pbxproj:
      * html/parser/HTMLToken.h:
      (WebCore::AtomicHTMLToken::AtomicHTMLToken):
      * html/parser/HTMLTokenTypes.h: Added.
      (WebCore):
      (HTMLTokenTypes):
      (DoctypeData):
      (WebCore::HTMLTokenTypes::DoctypeData::DoctypeData):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139533 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      04511b4a
    • commit-queue@webkit.org's avatar
      WebWidgetClient::didHandleGestureEvent needs to distinguish the case if the... · 5401a183
      commit-queue@webkit.org authored
      WebWidgetClient::didHandleGestureEvent needs to distinguish the case if the event is processed or swallowed
      https://bugs.webkit.org/show_bug.cgi?id=104427
      
      Patch by Tien-Ren Chen <trchen@chromium.org> on 2013-01-11
      Reviewed by Adam Barth.
      
      When a gesture needs to be disambiguated, WebKit doesn't update cursor focus.
      We added an extra status for didHandleGestureEvent(), so we can distinguish
      the case whether the event is actually delivered to the web page or cancelled.
      
      * public/WebViewClient.h:
      * public/WebWidgetClient.h:
      (WebKit):
      (WebWidgetClient):
      (WebKit::WebWidgetClient::didHandleGestureEvent):
      * src/WebViewImpl.cpp:
      (WebKit::WebViewImpl::handleGestureEvent):
      * tests/WebViewTest.cpp:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139532 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5401a183
    • commit-queue@webkit.org's avatar
      [chromium] Add ContinuousPainter to call setNeedsDisplay on all layers... · ce39a91f
      commit-queue@webkit.org authored
      [chromium] Add ContinuousPainter to call setNeedsDisplay on all layers recursively in continuous painting mode
      https://bugs.webkit.org/show_bug.cgi?id=105458
      
      Patch by Eberhard Graether <egraether@google.com> on 2013-01-11
      Reviewed by James Robinson.
      
      In continuous painting mode all layers are constantly repainted to allow for life measurements of page paint time,
      while changing HTML and CSS using the WebInspector. This change adds the ContinuousPainter helper object, which
      calls setNeedsDisplay() on all GraphicsLayers recursively in order to force all layers to repaint. PageOverlay
      layers get excluded from being repainted, because their extra paint time is altering the page paint time metric.
      
      * WebKit.gyp:
      * src/PageOverlay.h:
      (WebKit::PageOverlay::graphicsLayer):
      (PageOverlay):
      * src/PageOverlayList.cpp:
      (WebKit::PageOverlayList::findGraphicsLayer):
      (WebKit):
      * src/PageOverlayList.h:
      (WebCore):
      (PageOverlayList):
      * src/WebViewImpl.cpp:
      (WebKit::WebViewImpl::WebViewImpl):
      (WebKit::WebViewImpl::didBeginFrame):
      * src/WebViewImpl.h:
      * src/painting/ContinuousPainter.cpp: Copied from Source/WebKit/chromium/src/PageOverlay.h.
      (WebKit):
      (WebKit::ContinuousPainter::setNeedsDisplayRecursive):
      * src/painting/ContinuousPainter.h: Copied from Source/WebKit/chromium/src/PageOverlay.h.
      (WebCore):
      (WebKit):
      (ContinuousPainter):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139531 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ce39a91f
    • commit-queue@webkit.org's avatar
      [BlackBerry] Focus zoom animation doesn't occur on devices with physical keyboard · 7805e7c5
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106719
      
      Patch by Andrew Lo <anlo@rim.com> on 2013-01-11
      Reviewed by Yong Li.
      Internally reviewed by Mike Fenton.
      
      Internal PR 278687
      
      Always ensureFocusTextElementVisible if an element is focused when
      the device has a physical keyboard.
      
      * WebKitSupport/InputHandler.cpp:
      (BlackBerry::WebKit::InputHandler::setElementFocused):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139530 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7805e7c5
    • esprehn@chromium.org's avatar
      No need to initialize RefPtrs to 0 in ElementRareData · 19b0120a
      esprehn@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106717
      
      Reviewed by Ryosuke Niwa.
      
      RefPtrs initialize themself to null, so there's no reason
      to do it manually. This was code leftover from when
      PseudoElements were stored in bare ptrs instead of in
      RefPtrs.
      
      No new tests, just refactoring.
      
      * dom/ElementRareData.h:
      (WebCore::ElementRareData::ElementRareData):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139529 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      19b0120a
    • fpizlo@apple.com's avatar
      Phantom(GetLocal) should be treated as relevant to OSR · d6083f10
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106715
      
      Reviewed by Mark Hahnenberg.
      
      Source/JavaScriptCore: 
      
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::performBlockCSE):
      
      LayoutTests: 
      
      * fast/js/dfg-phantom-get-local-expected.txt: Added.
      * fast/js/dfg-phantom-get-local.html: Added.
      * fast/js/jsc-test-list:
      * fast/js/script-tests/dfg-phantom-get-local.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139528 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d6083f10
    • commit-queue@webkit.org's avatar
      [TexMap] Rename current[Transform|Opacity|Filters] in TextureMapperLayer. · a254b375
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=105760
      
      Patch by Huang Dongsung <luxtella@company100.net> on 2013-01-11
      Reviewed by Noam Rosenthal.
      
      Source/WebCore:
      
      TextureMapperLayer has two transform members: an original value and a
      changeable value. The changeable value would be changed by animations.
      This patch puts 'current' prefix on the changeable value to clarify
      its purpose. Opacity and filters ditto.
      
      No new tests. Refactoring only.
      
      * platform/graphics/texmap/TextureMapperLayer.cpp:
      (WebCore::TextureMapperLayer::computeTransformsRecursive):
      (WebCore::TextureMapperLayer::paintSelf):
      (WebCore::TextureMapperLayer::paintSelfAndChildren):
      (WebCore::TextureMapperLayer::intermediateSurfaceRect):
      (WebCore::TextureMapperLayer::shouldPaintToIntermediateSurface):
      (WebCore::TextureMapperLayer::isVisible):
      (WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica):
      (WebCore::TextureMapperLayer::paintRecursive):
      (WebCore::TextureMapperLayer::flushCompositingStateForThisLayerOnly):
      (WebCore::TextureMapperLayer::syncAnimations):
      (WebCore::TextureMapperLayer::setScrollPositionDeltaIfNeeded):
      * platform/graphics/texmap/TextureMapperLayer.h:
      (WebCore::TextureMapperLayer::TextureMapperLayer):
      (TextureMapperLayer):
      (WebCore::TextureMapperLayer::State::State):
      
      Source/WebKit/qt:
      
      TextureMapperLayerClientQt uses setTransform() and setOpacity() in
      GraphicsLayer instead of TextureMapperLayer like LayerTreeRenderer.
      This removes unnecessary public API for TextureMapperLayer.
      
      * WebCoreSupport/TextureMapperLayerClientQt.cpp:
      (TextureMapperLayerClientQt::renderCompositedLayers):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139526 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a254b375
    • commit-queue@webkit.org's avatar
      Coordinated Graphics: Remove the dependency of WebCoordinatedSurface::Handle... · 93f7b524
      commit-queue@webkit.org authored
      Coordinated Graphics: Remove the dependency of WebCoordinatedSurface::Handle from Coordinated Graphics.
      https://bugs.webkit.org/show_bug.cgi?id=104347
      
      Patch by Huang Dongsung <luxtella@company100.net> on 2013-01-11
      Reviewed by Noam Rosenthal.
      
      It is a preparation patch for Threaded Coordinated Graphics on WK1.
      
      Currently, UpdateAtlas and CoordinatedImageBacking use
      WebCoordinatedSurface::Handle, but WebCoordinatedSurface::Handle can be
      used only IPC-based Coordinated Graphics. So this patch removes the
      dependency of WebCoordinatedSurface::Handle from UpdateAtlas and
      CoordinatedImageBacking. Now CoordinatedLayerTreeHost converts the
      handle to a WebCoordinatedSurface.
      
      * WebProcess/WebPage/CoordinatedGraphics/CoordinatedImageBacking.cpp:
      (WebKit::CoordinatedImageBacking::update):
      (WebKit::CoordinatedImageBacking::releaseSurfaceIfNeeded):
      * WebProcess/WebPage/CoordinatedGraphics/CoordinatedImageBacking.h:
      (Coordinator):
      (CoordinatedImageBacking):
      * WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:
      (WebKit::CoordinatedLayerTreeHost::updateImageBacking):
      (WebKit::CoordinatedLayerTreeHost::createUpdateAtlas):
      * WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.h:
      (WebKit):
      (CoordinatedLayerTreeHost):
      * WebProcess/WebPage/CoordinatedGraphics/UpdateAtlas.cpp:
      (WebKit::UpdateAtlas::UpdateAtlas):
      (WebKit::UpdateAtlas::~UpdateAtlas):
      (WebKit::UpdateAtlas::beginPaintingOnAvailableBuffer):
      * WebProcess/WebPage/CoordinatedGraphics/UpdateAtlas.h:
      (UpdateAtlasClient):
      (UpdateAtlas):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139525 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      93f7b524
    • tonyg@chromium.org's avatar
      Move constructTreeFromHTMLToken into HTMLDocumentParser · 639188a8
      tonyg@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106694
      
      Reviewed by Adam Barth.
      
      This way it will sit parallel to a new constructTreeFromCompactHTMLToken method.
      
      No new tests because no new functionality.
      
      * html/parser/HTMLDocumentParser.cpp:
      (WebCore::HTMLDocumentParser::pumpTokenizer):
      (WebCore::HTMLDocumentParser::constructTreeFromHTMLToken):
      (WebCore):
      * html/parser/HTMLDocumentParser.h:
      * html/parser/HTMLTreeBuilder.cpp:
      * html/parser/HTMLTreeBuilder.h:
      (HTMLTreeBuilder):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139523 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      639188a8
    • commit-queue@webkit.org's avatar
      Explicitly set msvs_cygwin_shell to true for actions in WebKit · f87b4290
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106706
      
      Patch by Robert Iannucci <iannucci@chromium.org> on 2013-01-11
      Reviewed by Tony Chang.
      
      Currently, msvs_cygwin_shell is set to 1 by default. This patch
      explicitly sets it on the actions which will break if msvs_cygwin_shell
      were set to 0. This is in preparation for changing the default value of
      msvs_cygwin_shell, which in turn is in preparation of the removal of
      cygwin as a buld-system requirement.
      
      Since this change will have no semantic effect, no new tests are
      required.
      
      * WebCore.gyp/WebCore.gyp:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      f87b4290
    • commit-queue@webkit.org's avatar
      [BlackBerry] Modifying the databaseQuota call to WebPageClient · 8348e12b
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106703
      
      Patch by Otto Derek Cheung <otcheung@rim.com> on 2013-01-11
      Reviewed by Yong Li.
      
      The databaseQuota call in WebPageClientImpl is modified to take in
      BP:Strings directly. Also, we want to use the origin URL from the security origin.
      Not the database identifier.
      
      * Api/WebPageClient.h:
      * WebCoreSupport/ChromeClientBlackBerry.cpp:
      (WebCore::ChromeClientBlackBerry::exceededDatabaseQuota):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139519 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8348e12b
    • jsbell@chromium.org's avatar
      IndexedDB: IDBTransaction should manage lifetime of IDBRequests · 340f1c19
      jsbell@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106678
      
      Reviewed by Tony Chang.
      
      Ensure reference count of IDBRequests don't bounce off zero if there are no script
      references are while the events are arriving.
      
      No new tests - no detectable behavior changes.
      
      * Modules/indexeddb/IDBRequest.cpp:
      (WebCore::IDBRequest::create): Register with transaction (which now takes a ref) here to...
      (WebCore::IDBRequest::IDBRequest): ...avoid having to relax adoption requirements here.
      * Modules/indexeddb/IDBTransaction.cpp: Keep RefPtr<>s to outstanding requests.
      (WebCore::IDBTransaction::~IDBTransaction):
      (WebCore::IDBTransaction::abort):
      (WebCore::IDBTransaction::onAbort):
      * Modules/indexeddb/IDBTransaction.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139518 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      340f1c19
    • ap@apple.com's avatar
      [WK2] Network process unblocks all waiting threads when any sync reply arrives · 76813418
      ap@apple.com authored
              https://bugs.webkit.org/show_bug.cgi?id=106713
      
              Reviewed by Brady Eidson.
      
              Switch to sending sync CoreIPC messages, which is now possible.
      
              * NetworkProcess/NetworkConnectionToWebProcess.h:
              * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::didClose):
              We no longer have response maps.
      
              * NetworkProcess/NetworkResourceLoader.cpp:
              (WebKit::NetworkResourceLoader::willSendRequest): Just send a sync message.
              (WebKit::NetworkResourceLoader::canAuthenticateAgainstProtectionSpace): Ditto.
              (WebKit::NetworkResourceLoader::didReceiveDataArray): Added an unrelated assertion.
      
              * NetworkProcess/NetworkResourceLoader.h:
              * NetworkProcess/NetworkResourceLoader.messages.in:
              Removed no longer used reply messages and their handlers.
      
              * Shared/BlockingResponseMap.h: Removed a bool version, which was not perfectly
              safe, and only used in NetworkProcess.
              (BlockingResponseMap::didReceiveResponse): Updated a still valid FIXME to not refer
              to network process.
              (BlockingResponseMap::cancel): Ditto.
      
              * WebProcess/Network/NetworkProcessConnection.h:
              * WebProcess/Network/NetworkProcessConnection.cpp:
              (WebKit::NetworkProcessConnection::didReceiveSyncMessage):
              Plumbing to handle sync messages.
      
              * WebProcess/Network/WebResourceLoader.cpp:
              (WebKit::WebResourceLoader::willSendRequest):
              (WebKit::WebResourceLoader::canAuthenticateAgainstProtectionSpace):
              * WebProcess/Network/WebResourceLoader.h:
              * WebProcess/Network/WebResourceLoader.messages.in:
              Updated (simplified) sync messages and their handlers.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139516 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      76813418
    • ap@apple.com's avatar
      [WK2] Make it possible to send sync messages from secondary threads · 736e0542
      ap@apple.com authored
              https://bugs.webkit.org/show_bug.cgi?id=106708
      
              Apply another review comment (overlooked a "ditto").
      
              * Platform/CoreIPC/Connection.cpp:
              (CoreIPC::Connection::sendSyncMessage):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      736e0542
    • ap@apple.com's avatar
      [WK2] Make it possible to send sync messages from secondary threads · 4104765a
      ap@apple.com authored
              https://bugs.webkit.org/show_bug.cgi?id=106708
      
              Reviewed by Anders Carlsson.
      
              It is hugely beneficial to implement sync messages at Connection level, because
              ad hoc code that blocks a thread and wakes it up when a reply arrives on main
              thread can't be made equally performant. A CoreOPC MessageDecoder can be moved across
              threads, which can't be done with a decoded argument passed by reference to client code.
      
              Sync messages from secondary threads are tracked in much simpler data structure
              than client thread ones, because we don't need to be concerned with incoming messages.
      
              * Platform/CoreIPC/Connection.cpp:
              (Connection::SecondaryThreadPendingSyncReply):
              (CoreIPC::Connection::SecondaryThreadPendingSyncReply::SecondaryThreadPendingSyncReply):
              (CoreIPC::Connection::createSyncMessageEncoder):
              (CoreIPC::Connection::sendSyncMessage):
              (CoreIPC::Connection::sendSyncMessageFromSecondaryThread):
              (CoreIPC::Connection::processIncomingSyncReply):
              (CoreIPC::Connection::connectionDidClose):
      
              * Platform/CoreIPC/Connection.h: Also corrected a misleading comment.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139514 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4104765a
    • simonjam@chromium.org's avatar
      [Resource Timing] XMLHttpRequests should have initiator type 'xmlhttprequest' · c29cfd5d
      simonjam@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106409
      
      Reviewed by Nate Chapin.
      
      Source/WebCore:
      
      The initiator is passed through ThreadableLoaderOptions to the CachedResourceRequest. This is
      optional, so other users of ThreadableLoader will have the default initiator of 'request'. Note
      that synchronous XHRs don't show up in the Resource Timing buffer yet.
      
      Test: http/tests/w3c/webperf/submission/resource-timing/html/test_resource_initiator_types.html
      
      * loader/DocumentThreadableLoader.cpp:
      (WebCore::DocumentThreadableLoader::loadRequest):
      * loader/ThreadableLoader.h:
      (ThreadableLoaderOptions):
      * loader/cache/CachedResourceRequestInitiators.cpp:
      (WebCore::CachedResourceRequestInitiators::CachedResourceRequestInitiators):
      * loader/cache/CachedResourceRequestInitiators.h:
      (CachedResourceRequestInitiators):
      * xml/XMLHttpRequest.cpp:
      (WebCore::XMLHttpRequest::createRequest):
      
      LayoutTests:
      
      * http/tests/w3c/webperf/resources/all_resource_types.htm:
      * http/tests/w3c/webperf/submission/resource-timing/html/test_resource_initiator_types-expected.txt:
      * http/tests/w3c/webperf/submission/resource-timing/html/test_resource_initiator_types.html:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139513 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c29cfd5d
    • tony@chromium.org's avatar
      Unreviewed, revert r139157 to fix the chromium build. · 7337be91
      tony@chromium.org authored
      These files were deleted in a follow up and since r139044 was reverted, we need to
      add back these files.
      
      * WebKit.gyp:
      * src/DragScrollTimer.cpp: Added.
      (WebKit):
      (WebKit::distanceToRect):
      (WebKit::DragScrollTimer::DragScrollTimer):
      (WebKit::DragScrollTimer::~DragScrollTimer):
      (WebKit::DragScrollTimer::stop):
      (WebKit::DragScrollTimer::scroll):
      (WebKit::DragScrollTimer::update):
      (WebKit::DragScrollTimer::triggerScroll):
      (WebKit::DragScrollTimer::scrollDistanceFor):
      * src/DragScrollTimer.h: Added.
      (WebKit):
      (DragScrollTimer):
      (WebKit::DragScrollTimer::fired):
      (WebKit::DragScrollTimer::shouldScroll):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139511 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7337be91
    • psolanki@apple.com's avatar
      Fix function name typo ProgramExecutable::initalizeGlobalProperties() · b70d9c3f
      psolanki@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106701
      
      Reviewed by Geoffrey Garen.
      
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::execute):
      * runtime/Executable.cpp:
      (JSC::ProgramExecutable::initializeGlobalProperties):
      * runtime/Executable.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139510 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b70d9c3f
    • simonjam@chromium.org's avatar
      Restore old semantics to webkitRequestAnimationFrame callbacks · 9fa00ef8
      simonjam@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106697
      
      Reviewed by James Robinson.
      
      Source/WebCore:
      
      Sites that use GWT <= 2.4 are buggy and rely on Date.now()-like callback values.
      We'll restore that behavior to the prefixed version of webkitRequestAnimationFrame.
      requestAnimationFrame will continue to follow the spec.
      
      Test: fast/animation/request-animation-frame-prefix.html
      
      * dom/RequestAnimationFrameCallback.h:
      (RequestAnimationFrameCallback):
      * dom/ScriptedAnimationController.cpp:
      (WebCore::ScriptedAnimationController::serviceScriptedAnimations):
      * page/DOMWindow.cpp:
      (WebCore::DOMWindow::requestAnimationFrame):
      (WebCore):
      (WebCore::DOMWindow::webkitRequestAnimationFrame):
      * page/DOMWindow.h:
      (DOMWindow):
      * page/DOMWindow.idl:
      
      LayoutTests:
      
      * fast/animation/request-animation-frame-prefix-expected.txt: Added.
      * fast/animation/request-animation-frame-prefix.html: Added.
      * fast/animation/script-tests/request-animation-frame-prefix.js: Added.
      (busyWait):
      (window.webkitRequestAnimationFrame):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139509 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9fa00ef8
    • mhahnenberg@apple.com's avatar
      testapi is failing with a block-related error in the Objc API · bf1fd77c
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106055
      
      Reviewed by Filip Pizlo.
      
      Same bug as in testapi.mm. We need to actually call the static block, rather than casting the block to a bool.
      
      * API/ObjCCallbackFunction.mm:
      (blockSignatureContainsClass):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139508 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      bf1fd77c
    • fpizlo@apple.com's avatar
      Add a run-time option to print bytecode at DFG compile time · 067902be
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106704
      
      Reviewed by Mark Hahnenberg.
      
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseCodeBlock):
      * runtime/Options.h:
      (JSC):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139506 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      067902be
    • commit-queue@webkit.org's avatar
      Unreviewed, rolling out r139044. · 2e62898f
      commit-queue@webkit.org authored
      http://trac.webkit.org/changeset/139044
      https://bugs.webkit.org/show_bug.cgi?id=106702
      
      Caused various scrolling anomolies on Mac with drag and drop
      (Requested by smfr on #webkit).
      
      Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2013-01-11
      
      Source/WebCore:
      
      * page/AutoscrollController.cpp:
      (WebCore::AutoscrollController::AutoscrollController):
      (WebCore::AutoscrollController::autoscrollTimerFired):
      * page/AutoscrollController.h:
      (WebCore):
      (AutoscrollController):
      * page/EventHandler.cpp:
      (WebCore::EventHandler::updateDragAndDrop):
      * rendering/RenderBox.cpp:
      (WebCore):
      (WebCore::RenderBox::autoscroll):
      * rendering/RenderBox.h:
      (RenderBox):
      * rendering/RenderLayer.cpp:
      (WebCore::RenderLayer::autoscroll):
      * rendering/RenderLayer.h:
      (RenderLayer):
      * rendering/RenderListBox.cpp:
      (WebCore::RenderListBox::autoscroll):
      * rendering/RenderListBox.h:
      (RenderListBox):
      * rendering/RenderTextControlSingleLine.cpp:
      (WebCore::RenderTextControlSingleLine::autoscroll):
      * rendering/RenderTextControlSingleLine.h:
      (RenderTextControlSingleLine):
      
      Source/WebKit/chromium:
      
      * src/WebViewImpl.cpp:
      (WebKit::WebViewImpl::WebViewImpl):
      (WebKit::WebViewImpl::dragSourceEndedAt):
      (WebKit::WebViewImpl::dragSourceMovedTo):
      (WebKit::WebViewImpl::dragTargetDrop):
      (WebKit::WebViewImpl::dragTargetDragEnterOrOver):
      * src/WebViewImpl.h:
      (WebKit):
      
      LayoutTests:
      
      * fast/events/drag-and-drop-autoscroll-expected.txt: Removed.
      * fast/events/drag-and-drop-autoscroll.html: Removed.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139503 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2e62898f
    • rafaelw@chromium.org's avatar
      Prevent HTMLPreloadScanner from fetching resources inside <template> · 6405bd06
      rafaelw@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106687
      
      Reviewed by Adam Barth.
      
      Source/WebCore:
      
      This patch adds a simple counter to the preload scanner which increments on template start
      tag and decrements on template element. It only fetchs resources when the counter is at zero
      (i.e. for elements not contained by a template element).
      
      Test re-enabled within fast/dom/HTMLTemplateElement/inertContents.html
      
      * html/parser/HTMLPreloadScanner.cpp:
      (WebCore::HTMLPreloadScanner::HTMLPreloadScanner):
      (WebCore::HTMLPreloadScanner::processToken):
      * html/parser/HTMLPreloadScanner.h:
      (HTMLPreloadScanner):
      
      LayoutTests:
      
      * fast/dom/HTMLTemplateElement/inertContents-expected.txt:
      * fast/dom/HTMLTemplateElement/inertContents.html:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139502 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6405bd06
    • mitz@apple.com's avatar
      Exclude unused resources. · aa696242
      mitz@apple.com authored
      Reviewed by Darin Adler.
      
      * Configurations/WebKit2.xcconfig: Defined EXCLUDED_SOURCE_FILE_NAMES.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139500 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      aa696242
    • tonyg@chromium.org's avatar
      We should be able to checkpoint and restore the HTMLTokenizer across threads · 348d5f03
      tonyg@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106597
      
      Based on patch by Adam Barth.
      
      This has the ability to create a checkpoint any time the parser is blocked on a script.
      We clear m_appropriateEndTagName after each end tag is flushed so that the ASSERT in
      canCreateCheckpoint() will pass.
      
      Reviewed by Adam Barth.
      
      No new tests because no new functionality.
      
      * html/parser/HTMLDocumentParser.cpp:
      (WebCore::HTMLDocumentParser::HTMLDocumentParser):
      (WebCore::HTMLDocumentParser::pumpTokenizer):
      * html/parser/HTMLDocumentParser.h:
      (WebCore):
      (HTMLDocumentParser):
      * html/parser/HTMLTokenizer.cpp:
      (WebCore):
      (WebCore::HTMLTokenizer::canCreateCheckpoint):
      (WebCore::HTMLTokenizer::createCheckpoint):
      (WebCore::HTMLTokenizer::restoreFromCheckpoint):
      * html/parser/HTMLTokenizer.h:
      (HTMLTokenizer):
      (Checkpoint):
      (WebCore::HTMLTokenizer::Checkpoint::Checkpoint):
      * xml/parser/MarkupTokenizerBase.h:
      (WebCore::MarkupTokenizerBase::InputStreamPreprocessor::InputStreamPreprocessor):
      (WebCore::MarkupTokenizerBase::InputStreamPreprocessor::skipNextNewLine):
      (InputStreamPreprocessor):
      (WebCore::MarkupTokenizerBase::InputStreamPreprocessor::reset):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139497 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      348d5f03
    • fpizlo@apple.com's avatar
      It should be possible to enable verbose printing of each OSR exit at run-time... · 03e446e2
      fpizlo@apple.com authored
      It should be possible to enable verbose printing of each OSR exit at run-time (rather than compile-time) and it should print register state
      https://bugs.webkit.org/show_bug.cgi?id=106700
      
      Reviewed by Mark Hahnenberg.
      
      * dfg/DFGAssemblyHelpers.h:
      (DFG):
      (JSC::DFG::AssemblyHelpers::debugCall):
      * dfg/DFGCommon.h:
      * dfg/DFGOSRExit.h:
      (DFG):
      * dfg/DFGOSRExitCompiler32_64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGOSRExitCompiler64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * runtime/Options.h:
      (JSC):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139496 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      03e446e2
    • tony@chromium.org's avatar
      [chromium] Don't regenerate all bindings when any idl file changes · 0d0acd60
      tony@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=106604
      
      Reviewed by Kentaro Hara.
      
      Source/WebCore:
      
      Currently, every idl file is a dependency of generating the supplemental dependency map
      and generating bindings is a dependency of the map. This means that touching any idl file
      causes us to regenerate all the bindings.
      
      Change it so that generating bindings only depends on the idl files that have Supplemental= in them.
      We only have 24 idl files with Supplemental (3.7% of the 638 idl files in WebCore) so modifying
      any of those will cause all bindings to be regenerated.
      
      If you add or remove a new idl file, you have to rerun gyp which will fix up any dependencies.
      If you edit an existing file and add Supplemental= to it, you will now need to rerun gyp_{webkit,chromium}.
      I think that's a reasonable tradeoff since it seems highly unlikely that you would adding Supplemental=
      to an existing file without renaming it. The bots will always be fine because they always run
      gyp after updating.
      
      No new tests, this is a build only change.
      
      * WebCore.gyp/WebCore.gyp: Remove <(SHARED_INTERMEDIATE_DIR)/supplemental_dependency.tmp, which was causing
      the full rebuild. The step to generate this file is still a hard dependency so it will still be generated and
      used by generate-bindings.pl. Also remove <@(webcore_test_support_idl_files). This was saying we should regenerate
      all bindings if a test idl file changed. That doesn't make sense.
      * WebCore.gyp/scripts/supplemental_idl_files.py: Added.
      (DoMain):
      
      Source/WebKit/chromium:
      
      * gyp_webkit: Add Source/WebCore/WebCore.gyp/scripts to the python import search path
      so we can generate idl dependencies at gyp time.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139494 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0d0acd60
    • achicu@adobe.com's avatar
      Element is displayed behind a composited layer when clipping is used on a previous element · 23593abb
      achicu@adobe.com authored
      https://bugs.webkit.org/show_bug.cgi?id=104981
      
      Reviewed by Simon Fraser.
      
      Source/WebCore:
      
      RenderLayerCompositor::computeCompositingRequirements uses the local bounding box of the layers to optimize the number of composited
      layers that are created. That's needed in order to make sure that composited layers that are displayed behind non-composited
      layers are correctly promoting the layers in front to be composited. Otherwise the non-composited layers are rendered
      in the parent composited layer, displaying behind the other composited layers. That might be wrong as the correct paint order might not be
      preserved.
      
      In order to make animations work, there's a flag that will disable that optimization. That's because the animations run in the platform
      layer and the platform layer doesn't know about the layers that are not promoted to composited layers. When the overlapping of the layers
      is computed it just uses the start or the stop state, but no intermediate states. For that reason, all the 'top' layers in front of animated
      elements will become composited.
      
      When an animation has a clipping rectangle, then we know for sure that the animation is going to be contained inside the clip area, so WebKit
      uses the bounding box of the clipping area to detect the overlapping layers, so there's no need to disable the optimization in that case.
      
      However, if there is a different animation displaying behind the clipping container, we cannot safely disable that optimization anymore. That's
      because we still don't know what are the intermediate states of that particular animated layer. The bug was that the optimization was re-enabled
      anyway, even in this particular case.
      
      In order to fix it, I changed the logic, so that instead of re-enabling the optimization after a clipping container, it will just avoid to propagate
      the internal state to the following layers when there's no need to so.
      
      Note that 3D transforms behave like animations for now and disable the optimization. Because of that some of the existing tests ended up
      creating more layers than needed. That's because the tests had an overflow area that recreated the issue that this patch fixes, but with
      3D transforms instead of animations. 3D transforms will be treated in a separate patch.
      
      Tests: compositing/layer-creation/overlap-animation-clipping.html
             compositing/layer-creation/overlap-animation-container.html
      
      * rendering/RenderLayerCompositor.cpp:
      (WebCore::RenderLayerCompositor::computeCompositingRequirements):
      
      LayoutTests:
      
      Updated existing test results and added two new tests to check that animations respect the correct paint order,
      even though they are painted with composited layers.
      
      Note that there are side effects of this patch that will be corrected in a following bug. 3D layers are treated like animations, so they
      disable the overlapping optimizations. Because of that, some of the test results were updated to include the layers that, previously,
      were not created as a result of being in front of a "clipping container".
      
      * compositing/geometry/foreground-layer-expected.txt:
      * compositing/layer-creation/overlap-animation-clipping-expected.txt: Added.
      * compositing/layer-creation/overlap-animation-clipping.html: Added. Checking that the animation inside a clipping container is not
      affecting how we compute the animations outside the clipping container.
      * compositing/layer-creation/overlap-animation-container-expected.txt: Added.
      * compositing/layer-creation/overlap-animation-container.html: Added. Checking that we don't create unnecessary composited layers for layers inside
      composited containers that draw in front of animated layers.
      * compositing/overflow/clip-descendents-expected.txt:
      * compositing/overflow/clip-descendents.html: Removed the text from the output, so that platforms can share the same expected result.
      * platform/chromium-win/compositing/overflow/clip-descendents-expected.txt: Removed. Not needed anymore, all Chromium platforms can share the same results now.
      * platform/chromium/compositing/geometry/foreground-layer-expected.txt:
      * platform/chromium/compositing/layer-creation/overlap-animation-clipping-expected.txt: Added.
      * platform/chromium/compositing/layer-creation/overlap-animation-container-expected.txt: Added.
      * platform/chromium/compositing/layer-creation/overlap-transformed-3d-expected.txt: Added.
      * platform/chromium/compositing/layer-creation/overlap-transforms-expected.txt:
      * platform/chromium/compositing/overflow/clip-descendents-expected.txt: Renamed from LayoutTests/platform/chromium-mac/compositing/overflow/clip-descendents-expected.txt.
      * platform/qt/compositing/overflow/clip-descendents-expected.txt:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139493 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      23593abb
    • ggaren@apple.com's avatar
      Removed getDirectLocation and offsetForLocation and all their uses · 329c1534
      ggaren@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106692
      
      Reviewed by Filip Pizlo.
      
      getDirectLocation() and its associated offsetForLocation() relied on
      detailed knowledge of the rules of PropertyOffset, JSObject, and
      Structure, which is a hard thing to reverse-engineer reliably. Luckily,
      it wasn't needed, and all clients either wanted a true value or a
      PropertyOffset. So, I refactored accordingly.
      
      * dfg/DFGOperations.cpp: Renamed putDirectOffset to putDirect, to clarify
      that we are not putting an offset.
      
      * runtime/JSActivation.cpp:
      (JSC::JSActivation::getOwnPropertySlot): Get a value instead of a value
      pointer, since we never wanted a pointer to begin with.
      
      * runtime/JSFunction.cpp:
      (JSC::JSFunction::getOwnPropertySlot): Use a PropertyOffset instead of a pointer,
      so we don't have to reverse-engineer the offset from the pointer.
      
      * runtime/JSObject.cpp:
      (JSC::JSObject::put):
      (JSC::JSObject::resetInheritorID):
      (JSC::JSObject::inheritorID):
      (JSC::JSObject::removeDirect):
      (JSC::JSObject::fillGetterPropertySlot):
      (JSC::JSObject::getOwnPropertyDescriptor): Renamed getDirectOffset and
      putDirectOffset, as explaind above. We want to use the name "getDirectOffset"
      for when the thing you're getting is the offset.
      
      * runtime/JSObject.h:
      (JSC::JSObject::getDirect):
      (JSC::JSObject::getDirectOffset): Changed getDirectLocation to getDirectOffset,
      since clients really wants PropertyOffsets and not locations.
      
      (JSObject::offsetForLocation): Removed this function because it was hard
      to get right.
      
      (JSC::JSObject::putDirect):
      (JSC::JSObject::putDirectUndefined):
      (JSC::JSObject::inlineGetOwnPropertySlot):
      (JSC::JSObject::putDirectInternal):
      (JSC::JSObject::putDirectWithoutTransition):
      * runtime/JSScope.cpp:
      (JSC::executeResolveOperations):
      (JSC::JSScope::resolvePut):
      * runtime/JSValue.cpp:
      (JSC::JSValue::putToPrimitive): Updated for renames.
      
      * runtime/Lookup.cpp:
      (JSC::setUpStaticFunctionSlot): Use a PropertyOffset instead of a pointer,
      so we don't have to reverse-engineer the offset from the pointer.
      
      * runtime/Structure.cpp:
      (JSC::Structure::flattenDictionaryStructure): Updated for renames.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139491 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      329c1534
    • ggaren@apple.com's avatar
      Removed an unused version of getDirectLocation · a70da946
      ggaren@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106691
      
      Reviewed by Gavin Barraclough.
      
      getDirectLocation is a weird operation. Removing the unused version is
      the easy part.
      
      * runtime/JSObject.h:
      (JSObject):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139488 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a70da946
    • fpizlo@apple.com's avatar
      Add WTF_EXPORT_PRIVATE to printInternal() methods of PrintStream.h · e23405c9
      fpizlo@apple.com authored
      Rubber stamped by Mark Hahnenberg.
              
      This will make it easier to use dataLog() from WebCore.
      
      * wtf/PrintStream.h:
      (WTF):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139487 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e23405c9
    • mhahnenberg@apple.com's avatar
      Objective-C objects that are passed to JavaScript leak (until the JSContext is destroyed) · 211015ec
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106056
      
      Reviewed by Darin Adler.
      
      * API/APIJSValue.h:
      * API/JSValue.mm: Make the reference to the JSContext strong.
      (-[JSValue context]):
      (-[JSValue initWithValue:inContext:]):
      (-[JSValue dealloc]):
      * API/JSWrapperMap.mm: Make the reference back from wrappers to Obj-C objects weak instead of strong.
      Also add an explicit WeakGCMap in the JSWrapperMap rather than using Obj-C associated object API which 
      was causing memory leaks.
      (wrapperClass):
      (-[JSObjCClassInfo wrapperForObject:]):
      (-[JSWrapperMap initWithContext:]):
      (-[JSWrapperMap dealloc]):
      (-[JSWrapperMap wrapperForObject:]):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139486 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      211015ec
    • pdr@google.com's avatar
      Skip CachedImage::CreateImage if we don't have image data · 13577c50
      pdr@google.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106156
      
      Reviewed by Nate Chapin.
      
      This patch skips image creation if we do not have image data. This can occur during
      cache revalidation when the revalidation request (304 not modified) comes back without
      any content. In this revalidation case, the http spec requires that a mimetype not be set
      on the response to prevent a cached resource from having a different mimetype
      from the revalidated resource. Because revalidation requests do not have a mimetype,
      CachedImage::CreateImage() will fail on SVG images. This patch prevents
      CachedImage::CreateImage() from being called during revalidation.
      
      No new tests as there are no observable changes from this patch.
      
      * loader/cache/CachedImage.cpp:
      (WebCore::CachedImage::data):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139484 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      13577c50
    • haraken@chromium.org's avatar
      Unreviewed. Rebaselined run-bindings-tests. · 37ad4103
      haraken@chromium.org authored
      * bindings/scripts/test/V8/V8TestEventConstructor.cpp:
      (WebCore::TestEventConstructorV8Internal::attr1AttrGetter):
      (WebCore::TestEventConstructorV8Internal::attr2AttrGetter):
      * bindings/scripts/test/V8/V8TestException.cpp:
      (WebCore::TestExceptionV8Internal::nameAttrGetter):
      * bindings/scripts/test/V8/V8TestInterface.cpp:
      (WebCore::TestInterfaceV8Internal::supplementalStaticAttrAttrGetter):
      (WebCore::TestInterfaceV8Internal::supplementalStr1AttrGetter):
      (WebCore::TestInterfaceV8Internal::supplementalStr2AttrGetter):
      * bindings/scripts/test/V8/V8TestObj.cpp:
      (WebCore::TestObjV8Internal::readOnlyStringAttrAttrGetter):
      (WebCore::TestObjV8Internal::staticStringAttrAttrGetter):
      (WebCore::TestObjV8Internal::stringAttrAttrGetter):
      (WebCore::TestObjV8Internal::reflectedStringAttrAttrGetter):
      (WebCore::TestObjV8Internal::reflectedURLAttrAttrGetter):
      (WebCore::TestObjV8Internal::reflectedCustomURLAttrAttrGetter):
      (WebCore::TestObjV8Internal::stringAttrWithGetterExceptionAttrGetter):
      (WebCore::TestObjV8Internal::stringAttrWithSetterExceptionAttrGetter):
      (WebCore::TestObjV8Internal::hashAttrGetter):
      (WebCore::TestObjV8Internal::conditionalMethod1Callback):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139483 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      37ad4103
    • ggaren@apple.com's avatar
      Fixed some bogus PropertyOffset ASSERTs · 338bd6f3
      ggaren@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106686
      
      Reviewed by Gavin Barraclough.
      
      The ASSERTs were passing a JSType instead of an inlineCapacity, due to
      an incomplete refactoring.
      
      The compiler didn't catch this because both types are int underneath.
      
      * runtime/JSObject.h:
      (JSC::JSObject::getDirect):
      (JSC::JSObject::getDirectLocation):
      (JSC::JSObject::offsetForLocation):
      * runtime/Structure.cpp:
      (JSC::Structure::addPropertyTransitionToExistingStructure): Validate against
      our inline capacity, as we intended.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139482 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      338bd6f3
    • ggaren@apple.com's avatar
      Rename propertyOffsetFor => offsetForPropertyNumber · efd32fb2
      ggaren@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106685
      
      Reviewed by Gavin Barraclough.
      
      Since the argument is just a typedef and not an object, I wanted to clarify the meaning.
      
      * runtime/PropertyMapHashTable.h:
      (JSC::PropertyTable::nextOffset): Updated for rename.
      
      * runtime/PropertyOffset.h:
      (JSC::offsetForPropertyNumber): Renamed. Also changed some PropertyOffset variables
      to plain ints, because they're not actually on the PropertyOffsets number line.
      
      * runtime/Structure.cpp:
      (JSC::Structure::flattenDictionaryStructure):
      * runtime/Structure.h:
      (JSC::Structure::lastValidOffset): Updated for rename.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139481 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      efd32fb2