Changeset 249316 in webkit


Ignore:
Timestamp:
Aug 30, 2019 12:50:14 AM (5 years ago)
Author:
sihui_liu@apple.com
Message:

[wk2] LayoutTest imported/w3c/web-platform-tests/IndexedDB/fire-error-event-exception.html is a flaky failure
​https://bugs.webkit.org/show_bug.cgi?id=169621

Reviewed by Alex Christensen.

Source/WebCore:

Event handlers of IDB objects were called in unexpected order because of race, which made the console messages
in the tests come out of order.
Usually, an operation/request result is handled as follows:

  1. IDBServer sends IDBResultData to IDBClient.
  2. IDBClient receives IDBResultData and finishes a IDBTransaction operation with that result.
  3. IDBTransaction schedules operation completed timer.
  4. (Some time later) Timer fires, and IDBTransaction completes a request with the result and dispatches event.
  5. (Some time later) IDBTransaction is notified that event is dispatched. If there are other results received,

IDBTransaction schedules operation completed timer.

In previous implementation, if the IDBClient received a second IDBResultData for the same IDBTransaction between
step 3 and step 4, it would not schedule timer because timer was still active; if it received the result between
step 4 and step 5, it would schedule timer again.

Consider a flow like this:
result1 of transaction1 received, timer of transaction1 scheduled
result2 of transaction2 received, timer of transaction2 scheduled
result3 of transaction1 is received, timer of transaction1 active so no scheduling
timer of transaction1 fired, event1 to be dispatched to request1
timer of transaction2 fired, event2 to be dispatched to request2
result4 of transaction2 received, timer of transaction2 scheduled
event1 dispatched, timer of transaction1 scheduled (for handling result3)
event2 dispatched, timer of transaction2 active so no scheduling
timer of transaction2 fired, event3 to dispatch to request4
timer of transaction1 fired, event4 to dispatch to request3

request4 would get event before request3, though result3 was received before result4. We should stop scheduling
event if an IDBTransaction is in between step 4 and 5, which means its m_currentlyCompletingRequest is not null.

  • Modules/indexeddb/IDBTransaction.cpp:

(WebCore::IDBTransaction::operationCompletedOnServer):

LayoutTests:

Update test expectations to PASS.

  • platform/gtk/TestExpectations:
  • platform/ios-wk2/TestExpectations:
  • platform/mac-wk2/TestExpectations:
Location:
trunk
Files:
6 edited

Legend:

