Repro at its simplest:

<script>
  const db = openDatabase('websql-print-conflict', 1, '', 5000000)

  db.transaction(function (tx) {
    tx.executeSql(`CREATE TABLE IF NOT EXISTS test (name TEXT)`)
  })

  db.transaction(function (tx) {
     tx.executeSql(`INSERT INTO test VALUES (?)`, ['won\'t insert in chrome 57 when print invoked after'])
  })

  window.print()
</script>

Able to reproduce this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12 using chrome latest stable M57-57.0.2987.98. This issue is not observed on #57.0.2987.0 and 58.0.2988.0, Hence providing manual bisect information below.

CL from omahaproxy:
-------------------
https://chromium.googlesource.com/chromium/src/+log/57.0.2987.0..58.0.2988.0?pretty=fuller&n=10000

From the above change log suspecting below change

Review URL: https://codereview.chromium.org/2641123004

shess@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note: Since this is a recent regression observed in latest stable adding RB-Stable, please feel free to edit if this is not the case.

Thanks!

URGENT - PTAL ASAP.

Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you!

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M58.

The change in question about a billion% unlikely to be relevant to this.

That's a huge branch-crossing CL range, a ton of things happened.  Is there any chance of getting a tighter range on that?

WRT "ReleaseBlock-Stable", WebSQL has been deprecated since 2010, and the print-dialog thing means it's pretty unlikely.  So WRT WebSQL itself, I'm not sure this warrants blocking, but it's possible that it's a symptom of a bigger problem with events getting messed up, in which case _that_ might be worth blocking things.

So I think it'll have to simmer for a couple hours while people look into it.

Here's a more-visible repro case.  In Chrome 56.0.2924.87 what happens is that the print dialog comes up, then after cancel you see the additional output as the transactions fire.  In 59.0.3041.0, there is no additional output at any point.

I suspect that the print panel is somehow clearing an event queue or something like that.  If so, that is probably a general problem with many other interactions.  I cannot offhand think of something to look for.

Dammit, the repro case is attached.  I can repro using it as a file: URL.

Deleted: websql-print.html 1.2 KB

websql-print.html 1.2 KB View Download

Bisect?

Please find the manual bisect range which I got for the test provided in Comment#8 :

Last good build : 57.0.2987.35 
First Bad build : 57.0.2987.37

Change log :https://chromium.googlesource.com/chromium/src/+log/57.0.2987.35..57.0.2987.37?pretty=fuller&n=10000

Thank you  jsbell@

Suspecting CL : https://chromium.googlesource.com/chromium/src/+/91f69c5c73122c96f0690490d09b176526bf975b

If Cl listed at #11 is culprit and it will be a safe to revert, then please revert the change (It got rejected for M56 so we can leave without in M57 as well https://bugs.chromium.org/p/chromium/issues/detail?id=684947#c26).

I DO NOT KNOW WHAT I AM DOING, HERE!

But I do know how to test this repro, and how to revert a CL, and reverting that CL "fixes" this problem.

But I don't know if it should be considered the right thing to do, so I'm happy to let someone else make that decision.

Thank you shess@.

nhiroki@, ptal comment #12 and #13. Thank you.

I did the trunk bisect given the bug was also reproducible on Dev and Canary channels, Below is the bisect and we were spot on with the Suspecting CL :

You are probably looking for a change made after 448172 (known good), but no later than 448173 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/112c3d120a80a3e37590571b61a6a924ead2b935..04055dd2786e27cde8d210b68e7a726fab6d0c42

(CC to reviewers of my patch)

I don't understand how this happens yet. My patch just moved non-JS-timer tasks from the timer task runner to the unthrottled task runner. Some of them could assume they run on the timer task runner...?

Anyway, I'll take a closer look at this later (because I'm about to leave for the office).

https://chromium.googlesource.com/chromium/src/+/91f69c5c73122c96f0690490d09b176526bf975b is critical and should not be reverted. We've received many complains about postMessage etc being throttled and we do want to unthrottle them in M57.

Something is very strange going on.

1. When TaskType::DatabaseAccess is mapped to Timer or Loading task runner, everything is fine.
2. When TaskType::DatabaseAccess is mapped to Platform::current()->{current,main}Thread()->getWebTaskRunner(), everything fails.
3. When unthrottledTaskRunner is accessed from getTaskType, it is created inside an accessor.

