[Webkit-unassigned] [Bug 60881] [Qt] Inspector may close at the start of the next inspector test in DRT

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=60881


Zoltan Herczeg <zherczeg at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |apavlov at chromium.org




--- Comment #13 from Zoltan Herczeg <zherczeg at webkit.org>  2011-06-08 09:36:55 PST ---
I think it is very important to fix this bug. Today it caused new flakey tests! I tried to raise the visibility of the bug, and contacted the inspector developers.

Basically the issue is:
setTimeout(A, 0); setTimeout(B, 0) -> in this case, nothing guarantees, that A runs first, B later. It is likely, but not necessary. The setTimeout only guarantees, that the function will eventually be called.

Both "layoutTestController.closeWebInspector()" and "setTimeout(function() {
layoutTestController.notifyDone(); }, 0)" starts a setTimeout async call. If layoutTestController.notifyDone() comes first, the next test is starting to run. It opens, an inspector (without closing the previous one, etc.) However, the first processed message will be closeInspector(). Later the runInInspector or something fails, since there is no inspector. Since it has no return value, you don't even know that the call is failed. After that, the test stops, and wait for a watchdog timeout event.

Short, but stupid fix:

   setTimeout(function() {
      layoutTestController.notifyDone();
   }, 100 /* much bigger than 0 */);

It will slow down the inspector tests, but will likely works.

More clever idea:
Add a new bool function to DRT, which returns true, if the inspector exists. Before layoutTestController.notifyDone(), check this value, and if it is true, start another setTimeout() call. This is difficult solution, since affects all inspectors, but I feel this is the correct one. However, I don't want to start working on it until someone says this is the best solution. Any better idea is welcome.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.