Some additional information:
Upgrading/downgrading the kernel version didn't seem to have any effect.

I've also seen this issue appear on Chell and Reef (using R62 images).

> Lowering the fish count to around 250 or lower seems to be enough to allow other tabs to operate normally again.

What I found especially interesting when Casey showed this to me: lowering the number of WebGL fishes *while other tabs are stuck* unlocks them free again; it allows them to finish opening.

There also seems to be some "sour spot" / number of fishes somewhere in the middle that merely slows down the opening of other tabs (several seconds) without completely blocking them.

If you start with smaller fish number, can you repro this? If no, this looks to me like a performance issue. Can you trace the CPU usage and FPS when increasing the fish number?
Aquarium is quite a CPU intensive case, and I have some investigations at  crbug.com/755897 . 

And this is also a regression according to your description. So with a good image, if you increase the fish number, can you also repro this? At  crbug.com/755897 , I have an enhanced version with 10000 fishes at most. 

The CPU usage (using top) and FPS are almost exactly the same for both images. The exceptions being that the 'good' image has increased CPU usage values at 2000 fish (increased from ~100% to ~105%) and 4000 fish (increased from ~105% to ~112%).

Starting with a smaller fish number (using default 50 fish), I could not reproduce this issue.

With the 'good' image, and following the reproduction steps, I observed that the newly-opened tabs were alive and well.

@6: if this is a regression, can you bisect it?

@7: I've isolated the issue between two official ChromeOS images (9739.0.0 and 9740.0.0), but further analysis would require checking the browser versions (61.0.3153.0 through 61.0.3155.0), which our team does not have the cycles to do.

@marcheu: Is this issue same as  bug 757641 ?

@10: I don't think so

+Geoff who had some perf improvements for webGL apps land in that chrome version I believe and may have more insight into next steps to debug.

https://chromium-review.googlesource.com/c/chromium/src/+/559104

I'm not familiar with the ChromeOS enough to debug this.  This page is known for sending lots of GPU commands from the renderer process to the GPU process (proportional to the number of fish) so it's likely starving the other tabs of CPU time.

issue reproduce on eve with:
Chrome version: 63.0.3230.0  Channel: dev
OS Version: 10009.0.0
Flash Version: 27.0.0.159

feedback:
Report ID: 75791689811

sunnyps@, sounds like the GPU is being starved by a webgl context. Is this something that could be addressed by future scheduler work?

> future scheduler work?

Before looking at the future, does anyone understand how and why this recent regression happened precisely in Chrome version: 61.0.3155.0 ?

Unfortunately not a short list https://chromium.googlesource.com/chromium/src/+log/61.0.3153.0..61.0.3155.0?n=10000

Probably https://chromium.googlesource.com/chromium/src/+/63fbdcc12a7ef762e0652c972986fe74835ba00e ? We coudl test a local checkout before/after this change and see

The GPU scheduler is in that list: https://chromium.googlesource.com/chromium/src/+/63fbdcc12a7ef762e0652c972986fe74835ba00e

I landed a fix recently for a similar issue that was affecting mac. Can you try to reproduce on Canary/Dev 63.0.3238.0? The fix is https://chromium.googlesource.com/chromium/src/+/c98596763f36fd5fcc0c984be67b59f3775b35ac

Yeah ToT works.

Looking at the very short commit, looks like --disable-gpu-scheduler would be enough to root-cause the regression on affected images, correct?

The correct flag is --disable-features=GpuScheduler

Reproduced on ChromeOS with 63.0.3236.0, tested again and confirmed gone with dev channel update 63.0.3239.7

https://chromium.googlesource.com/chromium/src/+log/63.0.3237.0..63.0.3238.0?n=10000

As mentioned in (duplicate?)  issue 770146 , Ctrl-Shift-I is/was an equivalent and more convenient way to reproduce than Ctrl-Alt-T

As far as I understand the latest discussions and status in  issue 770146 , this won't be fixed in R61 and likely not in R62.