Unmodified
Added
Removed

  • trunk/LayoutTests/ChangeLog

    r249315 r249316  
     12019-08-30  Sihui Liu  <sihui_liu@apple.com>
     2
     3        [wk2] LayoutTest imported/w3c/web-platform-tests/IndexedDB/fire-error-event-exception.html is a flaky failure
     4        https://bugs.webkit.org/show_bug.cgi?id=169621
     5
     6        Reviewed by Alex Christensen.
     7
     8        Update test expectations to PASS.
     9
     10        * platform/gtk/TestExpectations:
     11        * platform/ios-wk2/TestExpectations:
     12        * platform/mac-wk2/TestExpectations:
     13
    1142019-08-29  Devin Rousso  <drousso@apple.com>
    215

  • trunk/LayoutTests/platform/gtk/TestExpectations

    r249278 r249316  
    17531753webkit.org/b/116277 media/video-buffered.html [ Pass Failure ]
    17541754
    1755 webkit.org/b/169621 imported/w3c/web-platform-tests/IndexedDB/fire-error-event-exception.html [ Pass Failure ]
    1756 webkit.org/b/169621 imported/w3c/web-platform-tests/IndexedDB/fire-success-event-exception.html [ Pass Failure ]
    1757 
    17581755webkit.org/b/170337 fast/repaint/obscured-background-no-repaint.html [ Pass Failure ]
    17591756

  • trunk/LayoutTests/platform/ios-wk2/TestExpectations

    r249194 r249316  
    11361136webkit.org/b/161631 imported/w3c/web-platform-tests/html/browsers/browsing-the-web/scroll-to-fragid/scroll-to-id-top.html [ Pass Failure ]
    11371137
    1138 webkit.org/b/169523 imported/w3c/web-platform-tests/IndexedDB/fire-error-event-exception.html [ Failure ]
    1139 webkit.org/b/169760 imported/w3c/web-platform-tests/IndexedDB/fire-success-event-exception.html [ Pass Failure ]
    1140 
    11411138# rdar://problem/26477855
    11421139http/tests/xmlhttprequest/logout.html [ Failure ]

  • trunk/LayoutTests/platform/mac-wk2/TestExpectations

    r249107 r249316  
    660660fast/events/context-activated-by-key-event.html [ Skip ]
    661661
    662 webkit.org/b/169621 imported/w3c/web-platform-tests/IndexedDB/fire-error-event-exception.html [ Pass Failure ]
    663 webkit.org/b/169760 imported/w3c/web-platform-tests/IndexedDB/fire-success-event-exception.html [ Pass Failure ]
    664 
    665662compositing/tiling/non-visible-window-tile-coverage.html [ Pass ]
    666663

  • trunk/Source/WebCore/ChangeLog

    r249315 r249316  
     12019-08-30  Sihui Liu  <sihui_liu@apple.com>
     2
     3        [wk2] LayoutTest imported/w3c/web-platform-tests/IndexedDB/fire-error-event-exception.html is a flaky failure
     4        https://bugs.webkit.org/show_bug.cgi?id=169621
     5
     6        Reviewed by Alex Christensen.
     7
     8        Event handlers of IDB objects were called in unexpected order because of race, which made the console messages
     9        in the tests come out of order.
     10        Usually, an operation/request result is handled as follows:
     11        1. IDBServer sends IDBResultData to IDBClient.
     12        2. IDBClient receives IDBResultData and finishes a IDBTransaction operation with that result.
     13        3. IDBTransaction schedules operation completed timer.
     14        4. (Some time later) Timer fires, and IDBTransaction completes a request with the result and dispatches event.
     15        5. (Some time later) IDBTransaction is notified that event is dispatched. If there are other results received,
     16        IDBTransaction schedules operation completed timer.
     17
     18        In previous implementation, if the IDBClient received a second IDBResultData for the same IDBTransaction between
     19        step 3 and step 4, it would not schedule timer because timer was still active; if it received the result between
     20        step 4 and step 5, it would schedule timer again.
     21
     22        Consider a flow like this:
     23        result1 of transaction1 received, timer of transaction1 scheduled
     24        result2 of transaction2 received, timer of transaction2 scheduled
     25        result3 of transaction1 is received, timer of transaction1 active so no scheduling
     26        timer of transaction1 fired, event1 to be dispatched to request1
     27        timer of transaction2 fired, event2 to be dispatched to request2
     28        result4 of transaction2 received, timer of transaction2 scheduled
     29        event1 dispatched, timer of transaction1 scheduled (for handling result3)
     30        event2 dispatched, timer of transaction2 active so no scheduling
     31        timer of transaction2 fired, event3 to dispatch to request4
     32        timer of transaction1 fired, event4 to dispatch to request3
     33
     34        request4 would get event before request3, though result3 was received before result4. We should stop scheduling
     35        event if an IDBTransaction is in between step 4 and 5, which means its m_currentlyCompletingRequest is not null.
     36
     37        * Modules/indexeddb/IDBTransaction.cpp:
     38        (WebCore::IDBTransaction::operationCompletedOnServer):
     39
    1402019-08-29  Devin Rousso  <drousso@apple.com>
    241

  • trunk/Source/WebCore/Modules/indexeddb/IDBTransaction.cpp

    r248846 r249316  
    447447
    448448    m_completedOnServerQueue.append({ &operation, data });
    449     scheduleCompletedOperationTimer();
     449
     450    if (!m_currentlyCompletingRequest)
     451        scheduleCompletedOperationTimer();
    450452}
    451453
Note: See TracChangeset for help on using the changeset viewer.