New issue
Advanced search Search tips

Issue 914800 link

Starred by 2 users

Issue metadata

Status: Duplicate
Owner:
Closed: Dec 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

window.print stops js execution - matchMedia('print') listener triggered only once

Reported by mar...@kluska.cz, Dec 13

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.2 Safari/605.1.15

Steps to reproduce the problem:
1. Create listener for print: window.matchMedia('print')
2. Console.log print start / print end (via matches)
3. Trigger via console or button window.print

What is the expected behavior?
matchMedia should trigger listeners callback with `matches: true` - we can alter the content for printing.
After dialog is closed callback is triggered with `matches: false`.

Window.print should not stop js execution.

What went wrong?
listeners callback with `matches: true` will not be executed (or any javascript after window.print is triggered, thread is stopped like when using alert/confirm).

Did this work before? Yes 70

Chrome version: 71.0.3578.98 (Oficiální sestavení) (64bitový) Verze	15234034d19b85dcd9a03b164ae89d04145d8368-refs/branch-heads/3578@{#897}  Channel: stable
OS Version: OS X 10.13.6
Flash Version: none

When using print shortcut, js is executed and printed correctly. See attached example (very simple).

Before 71 version it was working. Same issue on windows. At this moment we are unable to print dynamically adjusted content.
 
test.html
611 bytes View Download
73.0.3639.0 (Oficiální sestavení) canary (64bitový)
Verze	e428f176a90386a3ab8dccb657d236eac077209c-refs/branch-heads/3639@{#1} is affected too.
Components: -Blink Blink>Bindings
Labels: Needs-Bisect Needs-Triage-M71
Cc: swarnasree.mukkala@chromium.org
Labels: -Pri-2 -Needs-Bisect RegressedIn-71 ReleaseBlock-Stable Triaged-ET Target-71 Target-72 M-71 FoundIn-71 FoundIn-72 hasbisect-per-revision OS-Linux OS-Windows Pri-1
Owner: yukishiino@chromium.org
Status: Assigned (was: Unconfirmed)
[Reverse Bisect Information]Able to reproduce the issue on reported chrome version #71.0.3578.98 and it seems to be fixed on latest chrome #73.0.3640.0 using Windows 10, Mac OS 10.13.6 and Ubuntu 17.10 by following steps as per comment#0. The following is the reverse bisect information.

Reverse bisect information:
===========================
Last Bad Build: 73.0.3639.0
First Good Build: 73.0.3640.0

You are probably looking for a change made after 616278 (known good), but no later than 616279 (first known bad)
https://chromium.googlesource.com/chromium/src/+/2062a2efafde34bb4e8a9c3cc0547520c06ab1e4
Reviewed-on: https://chromium-review.googlesource.com/c/1375205

@Yuki Shiino: Please help us in reassigning the issue if it is not related to your change.
Adding Release Block Stable as it seems to be a recent regression.
Note:Please feel free to remove if not applicable.
Thanks.!
Labels: -ReleaseBlock-Stable
Mergedinto: 914554
Status: Duplicate (was: Assigned)
Would you give it a try with Canary version 73.0.3640.0 ?

I think that the issue is fixed in the latest Canary.

I can confirm that Canary version 73.0.3640.0 works as expected, also when changing size the "started event" is triggered also (as desired).

Thank you for the fix. ETA a release? :)
I'm sorry, I don't know ETA.  The fix will be merged to M72, and hopefully to M71 at some point but not sure.

Hi guys,

I have noticed a new problem related to this in Chrome Canary 73.0.3644.0 running on Mac OS 10.14. There is a different behavior with window.print() and Cmd+P (I have tested this with provided test.html):

- Using window.print() all works ok (query matches when print dialog opens and then doesn't match when print dialog is closed).
- However, if I use cmd+P the behavior is different. Listener is called twice (query matches and immediately doesn't match, and is not called after the print dialog closes).


Cc: thestig@chromium.org
Lei, do you think that this is a real issue?  I can't tell.

Anyway, it seems a totally different issue from the original report.  I'd recommend to file a new issue for the timing issue.

Sign in to add a comment