1. 22 Aug, 2013 1 commit
  2. 21 Aug, 2013 2 commits
  3. 19 Aug, 2013 1 commit
    • ap@apple.com's avatar
      https://bugs.webkit.org/show_bug.cgi?id=119915 · 3503443f
      ap@apple.com authored
      REGRESSION(r154144): ASSERTION FAILED: m_history->provisionalItem() == m_requestedHistoryItem.get()
      Reviewed by Darin Adler.
      The issue was that we ended up having no CFNetwork cache in the testing session due
      to an incorrect cache model. There is a number of things not implemented when it
      comes to dynamically changing cache model as attempted by WebKitTestRunner, but
      the easiest way to get this going is to initialize it to correct value upfront.
      * WebKitTestRunner/TestController.cpp: (WTR::TestController::initialize):
      * platform/mac-wk2/TestExpectations: Unskipping the failing test.
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154301 268f45cc-cd09-0410-ab3c-d52691b4dbfc
  4. 16 Aug, 2013 2 commits
  5. 12 Aug, 2013 1 commit
  6. 03 Aug, 2013 1 commit
  7. 02 Aug, 2013 1 commit
  8. 01 Aug, 2013 1 commit
  9. 30 Jul, 2013 2 commits
  10. 23 Jul, 2013 1 commit
    • timothy_horton@apple.com's avatar
      Add a test for plug-in unavailability indicator obscurity detection · b0aa0e2d
      timothy_horton@apple.com authored
      Reviewed by Anders Carlsson.
      Test: plugins/unavailable-plugin-indicator-obscurity.html
      Expose the ability to test whether the unavailable plugin indicator
      is obscured via the internals object.
      * testing/Internals.cpp:
      * testing/Internals.h:
      * testing/Internals.idl:
      Expose RenderEmbeddedObject::isReplacementObscured as
      internals.isPluginUnavailabilityIndicatorObscured for testing purposes.
      Expose the ability to block plug-ins via pluginLoadPolicy to testRunner.
      * WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl:
      * WebKitTestRunner/InjectedBundle/TestRunner.cpp:
      * WebKitTestRunner/InjectedBundle/TestRunner.h:
      * WebKitTestRunner/TestInvocation.cpp:
      Add testRunner.setBlockAllPlugins function (and corresponding message to
      forward it through to TestController).
      * WebKitTestRunner/TestController.cpp:
      Initialize m_shouldBlockAllPlugins to false (and drive-by initialize m_handlesAuthenticationChallenges).
      Register our pluginLoadPolicy callback.
      Reset m_shouldBlockAllPlugins to false.
      Return the existing plugin load policy, unless setBlockAllPlugins(true)
      was called, in which case we reject all plugins with kWKPluginLoadPolicyBlocked.
      * WebKitTestRunner/TestController.h:
      Add a test that ensures that RenderEmbeddedObject accurately detects the
      various different ways the unavailable plugin dialog can be obscured.
      * platform/mac-wk2/TestExpectations:
      * platform/mac/TestExpectations:
      * plugins/unavailable-plugin-indicator-obscurity-expected.txt: Added.
      * plugins/unavailable-plugin-indicator-obscurity.html: Added.
      * Source/autotools/symbols.filter:
      Expose RenderEmbeddedObject::isReplacementObscured to internals.
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153054 268f45cc-cd09-0410-ab3c-d52691b4dbfc
  11. 19 Jul, 2013 1 commit
  12. 08 Jul, 2013 1 commit
  13. 02 Jul, 2013 1 commit
    • timothy_horton@apple.com's avatar
      constrainScrollPositionForOverhang needs to handle scrollOrigin correctly · 81079fd7
      timothy_horton@apple.com authored
      Reviewed by Anders Carlsson.
      Test: compositing/geometry/fixed-position-flipped-writing-mode.html
      WebCore makes use of constrainScrollPositionForOverhang not only for
      constraining fixed- and sticky-positioned elements to the viewport, but
      also for clamping the tile cache's visible rect.
      Therefore, constrainScrollPositionForOverhang needs to correctly take
      the scrollOrigin into account. The easiest way I saw to do this was to
      reimplement the function in terms of a pair of rect intersections
      between a virtual scrollable "viewport" and the document (with a bit
      of complication from headers and footers).
      The first intersection is performed, then if the viewport doesn't fit,
      it is pushed down and to the right, from the origin. Next, we intersect
      again, this time pushing the rect up by the amount it overflowed the document
      rect from the bottom right. This performs effectively the same constraint
      as previously, but handles the scrollOrigin correctly and is also somewhat
      easier to read and understand (with pictures).
      * page/scrolling/mac/ScrollingTreeScrollingNodeMac.mm:
      Subtract the scrollOrigin out of the offset passed to scrollOffsetForFixedPosition,
      it's expecting an offset without the origin included.
      * platform/ScrollableArea.cpp:
      Reimplement the function as described above.
      Add a test that ensures that fixed position works with a scrollable document
      and direction: rtl, which is one case where scrollOrigin is set.
      Disable the test on Mac WebKit1 because of https://bugs.webkit.org/show_bug.cgi?id=118269.
      * compositing/geometry/fixed-position-flipped-writing-mode-expected.txt: Added.
      * compositing/geometry/fixed-position-flipped-writing-mode.html: Added.
      * platform/mac/compositing/geometry/fixed-position-flipped-writing-mode-expected.png: Added.
      * platform/mac/TestExpectations:
      * platform/mac-wk2/TestExpectations:
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152303 268f45cc-cd09-0410-ab3c-d52691b4dbfc
  14. 27 Jun, 2013 1 commit
  15. 24 Jun, 2013 1 commit
    • jer.noble@apple.com's avatar
      [Mac] media/video-played-collapse.html is flakey on certain platforms. · 1e0e7703
      jer.noble@apple.com authored
      Reviewed by Beth Dakin.
      This test does not wait until a seek completes before issuing a play()
      command during its subtests. This can cause flakiness on some platforms
      where playback will begin from the pre-seek currentTime. Wait for the seek
      to complete before continuing the sub-tests.
      Additionally, a 2s watchdog timeout is present to catch stalled tests. This
      timeout is fine for short-duration sub-tests, but longer tests' durations
      approach this 2s timeout period. Make the timeout the test duration + 2s.
      * media/video-played-collapse-expected.txt:
      * media/video-played-collapse.html:
      * media/video-played.js:
      * platform/mac-wk2/TestExpectations:
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151942 268f45cc-cd09-0410-ab3c-d52691b4dbfc
  16. 20 Jun, 2013 1 commit
  17. 18 Jun, 2013 1 commit
  18. 10 Jun, 2013 1 commit
    • jer.noble@apple.com's avatar
      REGRESSION(r151302): Many broken webaudio/ tests on Mac port. · 6a93d537
      jer.noble@apple.com authored
      Reviewed by Chris Rogers.
      The new "pageConsentRequiredForAudioStart()" restriction was blocking playback event
      even when page consent was given. Remvoe the restriction immediately in that case.
      * Modules/webaudio/AudioContext.cpp:
      Re-enable the tests on mac-wk2 and add new baselines for codec and audiobuffersource tests.
      * platform/mac-wk2/TestExpectations:
      * platform/mac-wk2/webaudio/audiobuffersource-loop-points-expected.wav: Added.
      * platform/mac-wk2/webaudio/audiobuffersource-playbackrate-expected.wav: Added.
      * platform/mac-wk2/webaudio/codec-tests/aac/vbr-128kbps-44khz-expected.wav: Added.
      * platform/mac-wk2/webaudio/codec-tests/mp3/128kbps-44khz-expected.wav: Added.
      * platform/mac-wk2/webaudio/codec-tests/wav/24bit-22khz-resample-expected.wav: Added.
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151410 268f45cc-cd09-0410-ab3c-d52691b4dbfc
  19. 30 May, 2013 1 commit
    • eustas@chromium.org's avatar
      selectionStart/selectionEnd return "obsolete" values when requested during "input" event · e61a1275
      eustas@chromium.org authored
      Reviewed by Ryosuke Niwa.
      This patch defers firing "webkitEditableContentChanged" until new
      selection is applied to control. This makes selection during "input"
      more consistent and reliable.
      Background: "input" event is fired by "webkitEditableContentChanged"
      dispatcher. But "input" is scoped event, so under some conditions its
      dispatching may be deferred. When "input" dispatching is deferred,
      dispatcher observes updated selectionStart and selectionEnd.
      Otherwise values repersent state before applying editing command.
      So, to make selectionStart/End to be more predictable and useful, we
      need either always dispatch "input" before selection is updated, or
      always dispatch "input" after selection is updated.
      As it was mentioned, dispatching could be deferred by scoping. So
      dispatching before updating selection couldn't be guaranteed.
      Moreover, it will be hard to calculate updated selection in user
      code. On the other side - old selection could be easily tracked.
      So, it looks logically that we should guarantee dispatching "input"
      after updating selection. There are no execution paths in
      "webkitEditableContentChanged" dispatched that depends on current
      selection. So it is safe to fire this event after selection is updated.
      Test: editing/selection/caret-after-keypress.html
      * editing/Editor.cpp:
      Dispatch "input" event after new selection in applied.
      Test that cursor is up-to-date during "input" event.
      * editing/selection/caret-after-keypress-expected.txt: Added.
      * editing/selection/caret-after-keypress.html: Added.
      * platform/mac-wk2/TestExpectations: Exclude new test.
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151009 268f45cc-cd09-0410-ab3c-d52691b4dbfc
  20. 24 May, 2013 2 commits
  21. 23 May, 2013 4 commits
  22. 22 May, 2013 1 commit
  23. 20 May, 2013 2 commits
  24. 17 May, 2013 1 commit
    • ap@apple.com's avatar
      Text input is largely broken when there are subframes loading · e042b63d
      ap@apple.com authored
              Reviewed by Darin Adler.
              * UIProcess/PageClient.h:
              * UIProcess/API/mac/PageClientImpl.h:
              * UIProcess/API/mac/PageClientImpl.mm:
              (WebKit::PageClientImpl::updateSecureInputState): Separated secure input state
              updating into a separate function. Removed updateTextInputState, we don't need
              to go through PageClient to implement its behavior at all.
              (WebKit::PageClientImpl::dismissDictionaryLookupPanel): Added a FIXME.
              * UIProcess/API/mac/WKView.mm:
              * UIProcess/API/mac/WKViewInternal.h:
              Removed _updateTextInputStateIncludingSecureInputState.
              * UIProcess/WebPageProxy.h: Added m_temporarilyClosedComposition, which helps
              to figure out that WebCore decided to close a composition. The issue is that WebCore
              would first send an EditorState with hasComposition set to false, and with
              shouldIgnoreCompositionSelectionChange set to true, at which time we forget the
              previous m_editorState, but can't make any decisions based on this transient state.
              We should find a way to simplify this (maybe not send these updates with
              shouldIgnoreCompositionSelectionChange at all?)
              * UIProcess/WebPageProxy.cpp:
              (WebKit::WebPageProxy::WebPageProxy): Initialize m_temporarilyClosedComposition.
              (WebKit::WebPageProxy::didCommitLoadForFrame): Removed the code to kill a composition
              when any frame commits a load, which made no sense (along with surrounding code,
              which will unfortunately survive longer).
              (WebKit::WebPageProxy::editorStateChanged): Implemented state updating here,
              we don't need to go to WKView.mm to implement this logic. Figure out when WebCore
              discards a composition, and notify input methods about this.
              (WebKit::WebPageProxy::resetStateAfterProcessExited): Reset m_temporarilyClosedComposition.
              Added some FIXMEs.
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150291 268f45cc-cd09-0410-ab3c-d52691b4dbfc
  25. 16 May, 2013 1 commit
  26. 14 May, 2013 1 commit
    • ap@apple.com's avatar
      [Mac] Add tests for secure event input · 3469b9f8
      ap@apple.com authored
              Reviewed by Mark Rowe.
              * editing/secure-input: Added.
              * editing/secure-input/password-input-changed-type-expected.txt: Added.
              * editing/secure-input/password-input-changed-type.html: Added.
              * editing/secure-input/password-input-focusing-expected.txt: Added.
              * editing/secure-input/password-input-focusing-to-different-frame-expected.txt: Added.
              * editing/secure-input/password-input-focusing-to-different-frame.html: Added.
              * editing/secure-input/password-input-focusing.html: Added.
              * editing/secure-input/removed-password-input-expected.txt: Added.
              * editing/secure-input/removed-password-input.html: Added.
              * editing/secure-input/reset-state-on-navigation-expected.txt: Added.
              * editing/secure-input/reset-state-on-navigation.html: Added.
              * editing/secure-input/resources: Added.
              * editing/secure-input/resources/reset-state-on-navigation-target.html: Added.
              * platform/efl/TestExpectations:
              * platform/gtk/TestExpectations:
              * platform/mac-wk2/TestExpectations:
              * platform/mac/TestExpectations:
              * platform/qt/TestExpectations:
              * platform/win/TestExpectations:
              * platform/wincairo/TestExpectations:
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150090 268f45cc-cd09-0410-ab3c-d52691b4dbfc
  27. 29 Apr, 2013 2 commits
  28. 19 Apr, 2013 1 commit
  29. 18 Apr, 2013 2 commits
  30. 17 Apr, 2013 1 commit