1. 20 May, 2010 1 commit
    • morrita@google.com's avatar
      2010-05-20 MORITA Hajime <morrita@google.com> · 034e133e
      morrita@google.com authored
              Reviewed by Kent Tamura.
      
              2x execCommand ReadAV@NULL
              https://bugs.webkit.org/show_bug.cgi?id=35791
      
              This test passes if it doesn't crash.
      
              * editing/execCommand/35791-expected.txt: Added.
              * editing/execCommand/35791.html: Added.
      2010-05-20  MORITA Hajime  <morrita@google.com>
      
              Reviewed by Kent Tamura.
      
              2x execCommand ReadAV@NULL
              https://bugs.webkit.org/show_bug.cgi?id=35791
      
              In applyBlockStyle(), a node which is referred from
              nextParagraphStart sometimes removed from the document and goes
              orphan, and that causes an assertion failed. This is because
              moveParagraphs() replaces the node with a new one with some new
              styles applied. So we re-compute nextParagraphStart in that case.
      
              Test: editing/execCommand/35791.html
      
              * dom/Position.h:
              (WebCore::Position::isOrphan):
              * editing/ApplyStyleCommand.cpp:
              (WebCore::ApplyStyleCommand::applyBlockStyle):
              * editing/VisiblePosition.h:
              (WebCore::VisiblePosition::isOrphan):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@59828 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      034e133e
  2. 18 May, 2010 2 commits
    • tony@chromium.org's avatar
      2010-05-18 Tony Chang <tony@chromium.org> · b50d9cb2
      tony@chromium.org authored
              Reviewed by Ojan Vafai.
      
              REGRESSION: crash in WebCore::CompositeEditCommand::splitTreeToNode when indenting in an empty li
              https://bugs.webkit.org/show_bug.cgi?id=38232
      
              * editing/execCommand/crash-indenting-list-item-expected.txt: Added.
              * editing/execCommand/crash-indenting-list-item.html: Added.
      2010-05-18  Tony Chang  <tony@chromium.org>
      
              Reviewed by Ojan Vafai.
      
              REGRESSION: crash in WebCore::CompositeEditCommand::splitTreeToNode when indenting in an empty li
              https://bugs.webkit.org/show_bug.cgi?id=38232
      
              Test: editing/execCommand/crash-indenting-list-item.html
      
              * editing/IndentOutdentCommand.cpp:
              (WebCore::IndentOutdentCommand::tryIndentingAsListItem):
              (WebCore::IndentOutdentCommand::indentIntoBlockquote):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@59739 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b50d9cb2
    • dimich@chromium.org's avatar
      DragData::asURL() shouldn't do file validity checks · 69fcf7b7
      dimich@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=38711
      
      Patch by Daniel Cheng <dcheng@chromium.org> on 2010-05-18
      Reviewed by Darin Adler, Jian Li.
      
      WebCore:
      
      There's no point to trying to make sure the file is valid in
      DragData::asURL(). It's better to ask for forgiveness than to ask for
      permission, since asking for permission is prone to race conditions
      and results in unnecessary I/O.  Consumers of this function either:
      - need to verify the file exists themselves (e.g. the loader)
      - don't care about file validity (rich text drag-and-drop)
      
      * platform/chromium/DragDataChromium.cpp:
      (WebCore::DragData::asURL):
      
      WebKit/mac:
      
      Change [NSPasteboard _web_bestURL] to still return a file URL for paths
      that don't exist. Callers who care about the existence of the file or
      whether or not it is a directory should check themselves when they
      want to use the file. The directory check has been left in for now,
      since the Mac implementation of ResourceHandle, which uses this function
      indirectly via DragController::performDrag) handles directories somewhat
      non-intuitively: it opens the parent directory in the Finder, rather
      than opening the directory itself.
      
      * Misc/WebNSPasteboardExtras.mm:
      (-[NSPasteboard _web_bestURL]):
      
      LayoutTests:
      
      Several layout tests depended on the fact that dropping a file would
      never trigger navigation. This never happened to occur in the past,
      since it just so happened that the filenames used in the tests never
      resolved to files that exist. Since DragData::asURL() no longer tries
      to verify file existence, the layout tests were updated to either
      suppress navigation or log any navigation that should occur as part of
      the test.
      
      * editing/pasteboard/file-input-files-access-expected.txt:
      * editing/pasteboard/script-tests/file-input-files-access.js:
      (runTest.window.onbeforeunload):
      (runTest):
      * http/tests/security/clipboard/script-tests/clipboard-file-access.js:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@59689 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      69fcf7b7
  3. 17 May, 2010 2 commits
    • tkent@chromium.org's avatar
      2010-05-17 Sheriff Bot <webkit.review.bot@gmail.com> · fc9b6990
      tkent@chromium.org authored
              Unreviewed, rolling out r59652.
              http://trac.webkit.org/changeset/59652
              https://bugs.webkit.org/show_bug.cgi?id=39268
      
              file-input-files-access test is broken on Mac (Requested by
              dcheng on #webkit).
      
              * editing/pasteboard/file-input-files-access-expected.txt:
              * editing/pasteboard/script-tests/file-input-files-access.js:
              (runTest):
              * http/tests/security/clipboard/script-tests/clipboard-file-access.js:
      2010-05-17  Sheriff Bot  <webkit.review.bot@gmail.com>
      
              Unreviewed, rolling out r59652.
              http://trac.webkit.org/changeset/59652
              https://bugs.webkit.org/show_bug.cgi?id=39268
      
              file-input-files-access test is broken on Mac (Requested by
              dcheng on #webkit).
      
              * platform/chromium/DragDataChromium.cpp:
              (WebCore::DragData::asURL):
      2010-05-17  Sheriff Bot  <webkit.review.bot@gmail.com>
      
              Unreviewed, rolling out r59652.
              http://trac.webkit.org/changeset/59652
              https://bugs.webkit.org/show_bug.cgi?id=39268
      
              file-input-files-access test is broken on Mac (Requested by
              dcheng on #webkit).
      
              * Misc/WebNSPasteboardExtras.mm:
              (-[NSPasteboard _web_bestURL]):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@59655 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      fc9b6990
    • tkent@chromium.org's avatar
      2010-05-17 Daniel Cheng <dcheng@chromium.org> · bc5d1c48
      tkent@chromium.org authored
              DragData::asURL() shouldn't do file validity checks
              https://bugs.webkit.org/show_bug.cgi?id=38711
      
              Several layout tests depended on the fact that dropping a file would
              never trigger navigation. This never happened to occur in the past,
              since it just so happened that the filenames used in the tests never
              resolved to files that exist. Since DragData::asURL() no longer tries
              to verify file existence, the layout tests were updated to either
              suppress navigation or log any navigation that should occur as part of
              the test.
      
              * editing/pasteboard/file-input-files-access-expected.txt:
              * editing/pasteboard/script-tests/file-input-files-access.js:
              (runTest.window.onbeforeunload):
              (runTest):
              * http/tests/security/clipboard/script-tests/clipboard-file-access.js:
      2010-05-17  Daniel Cheng  <dcheng@chromium.org>
      
              Reviewed by Darin Adler.
      
              DragData::asURL() shouldn't do file validity checks
              https://bugs.webkit.org/show_bug.cgi?id=38711
      
              There's no point to trying to make sure the file is valid in
              DragData::asURL(). It's better to ask for forgiveness than to ask for
              permission, since asking for permission is prone to race conditions
              and results in unnecessary I/O.  Consumers of this function either:
              - need to verify the file exists themselves (e.g. the loader)
              - don't care about file validity (rich text drag-and-drop)
      
              * platform/chromium/DragDataChromium.cpp:
              (WebCore::DragData::asURL):
      2010-05-17  Daniel Cheng  <dcheng@chromium.org>
      
              Reviewed by Darin Adler.
      
              DragData::asURL() shouldn't do file validity checks
              https://bugs.webkit.org/show_bug.cgi?id=38711
      
              Change [NSPasteboard _web_bestURL] to still return a file URL for paths
              that don't exist. Callers who care about the existence of the file or
              whether or not it is a directory should check themselves when they
              want to use the file. The directory check has been left in for now,
              since the Mac implementation of ResourceHandle, which uses this function
              indirectly via DragController::performDrag) handles directories somewhat
              non-intuitively: it opens the parent directory in the Finder, rather
              than opening the directory itself.
      
              * Misc/WebNSPasteboardExtras.mm:
              (-[NSPasteboard _web_bestURL]):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@59652 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      bc5d1c48
  4. 16 May, 2010 2 commits
  5. 14 May, 2010 1 commit
    • adele@apple.com's avatar
      WebCore: Fix for https://bugs.webkit.org/show_bug.cgi?id=39095 · c8bca7b5
      adele@apple.com authored
      <rdar://problem/7984158> REGRESSION (r53085): Infinite recursion in Position::getInlineBoxAndOffset when changing writing direction to right-to-left
      
      Reviewed by Dave Hyatt.
      
      Test: editing/selection/applystyle-to-inline-inside-block.html
      
      * dom/Position.cpp: (WebCore::Position::getInlineBoxAndOffset): Now that this function correctly goes in and out of editable areas by calling
      downstreamIgnoringEditingBoundaries and upstreamIgnoringEditingBoundaries for blocks (added in r58665), we no longer need a special case to 
      jump out to the parent when we hit an inline (which was added in r53085 when this issue was introduced).
      
      LayoutTests: Test for https://bugs.webkit.org/show_bug.cgi?id=39095 
      <rdar://problem/7984158> REGRESSION (r53085): Infinite recursion in Position::getInlineBoxAndOffset when changing writing direction to right-to-left
      
      Reviewed by Dave Hyatt.
      
      * editing/selection/applystyle-to-inline-in-block-expected.txt: Added.
      * editing/selection/applystyle-to-inline-in-block.html: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@59516 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c8bca7b5
  6. 13 May, 2010 1 commit
    • enrica@apple.com's avatar
      Adding block elements to a block and removing them changes the height of the element. · fefcb1d6
      enrica@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=38874
      
      Reviewed by Dave Hyatt.
      
      WebCore: 
      
      The initial height of an empty editable block is different from the height of the same block after we add block elements
      and remove them.
              
      Test: editing/deleting/delete-block-contents-004.html
      
      * rendering/RenderBlock.cpp:
      (WebCore::RenderBlock::layoutBlock): resetting m_childrenInline flag to true when layout a block with no children.
      
      LayoutTests: 
      
      The initial height of an empty editable block is different from the height of the same block after we add block elements
      and remove them.
              
      * editing/deleting/delete-block-contents-004-expected.txt: Added.
      * editing/deleting/delete-block-contents-004.html: Added.
      The following tests results have been updated to reflect the new renderer structure.
      * editing/deleting/in-visibly-empty-root-expected.txt:
      * platform/mac/editing/deleting/5408255-expected.txt:
      * platform/mac/editing/deleting/delete-select-all-001-expected.txt:
      * platform/mac/editing/selection/4895428-1-expected.txt:
      * platform/mac/editing/selection/4895428-4-expected.txt:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@59385 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      fefcb1d6
  7. 12 May, 2010 4 commits
    • simon.fraser@apple.com's avatar
      2010-05-12 Sheriff Bot <webkit.review.bot@gmail.com> · 6360d4a8
      simon.fraser@apple.com authored
              Unreviewed, rolling out r59270.
              http://trac.webkit.org/changeset/59270
              https://bugs.webkit.org/show_bug.cgi?id=39044
      
              Caused a crash on some pages - bug 39042 (Requested by smfr on
              #webkit).
      
              * editing/deleting/delete-block-contents-004-expected.txt: Removed.
              * editing/deleting/delete-block-contents-004.html: Removed.
              * editing/deleting/in-visibly-empty-root-expected.txt:
              * platform/mac/editing/deleting/5408255-expected.txt:
              * platform/mac/editing/deleting/delete-select-all-001-expected.txt:
              * platform/mac/editing/selection/4895428-1-expected.txt:
              * platform/mac/editing/selection/4895428-4-expected.txt:
              * platform/mac/fast/events/mouseout-dead-node-expected.txt:
      2010-05-12  Sheriff Bot  <webkit.review.bot@gmail.com>
      
              Unreviewed, rolling out r59270.
              http://trac.webkit.org/changeset/59270
              https://bugs.webkit.org/show_bug.cgi?id=39044
      
              Caused a crash on some pages - bug 39042 (Requested by smfr on
              #webkit).
      
              * rendering/RenderBlock.cpp:
              (WebCore::RenderBlock::removeChild):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@59341 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6360d4a8
    • enrica@apple.com's avatar
      Adding block elements to a block and removing them changes the height of the element. · 0a98ac3e
      enrica@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=38874
      
      Reviewed by Dave Hyatt.
      
      WebCore: 
      
      The initial height of an empty editable block is different from the height of the same block after we add block elements
      and remove them.
              
      Test: editing/deleting/delete-block-contents-004.html
      
      * rendering/RenderBlock.cpp:
      (WebCore::RenderBlock::removeChild): m_childrenInline was set to true only when the Renderer is created
      and never reset to true when all the block elements contained are removed.
      
      LayoutTests: 
      
      * editing/deleting/delete-block-contents-004-expected.txt: Added.
      * editing/deleting/delete-block-contents-004.html: Added.
      The following tests have new results because of the height change and because we now have one less renderer after the DOM changes.
      * editing/deleting/in-visibly-empty-root-expected.txt:
      * platform/mac/editing/deleting/5408255-expected.txt:
      * platform/mac/editing/deleting/delete-select-all-001-expected.txt:
      * platform/mac/editing/selection/4895428-1-expected.txt:
      * platform/mac/editing/selection/4895428-4-expected.txt:
      * platform/mac/fast/events/mouseout-dead-node-expected.txt
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@59270 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0a98ac3e
    • eric@webkit.org's avatar
      2010-05-12 Eric Seidel <eric@webkit.org> · 0d69deff
      eric@webkit.org authored
              Unreviewed, rolling out r59245.
              http://trac.webkit.org/changeset/59245
              https://bugs.webkit.org/show_bug.cgi?id=38874
      
              Broke at least one test on multiple platforms
      
              * editing/deleting/delete-block-contents-004-expected.txt: Removed.
              * editing/deleting/delete-block-contents-004.html: Removed.
              * editing/deleting/in-visibly-empty-root-expected.txt:
              * platform/mac/editing/deleting/5408255-expected.txt:
              * platform/mac/editing/deleting/delete-select-all-001-expected.txt:
              * platform/mac/editing/selection/4895428-1-expected.txt:
              * platform/mac/editing/selection/4895428-4-expected.txt:
      2010-05-12  Eric Seidel  <eric@webkit.org>
      
              Unreviewed, rolling out r59245.
              http://trac.webkit.org/changeset/59245
              https://bugs.webkit.org/show_bug.cgi?id=38874
      
              Broke at least one test on multiple platforms
      
              * rendering/RenderBlock.cpp:
              (WebCore::RenderBlock::removeChild):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@59256 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0d69deff
    • enrica@apple.com's avatar
      Adding block elements to a block and removing them changes the height of the element. · 6f2cfd86
      enrica@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=38874
      
      Reviewed by Dave Hyatt.
      
      WebCore: 
      
      The initial height of an empty editable block is different from the height of the same block after we add block elements
      and remove them.
              
      Test: editing/deleting/delete-block-contents-004.html
      
      * rendering/RenderBlock.cpp:
      (WebCore::RenderBlock::removeChild): m_childrenInline was set to true only when the Renderer is created
      and never reset to true when all the block elements contained are removed.
      
      LayoutTests: 
      
      * editing/deleting/delete-block-contents-004-expected.txt: Added.
      * editing/deleting/delete-block-contents-004.html: Added.
      The following tests have new results because of the height change and because we now have one less renderer after the DOM changes.
      * editing/deleting/in-visibly-empty-root-expected.txt:
      * platform/mac/editing/deleting/5408255-expected.txt:
      * platform/mac/editing/deleting/delete-select-all-001-expected.txt:
      * platform/mac/editing/selection/4895428-1-expected.txt:
      * platform/mac/editing/selection/4895428-4-expected.txt:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@59245 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6f2cfd86
  8. 06 May, 2010 1 commit
    • ojan@chromium.org's avatar
      2010-05-05 Ojan Vafai <ojan@chromium.org> · 28f8b8b6
      ojan@chromium.org authored
              Reviewed by Darin Adler.
      
              shift+click on an existing selection doesn't work right
              https://bugs.webkit.org/show_bug.cgi?id=36542
      
              NSTextView behavior is to move the end of the selection
              closest to the shift-click. Win/Linux behavior is to always
              move the focus end of the selection.
      
              * editing/selection/script-tests/shift-click.js: Added.
              (shiftClick):
              (assertSelectionString):
              * editing/selection/shift-click-expected.txt: Added.
              * editing/selection/shift-click.html: Added.
              * platform/win/editing/selection/shift-click-expected.txt: Added.
      2010-05-05  Ojan Vafai  <ojan@chromium.org>
      
              Reviewed by Darin Adler.
      
              shift+click on an existing selection doesn't work right
              https://bugs.webkit.org/show_bug.cgi?id=36542
      
              NSTextView behavior is to move the end of the selection
              closest to the shift-click. Win/Linux behavior is to always
              move the focus end of the selection.
      
              Test: editing/selection/shift-click.html
      
              * page/EventHandler.cpp:
              (WebCore::textDistance):
              (WebCore::EventHandler::handleMousePressEventSingleClick):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@58892 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      28f8b8b6
  9. 04 May, 2010 1 commit
    • levin@chromium.org's avatar
      REGRESSION(r54368): Text drag-and-drop from input/textarea doesn't work · a14b4e15
      levin@chromium.org authored
      if the text is like a URL
      https://bugs.webkit.org/show_bug.cgi?id=38374
      
      Patch by Kent Tamura <tkent@chromium.org> on 2010-05-04
      Reviewed by David Levin (and unofficially by Enrica Casucci).
      
      WebCore:
      
      Since r54368, documentFragmentFromDragData() creates an <a> element
      with no anchor text for URL-like text dragged from input/textarea
      element. If such text is dropped to input/textarea element, the text
      is not inserted.
      To fix this problem, use the original text or the URL as an anchor
      text.
      
      Test: editing/pasteboard/drag-drop-url-text.html
      
      * page/DragController.cpp:
      (WebCore::documentFragmentFromDragData):
      
      LayoutTests:
      
      * editing/pasteboard/drag-drop-url-text-expected.txt: Added.
      * editing/pasteboard/drag-drop-url-text.html: Added.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@58780 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a14b4e15
  10. 03 May, 2010 1 commit
    • abarth@webkit.org's avatar
      2010-05-03 Abhishek Arya <inferno@chromium.org> · 616e41e4
      abarth@webkit.org authored
              Reviewed by Adam Barth.
      
              Tests that javascript cannot access clipboard.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * editing/execCommand/clipboard-access-expected.txt: Added.
              * editing/execCommand/clipboard-access.html: Added.
              * editing/execCommand/script-tests/clipboard-access.js: Added.
              (enabled):
              (whenEnabled):
      2010-05-03  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              Test: editing/execCommand/clipboard-access.html
      
              * WebCore.base.exp:
              * editing/EditorCommand.cpp:
              (WebCore::supportedCopyCut):
              (WebCore::supportedPaste):
              (WebCore::createCommandMap):
              * page/Settings.cpp:
              (WebCore::Settings::Settings):
              (WebCore::Settings::setJavaScriptCanAccessClipboard):
              * page/Settings.h:
              (WebCore::Settings::javaScriptCanAccessClipboard):
      2010-05-03  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * public/WebSettings.h:
              * src/WebSettingsImpl.cpp:
              (WebKit::WebSettingsImpl::setJavaScriptCanAccessClipboard):
              * src/WebSettingsImpl.h:
      2010-05-03  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * webkit/webkitwebsettings.cpp:
              (webkit_web_settings_class_init):
              (webkit_web_settings_set_property):
              (webkit_web_settings_get_property):
              (webkit_web_settings_copy):
              * webkit/webkitwebview.cpp:
              (webkit_web_view_update_settings):
              (webkit_web_view_settings_notify):
      2010-05-03  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * WebView/WebPreferenceKeysPrivate.h:
              * WebView/WebPreferences.mm:
              (+[WebPreferences initialize]):
              (-[WebPreferences javaScriptCanAccessClipboard]):
              (-[WebPreferences setJavaScriptCanAccessClipboard:]):
              * WebView/WebPreferencesPrivate.h:
              * WebView/WebView.mm:
              (-[WebView _preferencesChangedNotification:]):
      2010-05-03  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * Api/qwebsettings.cpp:
              (QWebSettingsPrivate::apply):
              * Api/qwebsettings.h:
      2010-05-03  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * Interfaces/IWebPreferencesPrivate.idl:
              * WebPreferenceKeysPrivate.h:
              * WebPreferences.cpp:
              (WebPreferences::initializeDefaultSettings):
              (WebPreferences::javaScriptCanAccessClipboard):
              (WebPreferences::setJavaScriptCanAccessClipboard):
              * WebPreferences.h:
              * WebView.cpp:
              (WebView::notifyPreferencesChanged):
      2010-05-03  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is enabled in test framework.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * DumpRenderTree/LayoutTestController.cpp:
              (setJavaScriptCanAccessClipboardCallback):
              (LayoutTestController::staticFunctions):
              * DumpRenderTree/LayoutTestController.h:
              * DumpRenderTree/chromium/LayoutTestController.cpp:
              (LayoutTestController::LayoutTestController):
              (LayoutTestController::setJavaScriptCanAccessClipboard):
              (LayoutTestController::overridePreference):
              * DumpRenderTree/chromium/LayoutTestController.h:
              * DumpRenderTree/chromium/TestShell.cpp:
              (TestShell::resetWebSettings):
              * DumpRenderTree/gtk/DumpRenderTree.cpp:
              (resetDefaultsToConsistentValues):
              * DumpRenderTree/gtk/LayoutTestControllerGtk.cpp:
              (LayoutTestController::setJavaScriptCanAccessClipboard):
              * DumpRenderTree/mac/DumpRenderTree.mm:
              (resetDefaultsToConsistentValues):
              * DumpRenderTree/mac/LayoutTestControllerMac.mm:
              (LayoutTestController::setJavaScriptCanAccessClipboard):
              * DumpRenderTree/qt/DumpRenderTreeQt.cpp:
              (WebCore::WebPage::WebPage):
              (WebCore::WebPage::resetSettings):
              * DumpRenderTree/qt/LayoutTestControllerQt.cpp:
              (LayoutTestController::setJavaScriptCanAccessClipboard):
              * DumpRenderTree/qt/LayoutTestControllerQt.h:
              * DumpRenderTree/win/DumpRenderTree.cpp:
              (resetDefaultsToConsistentValues):
              * DumpRenderTree/win/LayoutTestControllerWin.cpp:
              (LayoutTestController::setJavaScriptCanAccessClipboard):
              * DumpRenderTree/wx/LayoutTestControllerWx.cpp:
              (LayoutTestController::setJavaScriptCanAccessClipboard):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@58703 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      616e41e4
  11. 02 May, 2010 1 commit
    • mitz@apple.com's avatar
      Another case of <rdar://problem/7552959> REGRESSION: Infinite recursion in... · 78c284ed
      mitz@apple.com authored
      Another case of <rdar://problem/7552959> REGRESSION: Infinite recursion in Position::getInlineBoxAndOffset()
      https://bugs.webkit.org/show_bug.cgi?id=38445
      
      Reviewed by Simon Fraser.
      
      WebCore: 
      
      Test: editing/selection/mixed-editability-11.html
      
      * dom/Position.cpp:
      (WebCore::downstreamIgnoringEditingBoundaries): Added. Returns the furthest visually equivalent
      position downstream, crossing any editability boundaries.
      (WebCore::upstreamIgnoringEditingBoundaries): Similarly for upstream.
      (WebCore::Position::getInlineBoxAndOffset): Changed the logic for finding an inline box for positions
      whose node is a block flow. Instead of traversing the DOM, advance downstream or upstream as far as
      possible, crossing any editability boudaries. Infinite recursion is avoided by advancing all the way
      and checking that the new position is different from the starting position. Also replaced the specific
      test for buttons with the generic and more comprehensive canHaveChildrenForEditing().
      
      LayoutTests: 
      
      * editing/selection/mixed-editability-11-expected.txt: Added.
      * editing/selection/mixed-editability-11.html: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@58665 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      78c284ed
  12. 30 Apr, 2010 1 commit
    • ddkilzer@apple.com's avatar
      WebCore: Convert m_documentUnderMouse, m_dragInitiator to RefPtr. · 35884699
      ddkilzer@apple.com authored
      Eliminated unused m_dragInitiator accessor to prevent dereferencing.
      https://bugs.webkit.org/show_bug.cgi?id=37618
      
      Patch by Abhishek Arya <inferno@chromium.org> on 2010-04-30
      Reviewed by David Kilzer.
      
      Test: editing/pasteboard/drag-drop-iframe-refresh-crash.html
      
      * page/DragController.cpp:
      (WebCore::DragController::tryDocumentDrag):
      (WebCore::DragController::concludeEditDrag):
      * page/DragController.h:
      (WebCore::DragController::draggingImageURL):
      (WebCore::DragController::documentUnderMouse):
      
      LayoutTests: Tests for a crash when an image drag-drop operation happens inside a continuously refreshing iframe.
      https://bugs.webkit.org/show_bug.cgi?id=37618
      
      Patch by Abhishek Arya <inferno@chromium.org> on 2010-04-30
      Reviewed by David Kilzer.
      
      * editing/pasteboard/drag-drop-iframe-refresh-crash-expected.txt: Added.
      * editing/pasteboard/drag-drop-iframe-refresh-crash.html: Added.
      * editing/resources/drag-drop.html: Added.
      * platform/qt/Skipped:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@58616 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      35884699
  13. 29 Apr, 2010 1 commit
    • tkent@chromium.org's avatar
      2010-04-29 Kent Tamura <tkent@chromium.org> · c8834896
      tkent@chromium.org authored
              Reviewed by Darin Adler.
      
              Fix a bug that selection drag-and-drop doesn't work for input/textarea.
              https://bugs.webkit.org/show_bug.cgi?id=38175
      
              * editing/pasteboard/drag-drop-input-textarea-expected.txt: Added.
              * editing/pasteboard/drag-drop-input-textarea.html: Added.
      2010-04-29  Kent Tamura  <tkent@chromium.org>
      
              Reviewed by Darin Adler.
      
              Fix a bug that selection drag-and-drop doesn't work for input/textarea.
              https://bugs.webkit.org/show_bug.cgi?id=38175
      
              The code supposed the selected region was in the destination text
              field. It is not true in a case of drag-and-drop.
      
              Test: editing/pasteboard/drag-drop-input-textarea.html
      
              * dom/InputElement.cpp:
              (WebCore::InputElement::handleBeforeTextInsertedEvent):
              * html/HTMLTextAreaElement.cpp:
              (WebCore::HTMLTextAreaElement::handleBeforeTextInsertedEvent):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@58502 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c8834896
  14. 28 Apr, 2010 2 commits
  15. 27 Apr, 2010 2 commits
  16. 23 Apr, 2010 2 commits
  17. 22 Apr, 2010 3 commits
    • morrita@google.com's avatar
      2010-04-22 MORITA Hajime <morrita@google.com> · b28c9b9e
      morrita@google.com authored
              Not reviewed.
      
              Picked a review feedback left on:
              https://bugs.webkit.org/show_bug.cgi?id=37056
              LayoutTests/editing/selection/move-left-right.html is slow
              
              * editing/selection/move-left-right.html:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@58113 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b28c9b9e
    • abarth@webkit.org's avatar
      2010-04-22 Adam Barth <abarth@webkit.org> · bf00db5b
      abarth@webkit.org authored
              Unreviewed, rolling out r58069.
              http://trac.webkit.org/changeset/58069
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              Broke compile on Windows.
      
              * editing/execCommand/clipboard-access-expected.txt: Removed.
              * editing/execCommand/clipboard-access.html: Removed.
              * editing/execCommand/script-tests/clipboard-access.js: Removed.
      2010-04-22  Adam Barth  <abarth@webkit.org>
      
              Unreviewed, rolling out r58069.
              http://trac.webkit.org/changeset/58069
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              Broke compile on Windows.
      
              * WebCore.base.exp:
              * editing/EditorCommand.cpp:
              (WebCore::supportedPaste):
              (WebCore::createCommandMap):
              * page/Settings.cpp:
              (WebCore::Settings::Settings):
              * page/Settings.h:
      2010-04-22  Adam Barth  <abarth@webkit.org>
      
              Unreviewed, rolling out r58069.
              http://trac.webkit.org/changeset/58069
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              Broke compile on Windows.
      
              * public/WebSettings.h:
              * src/WebSettingsImpl.cpp:
              * src/WebSettingsImpl.h:
      2010-04-22  Adam Barth  <abarth@webkit.org>
      
              Unreviewed, rolling out r58069.
              http://trac.webkit.org/changeset/58069
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              Broke compile on Windows.
      
              * webkit/webkitwebsettings.cpp:
              (webkit_web_settings_class_init):
              (webkit_web_settings_set_property):
              (webkit_web_settings_get_property):
              (webkit_web_settings_copy):
              * webkit/webkitwebview.cpp:
              (webkit_web_view_update_settings):
              (webkit_web_view_settings_notify):
      2010-04-22  Adam Barth  <abarth@webkit.org>
      
              Unreviewed, rolling out r58069.
              http://trac.webkit.org/changeset/58069
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              Broke compile on Windows.
      
              * WebView/WebPreferenceKeysPrivate.h:
              * WebView/WebPreferences.mm:
              (+[WebPreferences initialize]):
              * WebView/WebPreferencesPrivate.h:
              * WebView/WebView.mm:
              (-[WebView _preferencesChangedNotification:]):
      2010-04-22  Adam Barth  <abarth@webkit.org>
      
              Unreviewed, rolling out r58069.
              http://trac.webkit.org/changeset/58069
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              Broke compile on Windows.
      
              * Api/qwebsettings.cpp:
              (QWebSettingsPrivate::apply):
              * Api/qwebsettings.h:
      2010-04-22  Adam Barth  <abarth@webkit.org>
      
              Unreviewed, rolling out r58069.
              http://trac.webkit.org/changeset/58069
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              Broke compile on Windows.
      
              * Interfaces/IWebPreferencesPrivate.idl:
              * WebPreferenceKeysPrivate.h:
              * WebPreferences.cpp:
              (WebPreferences::initializeDefaultSettings):
              * WebPreferences.h:
              * WebView.cpp:
              (WebView::notifyPreferencesChanged):
      2010-04-22  Adam Barth  <abarth@webkit.org>
      
              Unreviewed, rolling out r58069.
              http://trac.webkit.org/changeset/58069
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              Broke compile on Windows.
      
              * DumpRenderTree/LayoutTestController.cpp:
              (LayoutTestController::staticFunctions):
              * DumpRenderTree/LayoutTestController.h:
              * DumpRenderTree/chromium/LayoutTestController.cpp:
              (LayoutTestController::LayoutTestController):
              (LayoutTestController::overridePreference):
              * DumpRenderTree/chromium/LayoutTestController.h:
              * DumpRenderTree/chromium/TestShell.cpp:
              (TestShell::resetWebSettings):
              * DumpRenderTree/gtk/LayoutTestControllerGtk.cpp:
              * DumpRenderTree/mac/DumpRenderTree.mm:
              (resetDefaultsToConsistentValues):
              * DumpRenderTree/mac/LayoutTestControllerMac.mm:
              * DumpRenderTree/qt/DumpRenderTreeQt.cpp:
              (WebCore::WebPage::WebPage):
              (WebCore::WebPage::resetSettings):
              * DumpRenderTree/qt/LayoutTestControllerQt.cpp:
              * DumpRenderTree/qt/LayoutTestControllerQt.h:
              * DumpRenderTree/win/DumpRenderTree.cpp:
              (resetDefaultsToConsistentValues):
              * DumpRenderTree/win/LayoutTestControllerWin.cpp:
              * DumpRenderTree/wx/LayoutTestControllerWx.cpp:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@58072 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      bf00db5b
    • abarth@webkit.org's avatar
      2010-04-22 Abhishek Arya <inferno@chromium.org> · dfeb70e5
      abarth@webkit.org authored
              Reviewed by Adam Barth.
      
              Manual test to verify that javascript cannot access clipboard.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * editing/execCommand/clipboard-access-expected.txt: Added.
              * editing/execCommand/clipboard-access.html: Added.
              * editing/execCommand/script-tests/clipboard-access.js: Added.
              (enabled):
              (whenEnabled):
              (runTest):
      2010-04-22  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              Test: editing/execCommand/clipboard-access.html
      
              * WebCore.base.exp:
              * editing/EditorCommand.cpp:
              (WebCore::supportedCopyCut):
              (WebCore::supportedPaste):
              (WebCore::createCommandMap):
              * page/Settings.cpp:
              (WebCore::Settings::Settings):
              (WebCore::Settings::setJavaScriptCanAccessClipboard):
              * page/Settings.h:
              (WebCore::Settings::javaScriptCanAccessClipboard):
      2010-04-22  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * public/WebSettings.h:
              * src/WebSettingsImpl.cpp:
              (WebKit::WebSettingsImpl::setJavaScriptCanAccessClipboard):
              * src/WebSettingsImpl.h:
      2010-04-22  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * webkit/webkitwebsettings.cpp:
              (webkit_web_settings_class_init):
              (webkit_web_settings_set_property):
              (webkit_web_settings_get_property):
              (webkit_web_settings_copy):
              * webkit/webkitwebview.cpp:
              (webkit_web_view_update_settings):
              (webkit_web_view_settings_notify):
      2010-04-22  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * WebView/WebPreferenceKeysPrivate.h:
              * WebView/WebPreferences.mm:
              (+[WebPreferences initialize]):
              (-[WebPreferences javaScriptCanAccessClipboard]):
              (-[WebPreferences setJavaScriptCanAccessClipboard:]):
              * WebView/WebPreferencesPrivate.h:
              * WebView/WebView.mm:
              (-[WebView _preferencesChangedNotification:]):
      2010-04-22  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * Api/qwebsettings.cpp:
              (QWebSettingsPrivate::apply):
              * Api/qwebsettings.h:
      2010-04-22  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is disabled by default.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * Interfaces/IWebPreferencesPrivate.idl:
              * WebPreferenceKeysPrivate.h:
              * WebPreferences.cpp:
              (WebPreferences::initializeDefaultSettings):
              (WebPreferences::javaScriptCanAccessClipboard):
              (WebPreferences::setJavaScriptCanAccessClipboard):
              * WebPreferences.h:
              * WebView.cpp:
              (WebView::notifyPreferencesChanged):
      2010-04-22  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Adam Barth.
      
              Add support for controlling clipboard access from javascript.
              Clipboard access from javascript is enabled in test framework.
              https://bugs.webkit.org/show_bug.cgi?id=27751
      
              * DumpRenderTree/LayoutTestController.cpp:
              (setJavaScriptCanAccessClipboardCallback):
              (LayoutTestController::staticFunctions):
              * DumpRenderTree/LayoutTestController.h:
              * DumpRenderTree/chromium/LayoutTestController.cpp:
              (LayoutTestController::LayoutTestController):
              (LayoutTestController::setJavaScriptCanAccessClipboard):
              (LayoutTestController::overridePreference):
              * DumpRenderTree/chromium/LayoutTestController.h:
              * DumpRenderTree/chromium/TestShell.cpp:
              (TestShell::resetWebSettings):
              * DumpRenderTree/gtk/LayoutTestControllerGtk.cpp:
              (LayoutTestController::setJavaScriptCanAccessClipboard):
              * DumpRenderTree/mac/DumpRenderTree.mm:
              (resetDefaultsToConsistentValues):
              * DumpRenderTree/mac/LayoutTestControllerMac.mm:
              (LayoutTestController::setJavaScriptCanAccessClipboard):
              * DumpRenderTree/qt/DumpRenderTreeQt.cpp:
              (WebCore::WebPage::WebPage):
              (WebCore::WebPage::resetSettings):
              * DumpRenderTree/qt/LayoutTestControllerQt.cpp:
              (LayoutTestController::setJavaScriptCanAccessClipboard):
              * DumpRenderTree/qt/LayoutTestControllerQt.h:
              * DumpRenderTree/win/DumpRenderTree.cpp:
              (resetDefaultsToConsistentValues):
              * DumpRenderTree/win/LayoutTestControllerWin.cpp:
              (LayoutTestController::setJavaScriptCanAccessClipboard):
              * DumpRenderTree/wx/LayoutTestControllerWx.cpp:
              (LayoutTestController::setJavaScriptCanAccessClipboard):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@58069 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      dfeb70e5
  18. 21 Apr, 2010 1 commit
  19. 20 Apr, 2010 2 commits
    • rniwa@webkit.org's avatar
      Nested <ul>s are mishandled when converted to <ol> using execCommand('insertorderedlist') · dfb6424f
      rniwa@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=19539
      
      Reviewed by Justin Garcia.
      
      WebCore: 
      
      Fixes a bug where two consecutive lists are not merged if they have been converted
      from ordered/unordered lists inside another list.
      
      The bug was caused by InsertListCommand::doApply where it did not merge a newly inserted
      list element and its neighbors. This patch adds code to doApply so that after inserting
      the list element, it updates previousList and nextList to the outermost list elements around
      insertionPos under the same enclosing list. Because the next and the previous list elements
      are not necessarily visually next to the newly inserted element before moveParagraph moves
      the paragraph into the new list element, doApply merges lists after moveParagraph is called.
      
      Test: editing/execCommand/insert-lists-inside-another-list.html
      
      * editing/InsertListCommand.cpp:
      (WebCore::InsertListCommand::doApply): Modified as described above
      * editing/htmlediting.cpp:
      (WebCore::outermostEnclosingList): Added rootNode. Returns the outermost list element,
        which is a descendent of rootNode.
      * editing/htmlediting.h:
      
      LayoutTests: 
      
      Test to make sure InsertListCommand merges consecutive lists when converting
      ordered/unordered lists to the opposite type of lists inside another list.
      
      * editing/execCommand/insert-lists-inside-another-list-expected.txt: Added.
      * editing/execCommand/insert-lists-inside-another-list.html: Added.
      * editing/execCommand/script-tests/insert-lists-inside-another-list.js: Added.
      (testList):
      * platform/mac/editing/execCommand/create-list-from-range-selection-expected.txt:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@57954 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      dfb6424f
    • hamaji@chromium.org's avatar
      2010-04-20 Shinichiro Hamaji <hamaji@chromium.org> · 359e1319
      hamaji@chromium.org authored
              Reviewed by Darin Adler and Alexey Proskuryakov.
      
              A backslash in EUC-JP becomes to a yen sign when it is copied
              https://bugs.webkit.org/show_bug.cgi?id=36419
      
              * editing/execCommand/transpose-backslash-with-euc-expected.txt: Added.
              * editing/execCommand/transpose-backslash-with-euc.html: Added.
              * editing/pasteboard/copy-backslash-with-euc-expected.txt: Added.
              * editing/pasteboard/copy-backslash-with-euc.html: Added.
              * editing/pasteboard/resources/copy-backslash-euc.html: Added.
      2010-04-20  Shinichiro Hamaji  <hamaji@chromium.org>
      
              Reviewed by Darin Adler and Alexey Proskuryakov.
      
              A backslash in EUC-JP becomes to a yen sign when it is copied
              https://bugs.webkit.org/show_bug.cgi?id=36419
      
              Tests: editing/execCommand/transpose-backslash-with-euc.html
                     editing/pasteboard/copy-backslash-with-euc.html
      
              * editing/Editor.cpp: Remove an unnecessary displayStringModifiedByEncoding calls.
              (WebCore::Editor::addToKillRing):
              * editing/TextIterator.cpp: TextIterator can use RenderText::textWithoutTranscoding and now plainText() uses this version
              (WebCore::TextIterator::TextIterator):
              (WebCore::TextIterator::init):
              (WebCore::TextIterator::emitText):
              (WebCore::plainTextToMallocAllocatedBuffer):
              * editing/TextIterator.h:
              (WebCore::):
              * platform/mac/PasteboardMac.mm: Remove an unnecessary displayStringModifiedByEncoding call.
              (WebCore::Pasteboard::writeSelection):
              * platform/text/TextEncoding.h: Make backslashAsCurrencySymbol public.
              * rendering/RenderText.cpp: Add RenderText::textWithoutTranscoding
              (WebCore::RenderText::RenderText):
              (WebCore::RenderText::updateNeedsTranscoding):
              (WebCore::RenderText::styleDidChange):
              (WebCore::isInlineFlowOrEmptyText):
              (WebCore::RenderText::previousCharacter):
              (WebCore::RenderText::setTextInternal):
              (WebCore::RenderText::textWithoutTranscoding):
              (WebCore::RenderText::transformText):
              * rendering/RenderText.h:
              * rendering/RenderTextControl.cpp: Remove an unnecessary displayStringModifiedByEncoding call.
              (WebCore::RenderTextControl::setInnerTextValue):
              (WebCore::RenderTextControl::finishText):
              * rendering/RenderTextFragment.cpp:
              (WebCore::RenderTextFragment::previousCharacter):
              * rendering/RenderTextFragment.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@57940 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      359e1319
  20. 11 Apr, 2010 1 commit
    • tony@chromium.org's avatar
      2010-04-11 Tony Chang <tony@chromium.org> · e27e1f78
      tony@chromium.org authored
              Reviewed by Eric Seidel.
      
              [chromium] implement getData('text/html') for paste and drop events
              https://bugs.webkit.org/show_bug.cgi?id=37193
      
              * editing/pasteboard/onpaste-text-html-expected.txt: Added.
              * editing/pasteboard/onpaste-text-html.html: Added.
              * fast/events/ondrop-text-html-expected.txt: Added.
              * fast/events/ondrop-text-html.html: Added.
              * platform/gtk/Skipped:
              * platform/mac/Skipped:
              * platform/win/Skipped:
      2010-04-07  Tony Chang  <tony@chromium.org>
      
              Reviewed by Eric Seidel.
      
              [chromium] implement getData('text/html') for paste and drop events
              https://bugs.webkit.org/show_bug.cgi?id=37193
      
              Tests: editing/pasteboard/onpaste-text-html.html
                     fast/events/ondrop-text-html.html
      
              * platform/chromium/ClipboardChromium.cpp:
              (WebCore::):
              (WebCore::clipboardTypeFromMIMEType): add html type
              (WebCore::ClipboardChromium::clearData): implement clear text/html
              (WebCore::ClipboardChromium::getData): implement get text/html (similar to text/plain)
              (WebCore::ClipboardChromium::setData): implement set text/html
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@57464 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e27e1f78
  21. 02 Apr, 2010 1 commit
  22. 01 Apr, 2010 1 commit
    • tkent@chromium.org's avatar
      2010-04-01 MORITA Hajime <morrita@google.com> · 0a60dff4
      tkent@chromium.org authored
              Reviewed by Darin Adler.
      
              WebCore::Document::updateLayoutIgnorePendingStylesheets NULL pointer
              https://bugs.webkit.org/show_bug.cgi?id=31680
              Ownerless nodes leads a crash on DOMSelection APIs
              https://bugs.webkit.org/show_bug.cgi?id=36800
      
              * editing/selection/DOMSelection-DocumentType-expected.txt: Added.
              * editing/selection/DOMSelection-DocumentType.html: Added.
              * editing/selection/DOMSelection-crossing-document-expected.txt: Added.
              * editing/selection/DOMSelection-crossing-document.html: Added.
              * editing/selection/drag-in-iframe.html:
                Updated to follow follow behaviour change.
              * editing/selection/script-tests/DOMSelection-DocumentType.js: Added.
              * editing/selection/script-tests/DOMSelection-crossing-document.js: Added.
              (makeEditableDocument):
              (clear):
      2010-04-01  MORITA Hajime  <morrita@google.com>
      
              Reviewed by Darin Adler.
      
              WebCore::Document::updateLayoutIgnorePendingStylesheets NULL pointer
              https://bugs.webkit.org/show_bug.cgi?id=31680
              Ownerless nodes leads a crash on DOMSelection APIs
              https://bugs.webkit.org/show_bug.cgi?id=36800
      
              Added guards nodes from foreign documents to DOMSelection APIs.
      
              Tests: editing/selection/DOMSelection-DocumentType.html
                     editing/selection/DOMSelection-crossing-document.html
      
              * editing/VisiblePosition.cpp:
              (WebCore::VisiblePosition::canonicalPosition):
              * page/DOMSelection.cpp:
              (WebCore::DOMSelection::collapse):
              (WebCore::DOMSelection::setBaseAndExtent):
              (WebCore::DOMSelection::setPosition):
              (WebCore::DOMSelection::extend):
              (WebCore::DOMSelection::containsNode):
              (WebCore::DOMSelection::isValidForPosition):
              * page/DOMSelection.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@56962 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0a60dff4
  23. 26 Mar, 2010 1 commit
    • ojan@chromium.org's avatar
      2010-03-25 Ojan Vafai <ojan@chromium.org> · d178f86e
      ojan@chromium.org authored
              Reviewed by Darin Adler.
      
              shift+home/end and cmd+shift+left/right don't extend the selection correctly
              https://bugs.webkit.org/show_bug.cgi?id=36539
      
              * editing/selection/extend-after-mouse-selection.html:
              * editing/selection/extend-selection-expected.txt:
              Extending forward by lineboundary selects the whole line. Now extending backwards
              by lineboundary after the whole line is selected is a noop instead of collapsed
              the selection to the start.
              * editing/selection/move-begin-end.html:
              Just cleaned up this test.
              * platform/mac/editing/selection/extend-after-mouse-selection-expected.txt:
      2010-03-25  Ojan Vafai  <ojan@chromium.org>
      
              Reviewed by Darin Adler.
      
              shift+home/end and cmd+shift+left/right don't extend the selection correctly
              https://bugs.webkit.org/show_bug.cgi?id=36539
      
              * WebCore.base.exp:
              * editing/SelectionController.cpp:
              (WebCore::SelectionController::modify):
              * editing/SelectionController.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@56639 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d178f86e
  24. 25 Mar, 2010 2 commits
    • ojan@chromium.org's avatar
      2010-03-25 Ojan Vafai <ojan@chromium.org> · 4466c89c
      ojan@chromium.org authored
              Reviewed by David Levin.
      
              mouse-based selections are always directional on Window/Linux
              https://bugs.webkit.org/show_bug.cgi?id=25195
      
              The tests are modified to expect different things for Win/Linux vs. Mac.
      
              * editing/selection/5195166-1.html:
              * editing/selection/extend-after-mouse-selection.html:
              * editing/selection/extend-selection-after-double-click-expected.txt:
              * editing/selection/extend-selection-after-double-click.html:
              * platform/chromium-linux/editing/selection/5195166-1-expected.checksum: Removed.
              * platform/chromium-linux/editing/selection/5195166-1-expected.png: Removed.
              * platform/chromium-win/editing/selection/5195166-1-expected.checksum: Removed.
              * platform/chromium-win/editing/selection/5195166-1-expected.png: Removed.
              * platform/chromium-win/editing/selection/5195166-1-expected.txt: Removed.
              * platform/mac/editing/selection/5195166-1-expected.checksum: Removed.
              * platform/mac/editing/selection/5195166-1-expected.png: Removed.
              * platform/mac/editing/selection/5195166-1-expected.txt:
              * platform/qt/editing/selection/5195166-1-expected.txt: Removed.
              * platform/win/editing/selection/extend-after-mouse-selection-expected.txt:
      2010-03-25  Ojan Vafai  <ojan@chromium.org>
      
              Reviewed by David Levin.
      
              mouse-based selections are always directional on Windows/Linux
              https://bugs.webkit.org/show_bug.cgi?id=25195
      
              Change m_lastChangeWasHorizontalExtension to m_isDirectional
              and make m_isDirectional always be true for Windows/Linux.
      
              * editing/SelectionController.cpp:
              (WebCore::SelectionController::SelectionController):
              (WebCore::SelectionController::setSelection):
              (WebCore::SelectionController::setIsDirectional):
              (WebCore::SelectionController::willBeModified):
              When double-clicking, the base/extent will be in the middle
              of the selection instead of the start/end of it. Changed to
              maintain that modifications after double-click still move the
              start/end of the selection, not the base/extent.
              (WebCore::SelectionController::modify):
              * editing/SelectionController.h:
              * page/EventHandler.cpp:
              (WebCore::EventHandler::handleMousePressEventSingleClick):
              (WebCore::EventHandler::updateSelectionForMouseDrag):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@56567 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4466c89c
    • eric@webkit.org's avatar
      2010-03-25 Kinuko Yasuda <kinuko@chromium.org> · 274ac6c1
      eric@webkit.org authored
              Reviewed by David Levin.
      
              Rewrite the layout test editing/inserting/6633727 to use dumpAsText
              https://bugs.webkit.org/show_bug.cgi?id=31579
      
              * editing/inserting/6633727-expected.txt: Added.
              * editing/inserting/6633727.html:
              * editing/inserting/script-tests/6633727.js: Added.
              * platform/gtk/editing/inserting/6633727-expected.txt: Removed.
              * platform/mac/editing/inserting/6633727-expected.checksum: Removed.
              * platform/mac/editing/inserting/6633727-expected.png: Removed.
              * platform/mac/editing/inserting/6633727-expected.txt: Removed.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@56506 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      274ac6c1
  25. 19 Mar, 2010 1 commit
  26. 18 Mar, 2010 1 commit
    • ojan@chromium.org's avatar
      2010-03-12 Ojan Vafai <ojan@chromium.org> · 406daf8b
      ojan@chromium.org authored
              Reviewed by David Levin.
      
              smartdelete should only occur after double-click
              https://bugs.webkit.org/show_bug.cgi?id=35314
      
              * editing/deleting/non-smart-delete.html:
              * editing/pasteboard/drag-drop-modifies-page.html:
              * editing/pasteboard/page-zoom-expected.txt:
              Space is removed because we used to incorrectly smartpaste here.
              New behavior matches NSTextView.
              * editing/style/apply-through-end-of-document-expected.txt:
              The change here is that selectall + smartpaste doesn't put a BR,
              but selectall + normal-paste does. Not sure if that's a bug or not,
              but it's not a side effect of this change.
              * editing/style/style-boundary-005.html:
              * platform/mac/editing/deleting/non-smart-delete-expected.checksum:
              * platform/mac/editing/deleting/non-smart-delete-expected.png:
              * platform/mac/editing/deleting/non-smart-delete-expected.txt:
              * platform/mac/editing/execCommand/paste-1-expected.txt:
              * platform/mac/editing/execCommand/paste-2-expected.txt:
              * platform/mac/editing/pasteboard/drag-drop-modifies-page-expected.checksum:
              * platform/mac/editing/pasteboard/drag-drop-modifies-page-expected.png:
              * platform/mac/editing/pasteboard/drag-drop-modifies-page-expected.txt:
      
              * platform/mac/editing/selection/expanding-selections-expected.txt:
              * platform/mac/editing/selection/expanding-selections2-expected.txt:
              * platform/mac/editing/selection/triple-click-in-pre-expected.txt:
              The above three results change because granularity is no longer part of the seleciton,
              so changes in granularity don't fire selection change notifications.
      
              * platform/mac/editing/style/style-boundary-005-expected.checksum:
              * platform/mac/editing/style/style-boundary-005-expected.png:
              * platform/mac/editing/style/style-boundary-005-expected.txt:
      2010-03-12  Ojan Vafai  <ojan@chromium.org>
      
              Reviewed by David Levin.
      
              smartdelete should only occur after double-click
              https://bugs.webkit.org/show_bug.cgi?id=35314
      
              1. Consolidate all notions of selection-granularity into SelectionController.
              2. Now only mouse-based selections store a selection-granularity. This matches NSTextView.
      
              New tests were added in http://trac.webkit.org/changeset/55913.
      
              * WebCore.base.exp:
              * editing/MoveSelectionCommand.cpp:
              (WebCore::MoveSelectionCommand::MoveSelectionCommand):
              (WebCore::MoveSelectionCommand::doApply):
              * editing/MoveSelectionCommand.h:
              (WebCore::MoveSelectionCommand::create):
              * editing/SelectionController.cpp:
              (WebCore::SelectionController::SelectionController):
              (WebCore::SelectionController::setSelection):
              (WebCore::SelectionController::modify):
              (WebCore::SelectionController::clear):
              * editing/SelectionController.h:
              (WebCore::SelectionController::setSelection):
              (WebCore::SelectionController::granularity):
              * editing/VisibleSelection.cpp:
              (WebCore::VisibleSelection::VisibleSelection):
              (WebCore::VisibleSelection::expandUsingGranularity):
              (WebCore::VisibleSelection::setStartAndEndFromBaseAndExtentRespectingGranularity):
              (WebCore::VisibleSelection::validate):
              * editing/VisibleSelection.h:
              (WebCore::operator==):
              * loader/FrameLoader.cpp:
              (WebCore::FrameLoader::clear):
              * page/DOMSelection.cpp:
              (WebCore::DOMSelection::extend):
              * page/DragController.cpp:
              (WebCore::DragController::concludeEditDrag):
              * page/EventHandler.cpp:
              (WebCore::EventHandler::selectClosestWordFromMouseEvent):
              (WebCore::EventHandler::selectClosestWordOrLinkFromMouseEvent):
              (WebCore::EventHandler::handleMousePressEventTripleClick):
              (WebCore::EventHandler::handleMousePressEventSingleClick):
              (WebCore::EventHandler::updateSelectionForMouseDrag):
              * page/Frame.cpp:
              (WebCore::Frame::Frame):
              (WebCore::Frame::selectionGranularity):
              * page/Frame.h:
              * rendering/RenderTextControl.cpp:
              (WebCore::RenderTextControl::setSelectionRange):
      2010-03-12  Ojan Vafai  <ojan@chromium.org>
      
              Reviewed by David Levin.
      
              smartdelete should only occur after double-click
              https://bugs.webkit.org/show_bug.cgi?id=35314
      
              * src/WebFrameImpl.cpp:
              (WebKit::WebFrameImpl::selectWordAroundPosition):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@56175 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      406daf8b
  27. 16 Mar, 2010 1 commit