> The correct flag is --disable-features=GpuScheduler

Is there a chrome://flags to test without the cost of switching to developer mode?

There is no chrome://flags switch for this.

Verified on 4 Soraka EVT2 boards. Issue is not observed on 3 boards. Able to open webgl aquarium with 5k and 10k fishes on 10 windows. 

But in 1 board able to open 7 or 8 windows, after which page responsiveness error is observed.

OS: Google Chrome 65.0.3287.0 (Platform 10201.0.0-17.12.10)
Able to open WebGL aquarium with 5000 fishes on 10 multiple windows but fps is ~1. Sporadically "page unresponsiveness" issue observed but it is going away automatically after a few seconds and WebGL continues to run fine. FPS drops to 1 or 2 at the time of observing the error

This does happen after all. See internal bug b/67387932.

> This does happen after all.

Comment #20 closed this as "Fixed on ToT; wontfix on older branches". Are you saying that https://bugs.chromium.org/p/chromium/issues/detail?id=770146#c19 wasn't enough to fix the ToT?

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

commit af5912a742121571beccf0af931fe1023fcf46ba
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Mon Jan 22 23:49:52 2018

gpu: Set high priority for media context.

WebGL context can starve media context because the client waits for
frames to be decoded before submitting a mailbox to the browser. The
scheduler doesn't see a dependency between browser and media contexts so
it doesn't elevate media context priority like it does for WebGL.

Disable the check for trusted channel when creating a high priority
stream because with this change untrusted channels (renderers) can
create high priority streams (media).

R=piman
BUG= 760834 

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I5b001e76ee922b68314190ea4c7b3cc48d013652
Reviewed-on: https://chromium-review.googlesource.com/877414
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531065}
[modify] https://crrev.com/af5912a742121571beccf0af931fe1023fcf46ba/content/common/gpu_stream_constants.h
[modify] https://crrev.com/af5912a742121571beccf0af931fe1023fcf46ba/content/renderer/render_thread_impl.cc
[modify] https://crrev.com/af5912a742121571beccf0af931fe1023fcf46ba/gpu/ipc/service/gpu_channel.cc
[modify] https://crrev.com/af5912a742121571beccf0af931fe1023fcf46ba/gpu/ipc/service/gpu_channel_unittest.cc

#29 a variation of this bug occurs with hw decoded video playing in one tab (or media player app) and webgl on another. May not happen to the same extent on all boards.

Can we get this fix merged back into M65?

Ok, requesting merge to M65.

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit db9824fab1f5a6fcad6ce60d10ec02978cc49ff4
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Fri Jan 26 01:35:44 2018

[merge to m65] gpu: Set high priority for media context.

WebGL context can starve media context because the client waits for
frames to be decoded before submitting a mailbox to the browser. The
scheduler doesn't see a dependency between browser and media contexts so
it doesn't elevate media context priority like it does for WebGL.

Disable the check for trusted channel when creating a high priority
stream because with this change untrusted channels (renderers) can
create high priority streams (media).

R=​piman
BUG= 760834 

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I5b001e76ee922b68314190ea4c7b3cc48d013652
Reviewed-on: https://chromium-review.googlesource.com/877414
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#531065}(cherry picked from commit af5912a742121571beccf0af931fe1023fcf46ba)
Reviewed-on: https://chromium-review.googlesource.com/888018
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#105}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/db9824fab1f5a6fcad6ce60d10ec02978cc49ff4/content/common/gpu_stream_constants.h
[modify] https://crrev.com/db9824fab1f5a6fcad6ce60d10ec02978cc49ff4/content/renderer/render_thread_impl.cc
[modify] https://crrev.com/db9824fab1f5a6fcad6ce60d10ec02978cc49ff4/gpu/ipc/service/gpu_channel.cc
[modify] https://crrev.com/db9824fab1f5a6fcad6ce60d10ec02978cc49ff4/gpu/ipc/service/gpu_channel_unittest.cc

verified on M-65 build 10323.30.0, 65.0.3325.65 on squawks