1. 26 Mar, 2013 40 commits
    • tkent@chromium.org's avatar
      Make HTMLProgressElement::isDeterminate private · 64d0d183
      tkent@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113299
      
      Reviewed by Kentaro Hara.
      
      The only callsite of isDeterminate outside of HTMLProgressElement
      is in StyleResolver::sharingCandidateHasIdenticalStyleAffectingAttributes,
      and we can replace it with Element::shouldAppearIndeterminate.
      
      No new tests. Just a refactoring.
      
      * css/StyleResolver.cpp:
      (WebCore::StyleResolver::sharingCandidateHasIdenticalStyleAffectingAttributes):
      Use Element::shouldAppearIndeterminate.
      * html/HTMLProgressElement.h:
      (HTMLProgressElement): Make isDeterminate private.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146953 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      64d0d183
    • dgrogan@chromium.org's avatar
      IndexedDB: Histogram cause of LevelDB write errors · 309eb62d
      dgrogan@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113350
      
      Reviewed by Tony Chang.
      
      Add histogram for source of LevelDB errors on Write in addition to
      Open.
      
      No new tests - no good way to test histogram code.
      
      * platform/leveldb/LevelDBDatabase.cpp:
      (WebCore::histogramLevelDBError):
      (WebCore):
      (WebCore::LevelDBDatabase::open):
      (WebCore::LevelDBDatabase::write):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146950 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      309eb62d
    • cfleizach@apple.com's avatar
      WebKit does not expose @required or @aria-required as AXRequired on select elements · 1f897272
      cfleizach@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113339
      
      Reviewed by Tim Horton.
      
      Source/WebCore: 
      
      Make sure button types can return the AXRequired attribute.
      
      Tests: platform/mac/accessibility/aria-required-popup-button.html
      
      * accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
      (-[WebAccessibilityObjectWrapper accessibilityAttributeNames]):
      
      LayoutTests: 
      
      * platform/mac/accessibility/aria-required-popup-button-expected.txt: Added.
      * platform/mac/accessibility/aria-required-popup-button.html: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146949 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      1f897272
    • dino@apple.com's avatar
      When a primary plugin is restarted, also start similar plugins · cf69686e
      dino@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113265
      
      Reviewed by Tim Horton.
      
      Source/WebCore:
      
      If we detect a primary plugin that is snapshotted, we immediately restart it.
      When this happens, we should also restart any other plugins that
      match the same origin and type. This allows sites with a lot of
      (geometrically) nearby plugins to behave as if they are a single big plugin.
      
      Tests: plugins/snapshotting/autoplay-similar-to-dominant-after-delay.html
             plugins/snapshotting/autoplay-similar-to-dominant.html
      
      * WebCore.exp.in: Export mimeTypeFromURL.
      * html/HTMLPlugInImageElement.cpp:
      (WebCore::addPlugInsFromNodeListMatchingPlugInOrigin): Use loadedMimeType helper.
      (WebCore::HTMLPlugInImageElement::restartSimilarPlugIns): New method, which copied the
          existing code from userDidClickSnapshot.
      (WebCore::HTMLPlugInImageElement::userDidClickSnapshot): Move the similar plugin detection
          out into another function and call it.
      (WebCore::HTMLPlugInImageElement::setIsPrimarySnapshottedPlugIn): Call restartSimilarPlugIns.
      (WebCore::HTMLPlugInImageElement::subframeLoaderWillCreatePlugIn): Use loadedMimeType helper.
      * html/HTMLPlugInImageElement.h: Declaration of restartSimilarPlugIns.
      (WebCore::HTMLPlugInImageElement::loadedMimeType): New helper method since this
          code was being often duplicated.
      
      Source/WebKit2:
      
      Remember the origin of the primary plugin, so that we can
      autostart anything that is similar.
      
      * WebProcess/WebCoreSupport/WebPlugInClient.cpp:
      (WebKit::WebPlugInClient::WebPlugInClient): Keep a pointer to the WebPage.
      (WebKit::WebPlugInClient::shouldAutoStartFromOrigin): Pass the page onto the process.
      * WebProcess/WebCoreSupport/WebPlugInClient.h:
      (WebPlugInClient): New member variable for the WebPage we were created with.
      * WebProcess/WebPage/WebPage.cpp:
      (WebKit::WebPage::determinePrimarySnapshottedPlugIn): Remember the origin information
          for the primary plugin.
      (WebKit::WebPage::matchesPrimaryPlugIn): Returns true if we're seeing something that
          looks like the primary plugin.
      * WebProcess/WebPage/WebPage.h: New method matchesPrimaryPlugIn.
      * WebProcess/WebProcess.cpp:
      (WebKit::WebProcess::shouldPlugInAutoStartFromOrigin): Check if the page thinks this is
          the primary plugin.
      * WebProcess/WebProcess.h: Accept a reference to the page in shouldPlugInAutoStartFromOrigin.
      
      LayoutTests:
      
      Two new tests. The first has one big plugin (that should be detected as the primary)
      and then a few smaller versions (which should autostart along with the primary).
      The second has one big plugin, and then adds a similar one after a short delay.
      
      * platform/mac-wk2/plugins/snapshotting/autoplay-similar-to-dominant-after-delay-expected.txt: Added.
      * platform/mac-wk2/plugins/snapshotting/autoplay-similar-to-dominant-expected.txt: Added.
      * plugins/snapshotting/autoplay-similar-to-dominant-after-delay.html: Added.
      * plugins/snapshotting/autoplay-similar-to-dominant.html: Added.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146946 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      cf69686e
    • bfulgham@webkit.org's avatar
      [Windows, WinCairo] Scroll offset being applied to plugins during print operations. · f6463f7a
      bfulgham@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=39889
      
      Reviewed by Anders Carlsson.
      
      This must be tested manually. See the issue for details.
      
      * plugins/win/PluginViewWin.cpp:
      (WebCore::PluginView::paintWindowedPluginIntoContext):
      Revise the Windows implementation of the PluginView class
      paintWindowedPluginIntoContext to use the containing window
      position when computing the plugin's position for printing.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146941 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      f6463f7a
    • wangxianzhu@chromium.org's avatar
      Non-paintsContent fixed position layer should not cause slow scrolling · 50666458
      wangxianzhu@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113238
      
      Reviewed by James Robinson.
      
      Source/WebCore:
      
      Added NotCompositedForNoVisibleContent in ViewportConstrainedNotCompositedReason and set it in RLC.
      
      Test: compositing/layer-creation/fixed-position-no-content-scroll-reason.html
      
      * rendering/RenderLayer.h: Add NotCompositedForNoVisibleContent.
      * rendering/RenderLayerCompositor.cpp:
      (WebCore::RenderLayerCompositor::requiresCompositingForPosition): Set NotCompositedForNoVisibleContent reason when the fixed position layer has no visible content.
      
      LayoutTests:
      
      * compositing/layer-creation/fixed-position-no-content-scroll-reason-expected.txt: Added.
      * compositing/layer-creation/fixed-position-no-content-scroll-reason.html: Copied from LayoutTests/compositing/layer-creation/fixed-position-out-of-view-scroll-reason.html. Test case for the bug.
      * compositing/layer-creation/fixed-position-in-view-dynamic.html: Set background of fixed layer to distinguish out-of-view case from no-content case.
      * compositing/layer-creation/fixed-position-out-of-view-dynamic.html: Ditto.
      * compositing/layer-creation/fixed-position-out-of-view-scroll-reason.html: Ditto.
      * platform/chromium/compositing/layer-creation/fixed-position-in-view-dynamic-expected.txt: Removed. This was a wrong rebaseline related to this bug.
      * platform/chromium/platform/chromium/virtual/softwarecompositing/layer-creation/fixed-position-in-view-dynamic-expected.txt: Removed. This was a wrong rebaseline related to this bug.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146940 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      50666458
    • zoltan@webkit.org's avatar
      [CSS Exclusions] The radius of a circle should be computed based on the shorter available dimension · fda9d1d6
      zoltan@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113255
      
      Reviewed by Julien Chaffraix.
      
      When we decide what should be the radius of a circle, we should choose the smallest available space. For instance when the
      width or height is not resolvable for the circle we should not have a radius for it. This change modifies the behavior to
      use the smaller available space, so we won't render unnecessary circle shapes.
      
      Source/WebCore: 
      
      Test: fast/exclusions/shape-inside/shape-inside-on-nested-container-with-unresolved-height.html
      
      * rendering/ExclusionShape.cpp:
      (WebCore::ExclusionShape::createExclusionShape):
      
      LayoutTests: 
      
      * fast/exclusions/shape-inside/shape-inside-on-nested-container-with-unresolved-height-expected.html: Added.
      * fast/exclusions/shape-inside/shape-inside-on-nested-container-with-unresolved-height.html: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146938 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      fda9d1d6
    • timothy@apple.com's avatar
      Make the Web Inspector console work in strict mode with JavaScriptCore. · da73879a
      timothy@apple.com authored
      https://webkit.org/b/65829
      rdar://problem/11271238
      
      Reviewed by Joseph Pecoraro.
      
      * inspector/InjectedScriptSource.js:
      (InjectedScript.prototype._evaluateOn): Don't use 'eval' parameter (it isn't
      allowed in strict mode). Swap window.eval with our known eval instead.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146937 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      da73879a
    • rniwa@webkit.org's avatar
      Heap-use-after-free regression · 0330737c
      rniwa@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113337
      
      Reviewed by Abhishek Arya and Alexey Proskuryakov.
      
      Source/WebCore: 
      
      Use RefPtr instead of raw pointer in m_associatedFormControls.
      
      * dom/Document.cpp:
      (WebCore::Document::didAssociateFormControlsTimerFired):
      * dom/Document.h:
      (Document):
      * loader/EmptyClients.h:
      (WebCore::EmptyChromeClient::didAssociateFormControls):
      * page/ChromeClient.h:
      (WebCore::ChromeClient::didAssociateFormControls):
      
      Source/WebKit/chromium: 
      
      * src/ChromeClientImpl.cpp:
      (WebKit::ChromeClientImpl::didAssociateFormControls):
      * src/ChromeClientImpl.h:
      (ChromeClientImpl):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146935 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0330737c
    • ap@apple.com's avatar
      <rdar://problem/13194263> Crashes in NetworkProcess due to threading issues · cd1fa45e
      ap@apple.com authored
              https://bugs.webkit.org/show_bug.cgi?id=113256
      
              Reviewed by Brady Eidson.
      
              Added a new code path in ResourceHandle/ResourceHandleClient that doesn't need
              blocking calls. Implemented it for NSURLConnection by changing NSOperationQueue
              version to forward calls to main thread.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146929 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      cd1fa45e
    • tony@chromium.org's avatar
      Autogenerate the scrollAnimatorEnabled setting in Settings.in · 82972d0f
      tony@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113253
      
      Reviewed by James Robinson.
      
      Source/WebCore:
      
      Convert scrollAnimatorEnabled into an autogenerated setting. This involves renaming
      the setter from setEnableScrollAnimator(bool) to setScrollAnimatorEnabled(bool) and
      updating the callers. I didn't change any WebKit API methods.
      
      Also remove the code in InternalSettings since it's never used and will now be
      autogenerated with proper resetting code.
      
      No new tests, this is a refactor and should compile.
      
      * page/Settings.cpp:
      (WebCore::Settings::Settings): Remove code that is now autogenerated.
      * page/Settings.h:
      (Settings): Remove code that is now autogenerated.
      * page/Settings.in: Add entry for scrollAnimatorEnabled.
      * testing/InternalSettings.cpp: Remove unused code.
      * testing/InternalSettings.h: Remove unused code.
      * testing/InternalSettings.idl: Remove unused code.
      
      Source/WebKit/chromium:
      
      * src/WebSettingsImpl.cpp:
      (WebKit::WebSettingsImpl::setEnableScrollAnimator): Update call to WebCore to use setScrollAnimatorEnabled(bool).
      
      Source/WebKit/gtk:
      
      * webkit/webkitwebview.cpp:
      (webkit_web_view_update_settings): Update call to WebCore to use setScrollAnimatorEnabled(bool).
      (webkit_web_view_settings_notify): Update call to WebCore to use setScrollAnimatorEnabled(bool).
      
      Source/WebKit/qt:
      
      * Api/qwebsettings.cpp:
      (QWebSettingsPrivate::apply): Update call to WebCore to use setScrollAnimatorEnabled(bool).
      
      Source/WebKit2:
      
      * WebProcess/WebPage/WebPage.cpp:
      (WebKit::WebPage::setUseFixedLayout): Update call to WebCore to use setScrollAnimatorEnabled(bool).
      (WebKit::WebPage::updatePreferences): Update call to WebCore to use setScrollAnimatorEnabled(bool).
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146924 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      82972d0f
    • commit-queue@webkit.org's avatar
      [BlackBerry] In RSSFilterStream, don't swallow headers when there's no body · 95e1ba28
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113334
      
      Patch by Joe Mason <jmason@blackberry.com> on 2013-03-26
      Reviewed by Rob Buis.
      
      RIM PR 316345
      
      When receiving an HTTP response that has a Content-Type header such as text/xml, but no
      body, RSSFilterStream::notifyHeadersReceived reads the Content-Type as "potential RSS", and
      calls saveHeaders. It expects to sniff the body in notifyDataReceived to see if it's RSS,
      and then call sendSavedHeaders to pass on the headers. But since there is no body,
      notifyDataReceived is never called. So call sendSavedHeaders in notifyClose too (it will not
      send them again if they were already sent.)
      
      * platform/network/blackberry/rss/RSSFilterStream.cpp:
      (WebCore::RSSFilterStream::notifyClose):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146922 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      95e1ba28
    • commit-queue@webkit.org's avatar
      Web Inspector: Faster drawer animation. · c3cb279b
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113330
      
      250ms -> 100ms
      
      Patch by Dmitry Zvorygin <zvorygin@chromium.org> on 2013-03-26
      Reviewed by Pavel Feldman.
      
      * inspector/front-end/inspector.css:
      (.animate #main):
      (.animate #floating-status-bar-container):
      (.animate #drawer):
      (.animate #bottom-status-bar-container > *):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146918 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c3cb279b
    • bfulgham@webkit.org's avatar
      [WinCairo] Unreviewed Build fix. · a869baca
      bfulgham@webkit.org authored
      * platform/graphics/win/FontCustomPlatformDataCairo.h:
      (FontCustomPlatformData): Correct signature in header to match
      required implementation.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146912 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a869baca
    • anilsson@rim.com's avatar
      [BlackBerry] Scrolling up and down can cause the screen to flash black · cd289bab
      anilsson@rim.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113269
      
      Reviewed by Rob Buis.
      
      PR 296106
      
      Source/WebCore:
      
      The LayerRenderer should never clear before drawing the layers, from
      now on that's the responsibility of the caller.
      
      Only manually testable.
      
      * platform/graphics/blackberry/LayerRenderer.cpp:
      (WebCore::LayerRenderer::setViewport):
      * platform/graphics/blackberry/LayerRendererClient.h:
      (LayerRendererClient):
      
      Source/WebKit/blackberry:
      
      Various flaws in the code could conspire to make the screen cleared to
      black before rendering the web page. This only happened when the
      BackingStore was inactive, and the LayerTiler takes on the job of
      drawing the root layer. When tiles are missing, this made the
      "checkerboard" effect especially noticeable since black color was seen
      where the tile should have been. It would be better to clear to the web
      page background color.
      
      This was actually the intent of the code, but when the document
      background color was invalid, we would still use it instead of the
      background color from settings. Also, the LayerRenderer would clear to
      black when WebPageCompositorPrivate::drawsRootLayer() was true.
      
      Fixed by falling back to the settings background color when the
      document background color is invalid, and removing the clearing code
      from the LayerRenderer entirely. The appropriate clear already happens
      near the beginning of BackingStorePrivate::blitVisibleContents().
      
      Also slightly cleaned up the code for managing the background color.
      
      * Api/WebPage.cpp:
      (BlackBerry::WebKit::WebPagePrivate::setLoadState):
      (BlackBerry::WebKit::WebPagePrivate::didChangeSettings):
      (BlackBerry::WebKit::WebPagePrivate::updateBackgroundColor):
      (WebKit):
      (BlackBerry::WebKit::WebPagePrivate::documentBackgroundColor):
      * Api/WebPageCompositor.cpp:
      * Api/WebPageCompositor_p.h:
      (WebPageCompositorPrivate):
      * Api/WebPage_p.h:
      (WebPagePrivate):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146911 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      cd289bab
    • allan.jensen@digia.com's avatar
      [Qt] editing/pasteboard/can-read-in-dragstart-event.html and... · 7bc0f8b1
      allan.jensen@digia.com authored
      [Qt] editing/pasteboard/can-read-in-dragstart-event.html and /can-read-in-copy-and-cut-events.html are crashing
      https://bugs.webkit.org/show_bug.cgi?id=113126
      
      Reviewed by Jocelyn Turcotte.
      
      Source/WebCore:
      
      Make it possible to read from a writable Clipboard.
      
      Test: editing/pasteboard/can-read-in-copy-and-cut-events.html
      
      * platform/qt/ClipboardQt.cpp:
      (WebCore::ClipboardQt::getData):
      (WebCore::ClipboardQt::types):
      (WebCore::ClipboardQt::files):
      (WebCore::ClipboardQt::readClipboardData):
      (WebCore::ClipboardQt::hasData):
      (WebCore::ClipboardQt::items):
      * platform/qt/ClipboardQt.h:
      (ClipboardQt):
      
      LayoutTests:
      
      Unskip now working editing/pasteboard/can-read-in-copy-and-cut-events.html.
      The other test still needs better drag-and-drop support in DRT.
      
      * platform/qt/TestExpectations:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146910 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7bc0f8b1
    • bfulgham@webkit.org's avatar
      [WinCairo] Unreviewed build correction. · 7e43ef59
      bfulgham@webkit.org authored
      * platform/graphics/win/FontCustomPlatformDataCairo.cpp:
      (WebCore::FontCustomPlatformData::fontPlatformData): Update
      method signature to match CG variant.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146909 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7e43ef59
    • ch.dumez@sisa.samsung.com's avatar
      Code duplication between HTTPParsers and HTTPValidation · 3855a916
      ch.dumez@sisa.samsung.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113283
      
      Reviewed by Alexey Proskuryakov.
      
      Source/WebCore:
      
      Merged isValidHTTPToken() from HTTPValidation.h and isRFC2616Token() from
      HTTPParsers.h. They were doing exactly the same thing and their
      implementation was almost the same.
      
      Removed HTTPValidation.* and moved remaining code to HTTPParsers.* as this
      seems like the proper place and it seems odd to keep HTTPValidation for
      just one function.
      
      No new tests, no behavior change for layout tests.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * Target.pri:
      * WebCore.gypi:
      * WebCore.vcproj/WebCore.vcproj:
      * WebCore.vcxproj/WebCore.vcxproj:
      * WebCore.vcxproj/WebCore.vcxproj.filters:
      * WebCore.xcodeproj/project.pbxproj:
      * platform/network/HTTPParsers.cpp:
      (WebCore::isValidHTTPHeaderValue):
      (WebCore):
      (WebCore::isValidHTTPToken): Implementation is slightly simplified based on
      isValidHTTPToken() from HTTPValidation.cpp. (c >= 0x80 || c == 0x7F) is
      replaced by (c >= 0x7F). (c <= 0x1F ||  c == ' ' || c == '\t') is replaced
      by (c <= 0x20). Those expressions are shorter but equivalent.
      (WebCore::contentDispositionType):
      * platform/network/HTTPParsers.h:
      * platform/network/HTTPValidation.cpp: Removed.
      * platform/network/HTTPValidation.h: Removed.
      * xml/XMLHttpRequest.cpp: Stop including HTTPValidation.h.
      
      Source/WebKit/chromium:
      
      * src/AssociatedURLLoader.cpp: Include HTTPParsers.h instead
      of HTTPValidation.h to use isValidHTTPToken().
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146908 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3855a916
    • sergio@webkit.org's avatar
      Implement overtype mode for editable content · 1874d7a9
      sergio@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=112126
      
      Reviewed by Ryosuke Niwa.
      
      Source/WebCore:
      
      Tests: editing/execCommand/overtype-support.html
             editing/execCommand/overtype.html
      
      Add a new Overwrite command to the editor. This command will
      perform overtype operations when enabled instead of "normal" text
      insertions. As IE does, we maintain a single toggle state in the
      editor (enabled/disabled) for all the editable content in the
      page.
      
      This new command will be only available for richly editable
      content via keybindings or the context menu. For testing purposes
      it is also accessible via internals.
      
      * editing/CompositeEditCommand.cpp:
      (WebCore::CompositeEditCommand::replaceTextInNode): Use RefPtr for
      local variables.
      * editing/Editor.cpp:
      (WebCore::Editor::Editor):
      * editing/Editor.h:
      (WebCore::Editor::isOverwriteModeEnabled):
      (WebCore::Editor::toggleOverwriteModeEnabled):
      (Editor): Added two new functions and a new attribute.
      * editing/EditorCommand.cpp:
      (WebCore::executeToggleOverwrite): Enables/disables overwrite mode.
      (WebCore):
      (WebCore::createCommandMap): New OverWrite command.
      * editing/InsertTextCommand.cpp:
      (WebCore::InsertTextCommand::setEndingSelectionWithoutValidation):
      Refactored from performTrivialReplace(), shared by
      performOverwrite().
      (WebCore):
      (WebCore::InsertTextCommand::performTrivialReplace):
      (WebCore::InsertTextCommand::performOverwrite):
      (WebCore::InsertTextCommand::doApply): Perform overwrite if enabled.
      * editing/InsertTextCommand.h:
      (InsertTextCommand):
      * testing/Internals.cpp:
      (WebCore::Internals::resetToConsistentState): Reset OverWrite mode
      to false.
      (WebCore::Internals::isOverwriteModeEnabled):
      (WebCore):
      (WebCore::Internals::toggleOverwriteModeEnabled): Provide access
      to overwrite functionality in Editor for testing purposes.
      * testing/Internals.h:
      (Internals):
      * testing/Internals.idl:
      
      Source/WebKit/mac:
      
      Added the OverWrite editing command to the WebCore editing
      commands lists.
      
      * WebView/WebHTMLView.mm:
      * WebView/WebView.h:
      * WebView/WebView.mm:
      
      LayoutTests:
      
      Two new layout tests for the new overtype mode. We use
      overtype-support.html to check that the Overwrite command is not
      exported to JavaScript but accessible through Internals. The
      overtype.html one is used to test the actual behaviour of the
      command.
      
      The new command was also added to enabling-and-selection-2.js to
      check that it is only available for richly editable content.
      
      * editing/execCommand/enabling-and-selection-2-expected.txt:
      Updated expectations for OverWrite command.
      * editing/execCommand/overtype-expected.txt: Added.
      * editing/execCommand/overtype-support-expected.txt: Added.
      * editing/execCommand/overtype-support.html: Added.
      * editing/execCommand/overtype.html: Added.
      * editing/execCommand/script-tests/enabling-and-selection-2.js:
      Added a check for OverWrite command.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146907 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      1874d7a9
    • anilsson@rim.com's avatar
      [BlackBerry] WebOverlay::pixelViewportRect() should return pixel viewport coordinates · 302250bc
      anilsson@rim.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113263
      
      Reviewed by Rob Buis.
      
      PR 312404
      
      Source/WebCore:
      
      Fix WebOverlay::pixelViewportRect() to return the pixel viewport rect
      instead of the window rect. These are different if the web page is
      rendered starting at a window coordinate other than 0,0. The clip rect
      encodes the position we're rendered at, and can be used to translate
      the rect expressed in window coordinates to the pixel viewport
      coordinate system.
      
      Also perform some cleanup of related code.
      
      Only manually testable.
      
      * platform/graphics/blackberry/LayerCompositingThread.cpp:
      (WebCore::LayerCompositingThread::getTransformedHolePunchRect):
      (WebCore::LayerCompositingThread::drawTextures):
      * platform/graphics/blackberry/LayerRenderer.cpp:
      (WebCore::toPixelCoordinates):
      (WebCore):
      (WebCore::LayerRenderer::toWindowCoordinates):
      (WebCore::LayerRenderer::toPixelViewportCoordinates):
      (WebCore::LayerRenderer::toDocumentViewportCoordinates):
      (WebCore::LayerRenderer::updateLayersRecursive):
      * platform/graphics/blackberry/LayerRenderer.h:
      (LayerRenderer):
      
      Source/WebKit/blackberry:
      
      Fixed by returning pixel viewport coordinates instead of window
      coordinates.
      
      * Api/WebOverlay.cpp:
      (BlackBerry::WebKit::WebOverlayPrivateCompositingThread::pixelViewportRect):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146906 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      302250bc
    • commit-queue@webkit.org's avatar
      Unreviewed, rolling out r146901. · 72190cac
      commit-queue@webkit.org authored
      http://trac.webkit.org/changeset/146901
      https://bugs.webkit.org/show_bug.cgi?id=113321
      
      Was landed to soon (Requested by pfeldman on #webkit).
      
      Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2013-03-26
      
      Source/WebCore:
      
      * inspector/front-end/ConsoleView.js:
      (WebInspector.ConsoleView.prototype.):
      (WebInspector.ConsoleView.prototype.filter):
      (WebInspector.ConsoleView.prototype._scheduleScrollIntoView.scrollIntoView):
      (WebInspector.ConsoleView.prototype._scheduleScrollIntoView):
      (WebInspector.ConsoleView.prototype._consoleMessageAdded):
      (WebInspector.ConsoleView.prototype._appendConsoleMessage):
      (WebInspector.ConsoleView.prototype._consoleCleared):
      (WebInspector.ConsoleView.prototype._handleContextMenuEvent.monitoringXHRItemAction):
      (WebInspector.ConsoleView.prototype._handleContextMenuEvent.get preserveLogItemAction):
      (WebInspector.ConsoleView.prototype._shouldBeVisible):
      (WebInspector.ConsoleView.prototype._updateMessageList):
      (WebInspector.ConsoleView.prototype._promptKeyDown):
      (WebInspector.ConsoleView.prototype._printResult):
      (WebInspector.ConsoleCommand.prototype.highlightSearchResults):
      * inspector/front-end/inspector.css:
      (.console-warning-level, .console-error-level, .console-log-level, .console-debug-level):
      (.filter-all .console-debug-level, .filter-debug .console-debug-level):
      (.filter-all .console-debug-level.repeated-message, .filter-debug .console-debug-level.repeated-message):
      
      LayoutTests:
      
      * inspector/console/console-preserve-log.html:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146905 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      72190cac
    • rafaelw@chromium.org's avatar
      HTMLStackItem should include <template> as a special tag · 16bce4e9
      rafaelw@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113016
      
      Reviewed by Eric Seidel.
      
      Source/WebCore:
      
      New test added to html5lib suite.
      
      * html/parser/HTMLStackItem.h:
      (WebCore::HTMLStackItem::isSpecialNode):
      
      LayoutTests:
      
      * html5lib/resources/template.dat:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146904 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      16bce4e9
    • vsevik@chromium.org's avatar
      Web Inspector: Distinguish breakpoints and breakpoint locations in BreakpointManager API · ccde99ef
      vsevik@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113311
      
      Reviewed by Pavel Feldman.
      
      Source/WebCore:
      
      Made independent handling of breakpoints and breakpoint location in breakpoint manager consistent.
      JavaScriptSourceFrame now removes breakpoints originally set in it based on primary UI location.
      
      * inspector/front-end/BreakpointManager.js:
      (WebInspector.BreakpointManager.prototype.breakpointsForUISourceCode):
      (WebInspector.BreakpointManager.prototype.allBreakpoints):
      (WebInspector.BreakpointManager.prototype.breakpointLocationsForUISourceCode):
      (WebInspector.BreakpointManager.prototype.allBreakpointLocations):
      (WebInspector.BreakpointManager.prototype._projectWillReset.get for):
      (WebInspector.BreakpointManager.prototype._projectWillReset):
      * inspector/front-end/JavaScriptSourceFrame.js:
      (WebInspector.JavaScriptSourceFrame.prototype.onUISourceCodeContentChanged):
      (WebInspector.JavaScriptSourceFrame.prototype._restoreBreakpointsAfterEditing):
      (WebInspector.JavaScriptSourceFrame.prototype._removeAllBreakpoints):
      
      LayoutTests:
      
      * inspector/debugger/live-edit-breakpoints-expected.txt:
      * inspector/debugger/live-edit-breakpoints.html:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146903 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ccde99ef
    • commit-queue@webkit.org's avatar
      Web Inspector: Remove remainings of CSS-based console message filtering. · 8a1b945c
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=112710
      
      Patch by Dmitry Zvorygin <zvorygin@chromium.org> on 2013-03-26
      Reviewed by Pavel Feldman.
      
      Source/WebCore:
      
      * inspector/front-end/ConsoleView.js:
      (WebInspector.ConsoleView.get this):
      (WebInspector.ConsoleView.prototype.):
      (WebInspector.ConsoleView.prototype.filter):
      (WebInspector.ConsoleView.prototype._consoleMessageAdded):
      (WebInspector.ConsoleView.prototype._appendConsoleMessage):
      (WebInspector.ConsoleView.prototype._consoleCleared):
      (WebInspector.ConsoleView.prototype._shouldBeVisible):
      (WebInspector.ConsoleView.prototype._updateMessageList):
      (WebInspector.ConsoleView.prototype._promptKeyDown):
      (WebInspector.ConsoleView.prototype._printResult):
      (WebInspector.ConsoleCommand.prototype.highlightSearchResults):
      * inspector/front-end/inspector.css:
      (.console-debug-level.repeated-message):
      
      LayoutTests:
      
      * inspector/console/console-preserve-log.html:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146901 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8a1b945c
    • commit-queue@webkit.org's avatar
      Web Inspector: refactor code duplication:... · 9eb13207
      commit-queue@webkit.org authored
      Web Inspector: refactor code duplication: WebInspector.ObjectPropertyTreeElement.wrapPropertyAsElements
      https://bugs.webkit.org/show_bug.cgi?id=113211
      
      Patch by Peter Rybin <prybin@chromium.org> on 2013-03-26
      Reviewed by Yury Semikhatsky.
      
      A new method WebInspector.ObjectPropertyTreeElement.wrapPropertyAsElements is added and used
      from 2 sites.
      
      * inspector/front-end/ObjectPropertiesSection.js:
      (WebInspector.ObjectPropertiesSection.prototype.update.callback):
      (WebInspector.ObjectPropertiesSection.prototype.update):
      (WebInspector.ObjectPropertiesSection.prototype.updateProperties):
      (.callback):
      (WebInspector.ObjectPropertyTreeElement.populate):
      (WebInspector.ObjectPropertyTreeElement.wrapPropertyAsElements):
      * inspector/front-end/WatchExpressionsSidebarPane.js:
      (WebInspector.WatchExpressionsSection.prototype.update.appendResult):
      (WebInspector.WatchExpressionsSection.prototype.update):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146900 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9eb13207
    • ch.dumez@sisa.samsung.com's avatar
      HTTPHeaderMap::copyData() could call uncheckedAppend() · 2a66fcac
      ch.dumez@sisa.samsung.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113279
      
      Reviewed by Alexey Proskuryakov.
      
      HTTPHeaderMap::copyData() calls reserveInitialCapacity() on the Vector
      but then appends items using append() function. Since we already know
      the capacity is sufficient, it is more efficient to call uncheckedAppend()
      instead to bypass capacity checks.
      
      No new tests, no behavior change for layout tests.
      
      * platform/network/HTTPHeaderMap.cpp:
      (WebCore::HTTPHeaderMap::copyData):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146899 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2a66fcac
    • vsevik@chromium.org's avatar
      Web Inspector: UISourceCodes are leaking on reload sometimes. · a9284923
      vsevik@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113310
      
      Reviewed by Pavel Feldman.
      
      * inspector/front-end/BreakpointManager.js:
      (WebInspector.BreakpointManager.prototype._projectWillReset.get for):
      (WebInspector.BreakpointManager.prototype._projectWillReset):
      * inspector/front-end/ConsoleModel.js:
      (WebInspector.ConsoleModel.prototype.clearMessages):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146898 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a9284923
    • apavlov@chromium.org's avatar
      Web Inspector: [Elements] Unable to "Edit as HTML" XHTML/SVG documents. · e2f25b07
      apavlov@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113290
      
      Reviewed by Pavel Feldman.
      
      Source/WebCore:
      
      DOMPatchSupport has been slightly augmented to handle XML (XHTML and SVG) documents.
      
      Test: inspector/elements/set-outer-html-for-xhtml.xhtml
      
      * inspector/DOMPatchSupport.cpp:
      (WebCore::DOMPatchSupport::patchDocument):
      (WebCore::DOMPatchSupport::patchNode):
      * inspector/InspectorDOMAgent.cpp:
      (WebCore::InspectorDOMAgent::setOuterHTML): Let HTML, XHTML, and SVG documents through.
      
      LayoutTests:
      
      * inspector/elements/set-outer-html-for-xhtml-expected.txt: Added.
      * inspector/elements/set-outer-html-for-xhtml.xhtml: Added.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146897 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e2f25b07
    • morrita@google.com's avatar
      https://bugs.webkit.org/show_bug.cgi?id=113164 · 85bdf051
      morrita@google.com authored
      Custom Elements: readyCallback should be called for outerHTML and insertAdjecentHTML
      
      Source/WebCore:
      
      These APIs also create new elements thus should have V8DeliverCustomElementCallbacks attribute.
      
      Reviewed by Dimitri Glazkov.
      
      Test: Updated lifecycle-ready-creation-api.html.
      
      * html/HTMLElement.idl:
      
      LayoutTests:
      
      Reviewed by Dimitri Glazkov.
      
      * fast/dom/custom/lifecycle-ready-creation-api-expected.txt:
      * fast/dom/custom/lifecycle-ready-creation-api.html:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146896 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      85bdf051
    • loislo@chromium.org's avatar
      Unreviewed. WebInspector: remove unnecessary method. · afacdc7d
      loislo@chromium.org authored
      * inspector/front-end/OverviewGrid.js:
      (WebInspector.OverviewGrid.Window):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146893 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      afacdc7d
    • loislo@chromium.org's avatar
      Web Inspector: Flame Chart. Scroll dividers together with underlying chart. · cf857ce8
      loislo@chromium.org authored
      http://bugs.webkit.org/show_bug.cgi?id=113080
      
      Reviewed by Pavel Feldman.
      
      * inspector/front-end/FlameChart.js:
      (WebInspector.FlameChart.Calculator.prototype.grandMinimumBoundary):
      (WebInspector.FlameChart.prototype._canvasDragging):
      * inspector/front-end/TimelineGrid.js:
      (WebInspector.TimelineGrid.prototype.updateDividers):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146890 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      cf857ce8
    • mkwst@chromium.org's avatar
      CSP 1.1: Experiment with 'base-uri' directive. · 5b0379f6
      mkwst@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113307
      
      Reviewed by Jochen Eisinger.
      
      Source/WebCore:
      
      The 'base-uri' directive was introduced[1] as an experimental directive
      in CSP 1.1 after a bit of discussion[2][3]. The exact semantics will
      likely change, but it would be good for us to get some implementation
      experience with the API as currently specified, and to allow folks to
      play with the implementation to determine whether it meets the
      requirements the way we think it might.
      
      This patch is a first pass at that implementation: it will have no
      effect on ports that haven't enabled the CSP_NEXT flag.
      
      [1]: https://dvcs.w3.org/hg/content-security-policy/rev/4b89c246ea16
      [2]: http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0022.html
      [3]: http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0074.html
      
      Tests: http/tests/security/contentSecurityPolicy/1.1/base-uri-allow.html
             http/tests/security/contentSecurityPolicy/1.1/base-uri-deny.html
      
      * dom/Document.cpp:
      (WebCore::Document::processBaseElement):
          Check that the new base URI is allowed by CSP before using it as
          the document's base URI.
      * page/ContentSecurityPolicy.cpp:
          Add a constant for the new directive name (and, as a drive-by, split
          the list into CSP 1.0 and CSP 1.1 for clarity).
      (CSPDirectiveList):
          Add a property to hold the base URI policy directive value.
      (WebCore::CSPDirectiveList::checkSourceAndReportViolation):
          Customize the error message iff we're dealing with 'base-uri'.
      (WebCore::CSPDirectiveList::allowBaseURI):
          Check the given URI against the 'base-uri' directive's value,
          exactly as we do for every other source-list type of directive.
      (WebCore::CSPDirectiveList::addDirective):
          Accept 'base-uri' as a valid directive iff CSP_NEXT is set, and
          the embedder has opted-in via the runtime flag.
      (WebCore::ContentSecurityPolicy::allowBaseURI):
          Expose an API method on ContentSecurityPolicy to check URIs against
          the 'base-uri' directive's value.
      
      LayoutTests:
      
      * http/tests/security/contentSecurityPolicy/1.1/base-uri-allow-expected.txt: Added.
      * http/tests/security/contentSecurityPolicy/1.1/base-uri-allow.html: Added.
      * http/tests/security/contentSecurityPolicy/1.1/base-uri-deny-expected.txt: Added.
      * http/tests/security/contentSecurityPolicy/1.1/base-uri-deny.html: Added.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146886 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5b0379f6
    • anilsson@rim.com's avatar
      [BlackBerry] Main frame fixed divs not positioned correctly · 7a0056a7
      anilsson@rim.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112889
      
      Reviewed by Carlos Garcia Campos.
      
      PR 283363
      
      This was a regression from bug #112806. It caused main frame fixed
      handling to enter the iframe/scrollable div code path in LayerRenderer.
      
      Fixed by not setting the container for fixed flag on the main frame,
      the LayerRenderer expects this flag to be set only on non-mainframe
      containers.
      
      Only manually testable.
      
      * page/scrolling/blackberry/ScrollingCoordinatorBlackBerry.cpp:
      (WebCore::scrollLayerForFrame):
      (WebCore):
      (WebCore::ScrollingCoordinatorBlackBerry::setLayerIsContainerForFixedPositionLayers):
      (WebCore::ScrollingCoordinatorBlackBerry::setLayerIsFixedToContainerLayer):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146885 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7a0056a7
    • ch.dumez@sisa.samsung.com's avatar
      FormData::deepCopy() could use Vector::uncheckedAppend() · 5fd189c3
      ch.dumez@sisa.samsung.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113309
      
      Reviewed by Kenneth Rohde Christiansen.
      
      FormData::deepCopy() calls reserveInitialCapacity() on the Vector but then uses the
      regular append() method. This patch switches to using uncheckedAppend() method
      instead to bypass capacity checks as we already know it is sufficient.
      
      No new tests, no behavior change.
      
      * platform/network/FormData.cpp:
      (WebCore::FormData::deepCopy):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146884 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5fd189c3
    • commit-queue@webkit.org's avatar
      Unreviewed, rolling out r146879. · 5df66a42
      commit-queue@webkit.org authored
      http://trac.webkit.org/changeset/146879
      https://bugs.webkit.org/show_bug.cgi?id=113312
      
      Multiple layout test crashes in
      WebCore::RenderListItem::updateListMarkerNumbers (Requested by
      yurys on #webkit).
      
      Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2013-03-26
      
      Source/WebCore:
      
      * dom/Node.cpp:
      * dom/Node.h:
      (Node):
      * dom/NodeTraversal.cpp:
      * dom/NodeTraversal.h:
      (ElementTraversal):
      (NodeTraversal):
      * html/HTMLLIElement.cpp:
      (WebCore::HTMLLIElement::attach):
      * html/HTMLOListElement.cpp:
      (WebCore::HTMLOListElement::updateItemValues):
      (WebCore::HTMLOListElement::recalculateItemCount):
      * rendering/RenderCounter.cpp:
      (WebCore::previousInPreOrder):
      (WebCore::previousSiblingOrParent):
      (WebCore::parentElement):
      (WebCore::nextInPreOrder):
      * rendering/RenderListItem.cpp:
      (WebCore::enclosingList):
      (WebCore::RenderListItem::nextListItem):
      (WebCore::previousListItem):
      (WebCore::RenderListItem::calcValue):
      (WebCore::RenderListItem::explicitValueChanged):
      (WebCore::previousOrNextItem):
      (WebCore::RenderListItem::updateListMarkerNumbers):
      * rendering/RenderListItem.h:
      (RenderListItem):
      
      LayoutTests:
      
      * fast/dom/shadow/shadow-and-list-elements-expected.html:
      * fast/lists/positioned-count-crash-expected.txt:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146883 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5df66a42
    • morrita@google.com's avatar
      remoeveAllEventListeners() should be called to shadow trees · ac8a476d
      morrita@google.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113037
      
      Reviewed by Dimitri Glazkov.
      
      Source/WebCore:
      
      Document::removeAllEventListeners() doesn't traverse shadow tree, but we should.
      This change override Element::removeAllEventListeners() so that it cleans its shadow trees up.
      
      Test: fast/dom/shadow/shadow-tree-listener-clearance.html
      
      * dom/Element.cpp:
      (WebCore::Element::removeAllEventListeners):
      (WebCore):
      * dom/Element.h:
      (Element):
      * dom/ElementShadow.cpp:
      (WebCore::ElementShadow::removeAllEventListeners): Added.
      (WebCore):
      * dom/ElementShadow.h:
      (ElementShadow):
      
      LayoutTests:
      
      * fast/dom/shadow/resources/shadow-tree-listener-clearance-frame.html: Added.
      * fast/dom/shadow/shadow-tree-listener-clearance-expected.txt: Added.
      * fast/dom/shadow/shadow-tree-listener-clearance.html: Added.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146882 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ac8a476d
    • abucur@adobe.com's avatar
      Use DOM ordering for list counts · bfff4b8d
      abucur@adobe.com authored
      https://bugs.webkit.org/show_bug.cgi?id=110352
      
      Reviewed by Elliott Sprehn.
      
      Source/WebCore:
      
      Currently the list items ordering is made by traversing the render tree. This gives bad results for:
      - list items flown inside regions because they are not rendered as descendants of their DOM list ancestors.
      - list items matched to insertion points inside a shadow tree. The insertion point may be a child of a
      list so the numbering gets broken.
      
      To implement correct DOM ordering I've taken into account the fact that pseudo-elements can have display: list-item
      so they should be included when traversing the DOM tree. I've added helper methods on the NodeTraversal
      namespace that should allow easily traversing the tree including the pseudo-elements (e.g. firstChildWithPseudo
      for an element with pseudo-before will return the before PseudoElement). Using these helper methods I've implemented
      pre-order traversal methods aware of the pseudo-elements.
      An effect of this change is how the list items inside shadow tree update their counting. With the patch, if there's
      no <ol> or <ul> element on the ancestor chain of a <li> element to the shadow root, the list node will be considered the
      first parent of the <li> or the shadow root if there is no ancestor.
      The RenderListItem class now makes use of this new method of traversal, replacing the one based on the render tree.
      To simplify the CSS counters implementation, I've changed the traversal functions inside RenderCounter to also make use
      of this method. The CSS counters and the list items now have the same traversal algorithm.
      
      In later patches I'll add tests that should cover the regions and shadow DOM use cases.
      Tests bug for shadow DOM: https://bugs.webkit.org/show_bug.cgi?id=113193
      Tests bug for regions: https://bugs.webkit.org/show_bug.cgi?id=103975
      
      Tests: no new tests is this patch; added the correct expectations for fast/lists/positioned-count-crash.html
      and fast/dom/shadow/shadow-and-list-elements.html
      
      * dom/Node.cpp:
      (WebCore::Node::pseudoAwarePreviousSibling):
      (WebCore):
      (WebCore::Node::pseudoAwareNextSibling):
      (WebCore::Node::pseudoAwareFirstChild):
      (WebCore::Node::pseudoAwareLastChild):
      * dom/Node.h:
      (Node):
      * dom/NodeTraversal.cpp:
      (WebCore):
      (WebCore::NodeTraversal::previousIncludingPseudo):
      (NodeTraversal):
      (WebCore::NodeTraversal::nextIncludingPseudo):
      (WebCore::NodeTraversal::nextIncludingPseudoSkippingChildren):
      * dom/NodeTraversal.h:
      (ElementTraversal):
      (NodeTraversal):
      (WebCore::ElementTraversal::previousIncludingPseudo):
      (WebCore::ElementTraversal::nextIncludingPseudo):
      (WebCore::ElementTraversal::nextIncludingPseudoSkippingChildren):
      (WebCore::ElementTraversal::pseudoAwarePreviousSibling):
      * html/HTMLLIElement.cpp:
      (WebCore::HTMLLIElement::attach):
      * html/HTMLOListElement.cpp:
      (WebCore::HTMLOListElement::updateItemValues):
      (WebCore::HTMLOListElement::recalculateItemCount):
      * rendering/RenderCounter.cpp:
      (WebCore::previousInPreOrder):
      (WebCore::previousSiblingOrParent):
      (WebCore::parentElement):
      (WebCore::nextInPreOrder):
      * rendering/RenderListItem.cpp:
      (WebCore):
      (WebCore::enclosingList):
      (WebCore::RenderListItem::nextListItem):
      (WebCore::previousListItem):
      (WebCore::RenderListItem::calcValue):
      (WebCore::RenderListItem::explicitValueChanged):
      (WebCore::previousOrNextItem):
      (WebCore::RenderListItem::updateListMarkerNumbers):
      * rendering/RenderListItem.h:
      (RenderListItem):
      
      LayoutTests:
      
      The fast/dom/shadow/shadow-and-list-elements-expected.html has changed because the list items
      inside the shadow tree no longer see the root <ol> element.
      The test fast/lists/positioned-count-crash.html has the correct rendering after changing
      the list counting to be in DOM order.
      
      * fast/dom/shadow/shadow-and-list-elements-expected.html:
      * fast/lists/positioned-count-crash-expected.txt:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146879 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      bfff4b8d
    • allan.jensen@digia.com's avatar
      [Qt] Poor rounding in GraphicsContext::drawLineForText · 8659f808
      allan.jensen@digia.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113301
      
      Reviewed by Jocelyn Turcotte.
      
      Round the position of the line decoration, so lines on subpixel
      coordinates are not always rounded up.
      
      * platform/graphics/qt/GraphicsContextQt.cpp:
      (WebCore::GraphicsContext::drawLineForText):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146878 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8659f808
    • vsevik@chromium.org's avatar
      Web Inspector: Decorations in several consecutive lines are not moved correctly in DTE. · 13951e12
      vsevik@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113296
      
      Reviewed by Pavel Feldman.
      
      Separated removing and adding decorations so that moved decorations are not removed when next line is processed.
      
      * inspector/front-end/DefaultTextEditor.js:
      (WebInspector.TextEditorGutterPanel.prototype.textChanged):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146875 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      13951e12
    • yurys@chromium.org's avatar
      Remove references to non-chromium entries from WebCore.gypi (part 2) · 283c2f8c
      yurys@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=103124
      
      Reviewed by Pavel Feldman.
      
      * WebCore.gypi: removed unused references to gtk, cf, win and mac
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146874 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      283c2f8c