1. 23 Jul, 2013 23 commits
  2. 22 Jul, 2013 17 commits
    • bdakin@apple.com's avatar
      StickyPositionConstraints should store the constrainingRectAtLastLayout · 21bd1024
      bdakin@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118999
      
      Reviewed by Simon Fraser.
      
      Much like how FixedPositionConstraints store a viewportRectAtLastLayout, 
      StickyConstraints should store a constrainingRectAtLastLayout. We'll need this to 
      get sticky right in overflow areas once overflow areas scroll on the scrolling 
      thread. 
      
      * page/scrolling/ScrollingConstraints.h:
      (WebCore::StickyPositionViewportConstraints::StickyPositionViewportConstraints):
      (WebCore::StickyPositionViewportConstraints::constrainingRectAtLastLayout):
      (WebCore::StickyPositionViewportConstraints::setConstrainingRectAtLastLayout):
      * rendering/RenderBoxModelObject.cpp:
      (WebCore::RenderBoxModelObject::computeStickyPositionConstraints):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153032 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      21bd1024
    • commit-queue@webkit.org's avatar
      DateInputType constructor initiate incorrect base class · e5daa513
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=118962
      
      Patch by Santosh Mahto <santosh.ma@samsung.com> on 2013-07-22
      Reviewed by Gyuyoung Kim.
      
      No new test required since solving code error
      
      * html/DateInputType.cpp:
      (WebCore::DateInputType::DateInputType):
      Corrected the base class instantiation in constructor.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153022 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e5daa513
    • timothy_horton@apple.com's avatar
      Plug-in unavailability indicator should not be displayed if a blocked plugin's indicator is clipped · 7adfc616
      timothy_horton@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118998
      <rdar://problem/14511268>
      
      Reviewed by Anders Carlsson.
      
      * html/HTMLEmbedElement.cpp:
      (WebCore::HTMLEmbedElement::updateWidget):
      * html/HTMLObjectElement.cpp:
      (WebCore::HTMLObjectElement::updateWidget):
      * html/HTMLPlugInElement.cpp:
      (WebCore::HTMLPlugInElement::defaultEventHandler):
      (WebCore::HTMLPlugInElement::supportsFocus):
      * html/HTMLPlugInImageElement.cpp:
      (WebCore::HTMLPlugInImageElement::updateWidgetIfNecessary):
      * loader/SubframeLoader.cpp:
      (WebCore::SubframeLoader::createJavaAppletWidget):
      (WebCore::SubframeLoader::loadPlugin):
      * page/FrameView.cpp:
      (WebCore::FrameView::updateWidget):
      Rename showsUnavailablePluginIndicator to isPluginUnavailable, since being unavailable
      and actually showing the indicator are two totally different things.
      
      * WebCore.exp.in: Expose setUnavailablePluginIndicatorIsHidden.
      
      * rendering/RenderEmbeddedObject.cpp:
      (WebCore::RenderEmbeddedObject::RenderEmbeddedObject):
      Rename m_showsUnavailablePluginIndicator to m_isPluginUnavailable.
      Add m_isUnavailablePluginIndicatorHidden, defaulting to false.
      
      (WebCore::RenderEmbeddedObject::setPluginUnavailabilityReasonWithDescription):
      Set m_isPluginUnavailable when we get an unavailability reason.
      
      (WebCore::RenderEmbeddedObject::paint):
      (WebCore::RenderEmbeddedObject::setUnavailablePluginIndicatorIsHidden): Added.
      
      * rendering/RenderEmbeddedObject.h:
      (WebCore::RenderEmbeddedObject::isPluginUnavailable): Added.
      
      (WebCore::RenderEmbeddedObject::showsUnavailablePluginIndicator):
      Repurpose "showsUnavailablePluginIndicator" to actually represent whether
      the indicator is displayed (i.e. the plugin is unavailable, and the
      indicator is not hidden).
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153017 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7adfc616
    • timothy_horton@apple.com's avatar
      RenderEmbeddedObject::isReplacementObscured should include the arrow in its area-of-interest · 44e53a9f
      timothy_horton@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118995
      <rdar://problem/14516421>
      
      Reviewed by Anders Carlsson.
      
      * rendering/RenderEmbeddedObject.cpp:
      (WebCore::RenderEmbeddedObject::unavailablePluginIndicatorBounds):
      Rename method from replacementTextRect to unavailablePluginIndicatorBounds for accuracy.
      Use the bounding box of the indicator's path, which includes the rounded rect behind
      the text as well as the arrow button.
      
      (WebCore::RenderEmbeddedObject::isReplacementObscured):
      * rendering/RenderEmbeddedObject.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153014 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      44e53a9f
    • timothy_horton@apple.com's avatar
      <applet> plugins are instantiated post-attach (instead of post-layout like for object and embed) · 6c8ba327
      timothy_horton@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118994
      <rdar://problem/14511232>
      
      Reviewed by Anders Carlsson.
      
      Make <applet> consistent with <object> and <embed>, deferring plugin
      instantiation to post-layout, so that layout is up-to-date if anything
      needs it (like RenderEmbeddedObject::isReplacementObscured) during creation.
      
      * html/HTMLAppletElement.cpp:
      (WebCore::HTMLAppletElement::updateWidget):
      Copy code from HTMLObjectElement/HTMLEmbedElement that defers plugin
      creation until post-layout tasks. Java is always an NPAPI plugin, so
      we should always defer if requested.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153013 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6c8ba327
    • benjamin@webkit.org's avatar
      String::lower() - Skip to slow path on the first failure · d9a499cb
      benjamin@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=118885
      
      Reviewed by Andreas Kling.
      
      In the 8 bits case, we don't need to know the state of the full string before changing characters
      to their lowercase variant.
      Just fail immediately and start transforming characters from the point of failure.
      
      This avoid reading the string twice when the uppercase character is not at the end of the string.
      
      * wtf/text/StringImpl.cpp:
      (WTF::StringImpl::lower):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153007 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d9a499cb
    • benjamin@webkit.org's avatar
      Do not allocate 2 AtomicString just to do a comparison in HTMLAnchorElement::setRel() · 6534a8f9
      benjamin@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=118941
      
      Reviewed by Gavin Barraclough.
      
      Currently, the only type of link relation supported by HTMLAnchorElement is RelationNoReferrer.
      
      To find the value, we create a SpaceSplitString with the input value of the attribute (which
      create one or more AtomicString depending on the input). Then we create a new AtomicString for
      the literal "noreferrer". Finally, we compare the pointers and throw away all the AtomicStrings.
      
      This causes a lot of memory operations for something really simple.
      
      This patch adds a little helper method to SpaceSplitString to find a literal in the input. The only
      allocation happens if we need to foldCase(). The following operations are done without allocating
      new buffer and without hashing the input.
      
      * dom/SpaceSplitString.cpp:
      (WebCore::tokenizeSpaceSplitString):
      (WebCore::AppendTokenToVectorTokenProcessor::AppendTokenToVectorTokenProcessor):
      (WebCore::AppendTokenToVectorTokenProcessor::processToken):
      (WebCore::SpaceSplitStringData::createVector):
      (WebCore::TokenIsEqualToCStringTokenProcessor::TokenIsEqualToCStringTokenProcessor):
      (WebCore::TokenIsEqualToCStringTokenProcessor::processToken):
      (WebCore::TokenIsEqualToCStringTokenProcessor::referenceStringWasFound):
      (WebCore::SpaceSplitString::spaceSplitStringContainsValue):
      * dom/SpaceSplitString.h:
      (WebCore::SpaceSplitString::spaceSplitStringContainsValue):
      * html/HTMLAnchorElement.cpp:
      (WebCore::HTMLAnchorElement::setRel):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153005 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6534a8f9
    • commit-queue@webkit.org's avatar
      segfault in RenderLayerCompositor when the iframe's position attribute is... · 12a5b98c
      commit-queue@webkit.org authored
      segfault in RenderLayerCompositor when the iframe's position attribute is changed and it embeds <object>.
      https://bugs.webkit.org/show_bug.cgi?id=118965
      
      Patch by Zalan Bujtas <zalan@apple.com> on 2013-07-22
      Reviewed by Simon Fraser.
      
      Do not change the composition state unless we can reliably figure out the iframe's size.
      If the renderer is not yet attached, its size is not computable.
      
      Source/WebCore:
      
      Test: compositing/iframes/iframe-position-absolute-with-padding-percentage-crash.html
      
      * rendering/RenderLayerCompositor.cpp:
      (WebCore::RenderLayerCompositor::requiresCompositingForFrame):
      
      LayoutTests:
      
      * compositing/iframes/iframe-position-absolute-with-padding-percentage-crash-expected.txt: Added.
      * compositing/iframes/iframe-position-absolute-with-padding-percentage-crash.html: Added.
      * compositing/iframes/resources/embed-tag-with-composition.html: Added.
      * platform/efl/TestExpectations: skip
      * platform/efl-wk2/TestExpectations: skip
      * platform/qt-5.0-wk1/TestExpectations: skip
      * platform/qt-5.0-wk2/TestExpectations: skip
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153003 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      12a5b98c
    • cfleizach@apple.com's avatar
      AX: VoiceOver only read the first column in a safari table · 36282cb3
      cfleizach@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118992
      
      Reviewed by Tim Horton.
      
      Source/WebCore: 
      
      In case the first section has fewer columns than the rest of the table, the AXTable was only reporting the number of
      columns for the first section. We need to take the max number of columns out of all sections.
      
      Test: accessibility/table-with-mismatch-column-count-in-initial-section.html
      
      * accessibility/AccessibilityTable.cpp:
      (WebCore::AccessibilityTable::addChildren):
      
      LayoutTests: 
      
      * accessibility/table-with-mismatch-column-count-in-initial-section-expected.txt: Added.
      * accessibility/table-with-mismatch-column-count-in-initial-section.html: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153002 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      36282cb3
    • bdakin@apple.com's avatar
      StickyPositionContraints should not need to change to account for a RenderLayer's · a99b14c6
      bdakin@apple.com authored
      scrollOffset
      https://bugs.webkit.org/show_bug.cgi?id=118958
      -and corresponding-
      <rdar://problem/12469203>
      
      Reviewed by Simon Fraser.
      
      Source/WebCore: 
      
      Before this patch, to get sticky offsets right in overflow areas, the 
      StickyPositionConstraints changed on every scroll to factor it in. This will be a 
      problem once we can scroll overflow areas on the scrolling thread. The constraints 
      should never have to change to account for the scroll position. This patch fixes 
      that issue by changing the StickyPositionViewportConstraints’s containerBlockRect 
      and stickyBoxRect to be in a coordinate space that is relative to the scrolling 
      ancestor rather than being absolute. This patch also removes ‘absolute’ from those 
      variable names since they are no longer absolute.
      
      A few re-names in the StickyPositionViewportConstraints class. The parameter to 
      computeStickyOffset() used to be called viewportRect, and is now called 
      constrainingRect. m_absoluteStickyBoxRect is now m_stickyBoxRect, and 
      m_absoluteContainingBlockRect is now m_containingBlockRect. And finally, 
      layerPositionForViewportRect() is now layerPositionForConstrainingRect()
      * page/scrolling/ScrollingConstraints.cpp:
      (WebCore::StickyPositionViewportConstraints::computeStickyOffset):
      (WebCore::StickyPositionViewportConstraints::layerPositionForConstrainingRect):
      * page/scrolling/ScrollingConstraints.h:
      (WebCore::StickyPositionViewportConstraints::StickyPositionViewportConstraints):
      (WebCore::StickyPositionViewportConstraints::containingBlockRect):
      (WebCore::StickyPositionViewportConstraints::setContainingBlockRect):
      (WebCore::StickyPositionViewportConstraints::stickyBoxRect):
      (WebCore::StickyPositionViewportConstraints::setStickyBoxRect):
      (WebCore::StickyPositionViewportConstraints::operator==):
      
      Accounting for the re-names. 
      * page/scrolling/ScrollingStateStickyNode.cpp:
      (WebCore::ScrollingStateStickyNode::syncLayerPositionForViewportRect):
      (WebCore::ScrollingStateStickyNode::dumpProperties):
      * page/scrolling/mac/ScrollingTreeStickyNode.mm:
      (WebCore::ScrollingTreeStickyNode::parentScrollPositionDidChange):
      
      Compute all values relative to the scrolling ancestor. This requires some juggling 
      in the overflow case to factor border and padding in or out.
      * rendering/RenderBoxModelObject.cpp:
      (WebCore::RenderBoxModelObject::computeStickyPositionConstraints):
      
      This is where the scrollOffset should be factored in.
      (WebCore::RenderBoxModelObject::stickyPositionOffset):
      
      LayoutTests: 
      
      This tests stick in overflow areas where the sticky’s containing block overflows 
      the overflow area. The sticky object should not extend beyond the overflow area in 
      that case. 
      
      * fast/css/sticky/sticky-top-overflow-container-overflow-expected.html: Added.
      * fast/css/sticky/sticky-top-overflow-container-overflow.html: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152998 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a99b14c6
    • dino@apple.com's avatar
      PlugIn content can disappear after restarting · 5d26494a
      dino@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118982
      
      Reviewed by Simon Fraser.
      
      When a snapshotted plug-in is restarted, we inserted its compositing
      layer back into the tree, but didn't recalculate style. This meant
      that a subsequent compositing tree operation (such as any hardware
      animation) could cause the content to disappear.
      
      * html/HTMLPlugInImageElement.cpp:
      (WebCore::HTMLPlugInImageElement::setDisplayState): Force a style recalc.
      (WebCore::HTMLPlugInImageElement::removeSnapshotTimerFired): Ditto.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152989 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5d26494a
    • joone.hur@intel.com's avatar
      Rebaseline the caret color test for the Mac port after r152612 · c3051ee4
      joone.hur@intel.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118961
      
      Reviewed by Alexey Proskuryakov.
      
      Added expected results of the caret color test for the Mac port.
      
      * platform/mac-wk2/editing/caret/caret-color-expected.png: Added.
      * platform/mac/TestExpectations:
      * platform/mac/editing/caret/caret-color-expected.png: Added.
      * platform/mac/editing/caret/caret-color-expected.txt: Added.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152987 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c3051ee4
    • commit-queue@webkit.org's avatar
      REGRESSION(r152227) Images with compositing layer don't show up unless the... · 9f7e41f2
      commit-queue@webkit.org authored
      REGRESSION(r152227) Images with compositing layer don't show up unless the containing window is resized.
      https://bugs.webkit.org/show_bug.cgi?id=118951
      
      Patch by Zalan Bujtas <zalan@apple.com> on 2013-07-22
      Reviewed by Simon Fraser.
      
      Ensure that the content rect is initialized when the image is set on the graphics layer.
      
      RenderLayerBacking::updateGraphicsLayerGeometry() only updates the contents rect when
      the associated graphics layer has a content layer. Since the image gets committed
      on the graphics layer after the update calls, the contents rect is left uninitialized.
      
      Source/WebCore:
      
      Test: compositing/images/positioned-image-content-rect.html
      
      * rendering/RenderLayerBacking.cpp:
      (WebCore::RenderLayerBacking::updateImageContents):
      
      LayoutTests:
      
      * compositing/images/positioned-image-content-rect-expected.html: Added.
      * compositing/images/positioned-image-content-rect.html: Added.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152986 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9f7e41f2
    • commit-queue@webkit.org's avatar
      [Old Web Inspector] When right-clicking on a DataGrid column, show editing... · 01a38a82
      commit-queue@webkit.org authored
      [Old Web Inspector] When right-clicking on a DataGrid column, show editing menu option as "Edit <columnName>" instead of just "Edit"
      https://bugs.webkit.org/show_bug.cgi?id=118971
      
      Patch by Diego Pino Garcia <dpino@igalia.com> on 2013-07-22
      Reviewed by Timothy Hatcher.
      
      * English.lproj/localizedStrings.js:
      * inspector/front-end/DataGrid.js: Change "Edit" for "Edit <columnTitle>"
      (WebInspector.DataGrid.prototype._contextMenuInDataTable):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152985 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      01a38a82
    • ap@apple.com's avatar
      Frequent MESSAGE_CHECK failures in WebPageProxy::didReceiveEvent · 2b9e9add
      ap@apple.com authored
              https://bugs.webkit.org/show_bug.cgi?id=118976
              <rdar://problem/14155030>
      
              Reviewed by Sam Weinig.
      
              * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetStateAfterProcessExited):
              Clear m_gestureEventQueue, just like we clear all other event queues here.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152984 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2b9e9add
    • achristensen@apple.com's avatar
      Fixed WinCairo build configurations. · 8c0ef9c1
      achristensen@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118932
      
      Reviewed by Brent Fulgham.
      
      * WebKit.vcxproj/WebKit.sln:
      Made WinCairo not build AssembleBuildLogs (wasn't working, not necessary).
      Made Debug_WinCairo build with Debug_WinCairo configuration.
      Made 64-bit WinCairo not build QTMovieWin.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152983 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8c0ef9c1
    • achristensen@apple.com's avatar
      Added assembly files to Windows 64-bit builds. · e2a406ce
      achristensen@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118931
      
      Reviewed by Brent Fulgham.
      
      Source/JavaScriptCore:
      
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Added JITStubsMSVC64.asm for x64 and enabled MASM.
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Added JITStubsMSVC64.asm.
      
      Source/WebCore:
      
      * WebCore.vcxproj/WebCore.vcxproj: Added PaintHooks.asm for x64 and enabled MASM.
      * WebCore.vcxproj/WebCore.vcxproj.filters: Added PaintHooks.asm.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152982 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e2a406ce