New issue
Advanced search Search tips
Starred by 9 users

Issue metadata

Status: Archived
Owner: ----
Closed: Jan 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Keyboard events don't work when printing a page using window print method of javascript

Reported by, Feb 13 2014

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36

Steps to reproduce the problem:
I have produced this problem in a fiddle.
1. Go to: and click the button in result section.
2. A new tab will open for printing the page. Do not close this tab.
3. Now, come back to the fiddle page from where you triggered this and try typing inside any fiddle section again. You will see that it has freezed.
4. Now close the print page tab and come back to fiddle page, it will start working again.

What is the expected behavior?
Browser freezes when 'window.print' method is used to print current page.

What went wrong?
The tab which triggered the print operation freezes and does not let me do anything there

Crashed report ID: 

How much crashed? Just one tab

Is it a problem with a plugin? No 

Did this work before? No 

Chrome version: 32.0.1700.107  Channel: stable
OS Version: 6.2 (Windows 8)
Flash Version: Shockwave Flash 12.0 r0

This is working fine in all other browsers. I think the problem is in google's implementation of the print page. Because in all other browsers, the print option appears as a popup modal box but in chrome it opens as a new tab.

Comment 1 by, Apr 17 2014

Labels: -OS-Windows OS-All
Status: Untriaged
This repros on my Mac; I assume it's broken everywhere.

Comment 2 by, Apr 17 2014

Summary: Keyboard events don't work when printing a page using window print method of javascript (was: Chrome freezes when printing a page using window print method of javascript)

Comment 3 by, Apr 17 2014

Labels: Cr-UI-Browser-PrintPreview
Note that clicking around in the fiddle page works, so it's not like events are completely stopped.

Comment 4 by, Apr 17 2014

thestig@ notes that this brokenness has been around forever.
The OP states that after 'closing' the print tab, the original becomes responsive again. If you 'cancel' the print dialog then that is true; however, if you 'close' the print tab using the 'x' on the tab, the original tab remains broken: buttons will not work, refresh doesn't work, back/forward buttons don't work. The tab is completely hosed. Users will likely think your website doesn't work and are less likely to return or patronize your business. The same thing occurs if one tab calls[uri], "_blank") and the second calls window.print(). 

Comment 6 by, May 20 2014

archiving: That is a different bug,  bug 359627 .

Comment 7 Deleted

I have similar problem in my website as described in initial steps of this issue.
The initiator tab is blocked in weird ways while the print-preview child has a dialog up.
I am using chrome33 and I have also checked that it also produces in version 37.0.2008.2 dev-m.
So any update on this, when this will get fixed?

Comment 9 by Deleted ...@, May 28 2014

Confirming I also have this issue in chrome 35

Comment 10 by Deleted ...@, Jul 8 2014

I have the same issue in Chrome 35.0.1916.153 

Comment 11 Deleted


I have a similar problem.

Two Joomla libraries: one creates a modal popup which shows a google map provided by the other. This has a small print button.

In every other browser a modal print dialogue appears. but the chrome print dialogue can be closed by closing the tab which sends things bonkers ...

see here: - follow Walking in Linn Park, the Some Routes.

the joomla libraries are both well proven

it is the latter module to which a print button has beeen added ... the author located this bug.

Comment 13 by Deleted ...@, Aug 25 2014

Hi all,
Can anyone give us the solution to this problem...
Fixing would resolve this issue.

Comment 15 by, Jan 19 2016

Labels: Stability-Crash-Bulk-Archive
Status: Archived
[Bulk edit] Auto-archiving all Stability-Crash bugs that have not been touched in more than 180 days.  If you feel this action has been taken in error, please re-open the bug, or file a new one and reference this bug in the new report.

Sign in to add a comment