Most likely, this is due to DatabaseAccess living on a separate thread and breaking some of our assumptions.

Please do not revert the patch in question. The problem is larger than that and reverting the patch will not fix the underlying cause. It is my top priority, I will look into this first thing tomorrow. 

altmin@, thank you for the investigation. tzik@ and I are now taking a look at this. I'll hand this over to you if we cannot fix this in our timezone (JST).

I think the mechanism is around here:
https://cs.chromium.org/chromium/src/out/Debug/gen/blink/bindings/modules/v8/V8DatabaseCallback.cpp?dr=C&l=39

The print dialog is a modal dialog that suspend the document. The suspension stops task queues other than the unthrottled queue, and V8DatabaseCallback cancels the callback if it runs on a suspended document.

So, I think we should move TaskType::DatabaseAccess from the unthrottled queue to the loading queue as a quick fix for the stable channel, and suspend the unthrottled queue on the document suspension.

Changed the OS label to specific ones for TPMs.

Can you explain how this affects Android? The steps in the original report don't seem like they'd be run on a mobile device often; but are scripts like c#2 common on the mobile web?

What is the end user use case for someone using the browser? 

amineer@: This is a problem in the scheduler commonly used among desktop and Android, and the original report is just an example of the problem.

tzik@'s workaround idea sounds reasonable to me unless the loading queue doesn't throttle tasks like the timer queue. Probably we should move not only TaskType::DatabaseAccess but also all non-JS-timer task types. Let me defer to altimin@'s decision.

Context for a very specific end user use case, we have a legacy web app for Desktop/Tablet that supports an offline mode via WebSQL DB.

We save Sales Data in WebSQL to sync to server later, then trigger a print dialog for the Sales Receipt. This bug broke our app flow over the weekend when users updated to latest Chrome.

We have since updated our app to work around this, but thought it best to raise an issue on Chromium. Thanks for looking into it :)

Just to note, it repros on Android on M57 with the test file in #8.

After discussion with skyostil@ we agreed that suspending unthrottled task runner is a big risk due to an explicit guarantee in the comments that unthrottled task runner will run when suspended. Switching everything to a loading tq is a bad idea too given that there is a special set of policies around loading tasks.

We will add a new suspendable task queue which won't be throttled and will be suspended.

After discussion with amineer@ and skyostil@ suspendable task queue seems to be too big to go to stable on a very short notice. We'll fix websql problem specifically by moving TaskType::DatabaseAccess to loading task queue. 

Suspendable task queue patch will land in trunk and will be on standby if we encounter any other bugs.

Fix is at https://codereview.chromium.org/2752003002/ and is going through CQ now.

Merge approved for branch 3029 (M58) and 2987 (M57).  Let's get it merged so we can kick builds off once it lands.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/27e68ff784ac0798b46bc596434dd50fbd673887

commit 27e68ff784ac0798b46bc596434dd50fbd673887
Author: altimin <altimin@chromium.org>
Date: Wed Mar 15 18:23:38 2017

[scheduler] Move DatabaseAccess tasks to loading tq.

Posting DatabaseAccess tasks to unthrottled task queue can lead to running websql callbacks when the page is suspended, and it will cause callback to cancel itself.

Post DatabaseAccess tasks to loading queue, which can be suspended and make sure that these tasks run only when page isn't suspended.

R=haraken@chromium.org
CC=skyostil@chromium.org

BUG= 700792 

