Bug 31164 - [Qt] [DRT] Fix wrong logic in LayoutTestController processWork
: [Qt] [DRT] Fix wrong logic in LayoutTestController processWork
Status: RESOLVED FIXED
: WebKit
Tools / Tests
: 528+ (Nightly build)
: PC Mac OS X 10.5
: P2 Normal
Assigned To:
:
: Qt
:
: 30573
  Show dependency treegraph
 
Reported: 2009-11-05 05:02 PST by
Modified: 2009-11-08 19:13 PST (History)


Attachments
(committed in r50622) patch (2.11 KB, patch)
2009-11-05 05:09 PST, Antonio Gomes
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-11-05 05:02:23 PST
Qt's DRT logic for processing the WorkQueue is working differently from other DRT ports (e.g. mac, gtk and win):

void LayoutTestController::processWork()
  (..)
  if (!WorkQueue::shared()->processWork() && !shouldWaitUntilDone()) {
     emit done();


notice the first "!". It makes queue processing stop when if should proceed ('true' here means that queue is done and we are ok to finish).
------- Comment #1 From 2009-11-05 05:03:01 PST -------
for reference:

GTK:
static gboolean processWork(void* data)
{
  // if we finish all the commands, we're ready to dump state
  if (WorkQueue::shared()->processWork() && !gLayoutTestController->waitToDump())
     dump();

WIN:
void FrameLoadDelegate::processWork()
{
  (...)
  // if we finish all the commands, we're ready to dump state
  if (WorkQueue::shared()->processWork() && !::gLayoutTestController->waitToDump())
    dump();

MAC:
- (void)processWork:(id)dummy
{
  (...)
  // if we finish all the commands, we're ready to dump state
  if (WorkQueue::shared()->processWork() && !gLayoutTestController->waitToDump())
    dump();
------- Comment #2 From 2009-11-05 05:09:53 PST -------
Created an attachment (id=42560) [details]
patch

patch make LayoutTestController::proccessWork to dump whole if WorkQueue returns 'true'

it makes qt compliant to other drt's (mac, win, gtk)
------- Comment #3 From 2009-11-07 00:32:56 PST -------
(From update of attachment 42560 [details])
Seems plausible.
------- Comment #4 From 2009-11-08 09:27:46 PST -------
r50622