New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 784084 link

Starred by 1 user
Status: WontFix
Owner:
skyos...@chromium.org
Closed: Nov 2017
Cc:
delph...@chromium.org
█ vamshi.k...@techmahindra.com
altimin@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug



Sign in to add a comment

Calling window.print() is pausing all .gif images, even after you select "cancel".

Reported by gamingpr...@gmail.com, Nov 11 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36

Steps to reproduce the problem:
1. Put a .gif image on a website, or set it as CSS background-image property
2. Call window.print()
3. Click cancel

What is the expected behavior?
The expected behaviour would be the .gif to keep going with its animation, instead of freezing.

What went wrong?
After window.print() was called, all .gif images and elements with a .gif set for a CSS background-image on the page stopped playing the .gif animation.

Did this work before? N/A 

Chrome version: 62.0.3202.89  Channel: stable
OS Version: 10.0
Flash Version: 

A live example of this can be found on https://mcnitro.net/terms
The logo in the navigation has a .gif for a background.
You can call the window.print() by clicking on the blue "print" button.

Comment 1 by vamshi.k...@techmahindra.com, Nov 13 2017

Cc: vamshi.k...@techmahindra.com
Labels: -Pri-2 hasbisect-per-revision Triaged-ET M-64 Needs-Triage-M62 OS-Linux OS-Mac Pri-1
Owner: delph...@chromium.org
Status: Assigned (was: Unconfirmed)
"Able to reproduce the issue on the reported chrome version stable 62.0.3202.89 and on the latest dev 64.0.3267.0 Using Windows 10, Ubuntu 14.04 and Mac 10.12.6.

Manual Bisect info:
---------------------------
Good Build: 60.0.3102.0
Bad Build: 60.0.3103.0

You are probably looking for a change made after 472426 (known good), but no later than 472427 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/659885eebc27bf7a49b806d2f8b104b547b36605..f5065232010251bad1cccddcc2a0d27ac2232f67

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

Suspecting same from changelog.

delphick@: Please confirm the bug and help in re-assigning if it is not related to your change.

Thanks!"

Comment 2 by delph...@chromium.org, Nov 14 2017

Cc: delph...@chromium.org
Owner: skyos...@chromium.org
That CL moved GIF animation onto the compositor task queue (initially it also increased the compositor TQ priority but that was rolled back). Perhaps the compositor TQ was paused

A simpler repro page is: https://resources.enjin.com/1465083537/themes/core/images/tag_fx/sparkle_green.gif

I can repro with 64.0.3260.2-1, but can't repro with a build from HEAD. I'm testing by opening the console and typing "window.print()" and I found that when it triggers I can get the animation to start again by resizing that console pane. I've attached a trace that shows this process.

Sami, could we be pausing the compositor queue for window.print() and then not restarting it?
trace_animated_gif_print_trace.json.gz
4.6 MB Download

Comment 3 by dtapu...@chromium.org, Nov 14 2017

Components: -Blink Blink>Scheduling

Comment 4 by gamingpr...@gmail.com, Nov 17 2017 

Additional note: Using `CTRL + P` is not firing the bug, but calling window.print() via JavaScript is.

Comment 5 by skyos...@chromium.org, Nov 22 2017

Status: WontFix (was: Assigned)
Looks like this is a regression in M62. M63, M64 and ToT are fine. Given that M63 will be stable soon I don't think this is worth backporting.
►

Sign in to add a comment