Review-Url: https://codereview.chromium.org/2752003002
Cr-Commit-Position: refs/heads/master@{#457145}

[modify] https://crrev.com/27e68ff784ac0798b46bc596434dd50fbd673887/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7279e7e6423960fc2266d46b57baf856faa4cc7d

commit 7279e7e6423960fc2266d46b57baf856faa4cc7d
Author: Sami Kyostila <skyostil@chromium.org>
Date: Wed Mar 15 18:30:25 2017

[scheduler] Move DatabaseAccess tasks to loading tq.

Posting DatabaseAccess tasks to unthrottled task queue can lead to running websql callbacks when the page is suspended, and it will cause callback to cancel itself.

Post DatabaseAccess tasks to loading queue, which can be suspended and make sure that these tasks run only when page isn't suspended.

R=haraken@chromium.org
CC=skyostil@chromium.org

BUG= 700792 

Review-Url: https://codereview.chromium.org/2752003002
Cr-Commit-Position: refs/heads/master@{#457145}
(cherry picked from commit 27e68ff784ac0798b46bc596434dd50fbd673887)

Review-Url: https://codereview.chromium.org/2741343012 .
Cr-Commit-Position: refs/branch-heads/3029@{#208}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/7279e7e6423960fc2266d46b57baf856faa4cc7d/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/faad12b9a164462d05626473b8caac31281d4fb6

commit faad12b9a164462d05626473b8caac31281d4fb6
Author: Sami Kyostila <skyostil@chromium.org>
Date: Wed Mar 15 18:46:26 2017

[scheduler] Move DatabaseAccess tasks to loading tq.

Posting DatabaseAccess tasks to unthrottled task queue can lead to running websql callbacks when the page is suspended, and it will cause callback to cancel itself.

Post DatabaseAccess tasks to loading queue, which can be suspended and make sure that these tasks run only when page isn't suspended.

R=haraken@chromium.org
CC=skyostil@chromium.org

BUG= 700792 

Review-Url: https://codereview.chromium.org/2752003002
Cr-Commit-Position: refs/heads/master@{#457145}
(cherry picked from commit 27e68ff784ac0798b46bc596434dd50fbd673887)

Review-Url: https://codereview.chromium.org/2745413005 .
Cr-Commit-Position: refs/branch-heads/2987@{#826}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/faad12b9a164462d05626473b8caac31281d4fb6/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/42481370dbaa70eaf7149b83cfceebad8d15373e

commit 42481370dbaa70eaf7149b83cfceebad8d15373e
Author: Alex Mineer <amineer@chromium.org>
Date: Wed Mar 15 19:35:52 2017

[scheduler] Move DatabaseAccess tasks to loading tq.

Posting DatabaseAccess tasks to unthrottled task queue can lead to running websql callbacks when the page is suspended, and it will cause callback to cancel itself.

Post DatabaseAccess tasks to loading queue, which can be suspended and make sure that these tasks run only when page isn't suspended.

R=haraken@chromium.org
CC=skyostil@chromium.org

BUG= 700792 

(cherry picked from commit 27e68ff784ac0798b46bc596434dd50fbd673887)

Review-Url: https://codereview.chromium.org/2752003002
Cr-Original-Commit-Position: refs/heads/master@{#457145}
Cr-Commit-Position: refs/branch-heads/3042@{#3}
Cr-Branched-From: 8fdbfb2484873d09de132e051da87e580382f95b-refs/heads/master@{#456934}

[modify] https://crrev.com/42481370dbaa70eaf7149b83cfceebad8d15373e/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp

The last merge was me CPing this to last night's canary branch and kicking a new build, so that a new canary is deployed to users and we have crash data to review when we get in tomorrow.

Where are we going to track follow up work for the solution proposed in c#30?

Requesting a postmortem for this issue. Thank you.

(see go/chrome-postmortems for the process to follow)

Rechecked this issue on Windows 10, MAC 10.12.3, Ubuntu 14.04 for chrome version 57.0.2987.110. Fix is working as intended. Adding TE-verified labels.

Note: For CrOS 57.0.2987.100 is the latest build available and the change is not available in this build.

Thanks.!

#38: Filed https://bugs.chromium.org/p/chromium/issues/detail?id=702160 to track the follow-up.

Tested the issue on Windows-7, Mac 10.12.3 and Linux Ubuntu-14.04 using Chrome version 58.0.3029.33.
Observed that the fix is working as expected.Hence adding TE-verified labels.
Please find the attached screen cast for the same.

Thanks.

Deleted: 700792.mp4 291 KB

	700792.mp4 291 KB View Download

Verified on chrome 58.0.3029.33 and 57.0.2987.121 on sony Xperia Z3.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/12e16766adec5bb1e5cdd73d3cd8f5016b59ce18

commit 12e16766adec5bb1e5cdd73d3cd8f5016b59ce18
Author: altimin <altimin@chromium.org>
Date: Mon Mar 27 15:45:38 2017

[scheduler] Add suspendable task queue.

Add suspendable task queue to avoid running (and cancelling) callbacks
when execution context is suspended.

R=skyostil@chromium.org,alexclarke@chromium.org,haraken@chromium.org
CC=nhiroki@chromium.org,tzik@chromium.org
BUG= 700792 

Review-Url: https://codereview.chromium.org/2754673002
Cr-Commit-Position: refs/heads/master@{#459787}

[modify] https://crrev.com/12e16766adec5bb1e5cdd73d3cd8f5016b59ce18/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp
[modify] https://crrev.com/12e16766adec5bb1e5cdd73d3cd8f5016b59ce18/third_party/WebKit/Source/core/loader/EmptyClients.cpp
[modify] https://crrev.com/12e16766adec5bb1e5cdd73d3cd8f5016b59ce18/third_party/WebKit/Source/platform/WebFrameScheduler.h
[modify] https://crrev.com/12e16766adec5bb1e5cdd73d3cd8f5016b59ce18/third_party/WebKit/Source/platform/scheduler/renderer/web_frame_scheduler_impl.cc
[modify] https://crrev.com/12e16766adec5bb1e5cdd73d3cd8f5016b59ce18/third_party/WebKit/Source/platform/scheduler/renderer/web_frame_scheduler_impl.h
[modify] https://crrev.com/12e16766adec5bb1e5cdd73d3cd8f5016b59ce18/third_party/WebKit/Source/platform/scheduler/renderer/web_frame_scheduler_impl_unittest.cc

Thank you for fixing the bug. 
Requesting postmortem for this please see go/chrome-postmortems for the process to follow).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/78c7038fe6f981a9045d7d32d9f531ebb098fd80

commit 78c7038fe6f981a9045d7d32d9f531ebb098fd80
Author: rnephew <rnephew@chromium.org>
Date: Wed Mar 29 20:25:53 2017

Revert of [scheduler] Split suspendable tq from unthrottled tq. (patchset #4 id:60001 of https://codereview.chromium.org/2754673002/ )

Reason for revert:
Causing failures in perf tests. Reverting to confirm it is the culprit.

 crbug.com/706108 
 crbug.com/706104 

Original issue's description:
> [scheduler] Add suspendable task queue.
>
> Add suspendable task queue to avoid running (and cancelling) callbacks
> when execution context is suspended.
>
> R=skyostil@chromium.org,alexclarke@chromium.org,haraken@chromium.org
> CC=nhiroki@chromium.org,tzik@chromium.org
> BUG= 700792 
>
> Review-Url: https://codereview.chromium.org/2754673002
> Cr-Commit-Position: refs/heads/master@{#459787}
> Committed: https://chromium.googlesource.com/chromium/src/+/12e16766adec5bb1e5cdd73d3cd8f5016b59ce18

TBR=alexclarke@chromium.org,haraken@chromium.org,skyostil@chromium.org,altimin@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 700792 

Review-Url: https://codereview.chromium.org/2780233002
Cr-Commit-Position: refs/heads/master@{#460519}

[modify] https://crrev.com/78c7038fe6f981a9045d7d32d9f531ebb098fd80/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp
[modify] https://crrev.com/78c7038fe6f981a9045d7d32d9f531ebb098fd80/third_party/WebKit/Source/core/loader/EmptyClients.cpp
[modify] https://crrev.com/78c7038fe6f981a9045d7d32d9f531ebb098fd80/third_party/WebKit/Source/platform/WebFrameScheduler.h
[modify] https://crrev.com/78c7038fe6f981a9045d7d32d9f531ebb098fd80/third_party/WebKit/Source/platform/scheduler/renderer/web_frame_scheduler_impl.cc
[modify] https://crrev.com/78c7038fe6f981a9045d7d32d9f531ebb098fd80/third_party/WebKit/Source/platform/scheduler/renderer/web_frame_scheduler_impl.h
[modify] https://crrev.com/78c7038fe6f981a9045d7d32d9f531ebb098fd80/third_party/WebKit/Source/platform/scheduler/renderer/web_frame_scheduler_impl_unittest.cc