[wk2] LayoutTest imported/w3c/web-platform-tests/IndexedDB/fire-error-event-exception...
authorsihui_liu@apple.com <sihui_liu@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 30 Aug 2019 07:50:14 +0000 (07:50 +0000)
committersihui_liu@apple.com <sihui_liu@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 30 Aug 2019 07:50:14 +0000 (07:50 +0000)
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:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249316 268f45cc-cd09-0410-ab3c-d52691b4dbfc

LayoutTests/ChangeLog
LayoutTests/platform/gtk/TestExpectations
LayoutTests/platform/ios-wk2/TestExpectations
LayoutTests/platform/mac-wk2/TestExpectations
Source/WebCore/ChangeLog
Source/WebCore/Modules/indexeddb/IDBTransaction.cpp

index 22140b7..52f7bb2 100644 (file)
@@ -1,3 +1,16 @@
+2019-08-30  Sihui Liu  <sihui_liu@apple.com>
+
+        [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.
+
+        Update test expectations to PASS.
+
+        * platform/gtk/TestExpectations:
+        * platform/ios-wk2/TestExpectations:
+        * platform/mac-wk2/TestExpectations:
+
 2019-08-29  Devin Rousso  <drousso@apple.com>
 
         Web Inspector: Debugger: async event listener stack traces should be available in Workers
index 25edc8e..0eeafa6 100644 (file)
@@ -1752,9 +1752,6 @@ webkit.org/b/168780 fast/forms/input-first-letter-edit.html [ ImageOnlyFailure P
 
 webkit.org/b/116277 media/video-buffered.html [ Pass Failure ]
 
-webkit.org/b/169621 imported/w3c/web-platform-tests/IndexedDB/fire-error-event-exception.html [ Pass Failure ]
-webkit.org/b/169621 imported/w3c/web-platform-tests/IndexedDB/fire-success-event-exception.html [ Pass Failure ]
-
 webkit.org/b/170337 fast/repaint/obscured-background-no-repaint.html [ Pass Failure ]
 
 webkit.org/b/171600 css3/filters/composited-during-animation-layertree.html [ Pass Failure ]
index 05a3e46..11dbdee 100644 (file)
@@ -1135,9 +1135,6 @@ webkit.org/b/165814 imported/w3c/web-platform-tests/html/browsers/browsing-the-w
 webkit.org/b/161359 imported/w3c/web-platform-tests/html/browsers/browsing-the-web/scroll-to-fragid/scroll-to-top.html [ Pass Failure ]
 webkit.org/b/161631 imported/w3c/web-platform-tests/html/browsers/browsing-the-web/scroll-to-fragid/scroll-to-id-top.html [ Pass Failure ]
 
-webkit.org/b/169523 imported/w3c/web-platform-tests/IndexedDB/fire-error-event-exception.html [ Failure ]
-webkit.org/b/169760 imported/w3c/web-platform-tests/IndexedDB/fire-success-event-exception.html [ Pass Failure ]
-
 # rdar://problem/26477855
 http/tests/xmlhttprequest/logout.html [ Failure ]
 
index 1adee02..58e8210 100644 (file)
@@ -659,9 +659,6 @@ webkit.org/b/168336 [ Debug ] imported/w3c/web-platform-tests/streams/readable-s
 # Skipped because Mac doesn't have a key to show the context menu
 fast/events/context-activated-by-key-event.html [ Skip ]
 
-webkit.org/b/169621 imported/w3c/web-platform-tests/IndexedDB/fire-error-event-exception.html [ Pass Failure ]
-webkit.org/b/169760 imported/w3c/web-platform-tests/IndexedDB/fire-success-event-exception.html [ Pass Failure ]
-
 compositing/tiling/non-visible-window-tile-coverage.html [ Pass ]
 
 webkit.org/b/170629  memory/memory-pressure-simulation.html [ Pass Failure ]
index ce2a467..12c1e37 100644 (file)
@@ -1,3 +1,42 @@
+2019-08-30  Sihui Liu  <sihui_liu@apple.com>
+
+        [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.
+
+        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):
+
 2019-08-29  Devin Rousso  <drousso@apple.com>
 
         Web Inspector: Debugger: async event listener stack traces should be available in Workers
index 42243fb..63493b3 100644 (file)
@@ -446,7 +446,9 @@ void IDBTransaction::operationCompletedOnServer(const IDBResultData& data, IDBCl
     ASSERT(&operation.originThread() == &Thread::current());
 
     m_completedOnServerQueue.append({ &operation, data });
-    scheduleCompletedOperationTimer();
+
+    if (!m_currentlyCompletingRequest)
+        scheduleCompletedOperationTimer();
 }
 
 void IDBTransaction::scheduleCompletedOperationTimer()