After selecting print the search box in inaccessible unless I click off the web browser

rodegard

I am encountering a strange behavior. When I click the print button and then return the web page and try to enter text in the search box it is not accessible unless I first click off the web browser (not just the web page) and then back on the web page, or close the app down and restart it. This behavior seems to also affect the search box of other pages in the app.

Using this link to one of your samples
1. Open the above link
2. Click the print button
3. close the print preview page and then try to enter text in the search box - the box cannot be clicked on
4. Click off the entire web browser and then back on the web page and you can now enter text in the search box

This issue occurs in both Microsoft Edge and Chrome in windows. your help is appreciated

Regards,

Rob

rodegard

Note that this issues seems to only happen on windows and not on a Mac

colin

I'm not seeing that - I tried Chrome on Windows 10. It would be worth running in Private Browsing mode, in case an extension is affecting the behaviour.

Colin

tangerine

I'm not seeing that - I tried Chrome on Windows 10.

Me neither, fwiw.

robert.odegard01

Will give that a try, but we are seeing it on multiple computers.

robert.odegard01

Just tried it in Private Browsing in Microsoft Edge and I get the same issue. as well I just tried it at another client and the same issue occurs.

colin

Odd. Could you check the console and see if there are any errors being generated, please. Normally if functionality breaks it's because of a script error,which the console would report.

And thanks for also checking, @tangerine

Colin

rodegard

There are no errors on the grid page but when the print dialog page is presented I have a number of warnings indicating deprecated files

A strange behaviour is when the print dialog web page is open the grid page is not accessible at all, seems to be locked out, for example the search box at the top of the page is disabled and if I try to log in in this state I cannot enter any text in any field in the login editor. If I close the print dialog page with the 'x' on the page tab the search dialog cannot be selected but the rest of the page seems to be functioning. If I close the Print Dialog page with the cancel button the grid page works as expected and I can enter values in the search box.

And this issue seems to affect all datable text entry boxes, not just the search box.

I have tested on three different windows 10 machines at two different clients and I am experience the same behaviour on all three machines. I have been testing in Microsoft Edge. - Version 91.0.864.64 and 91.0.864.41 (Official build) (64-bit)

allan

Interesting one! I'm fairly certain that what Chrome is doing it, child document has a blocking UI action on it (the print view) and thus it is also going to block the parent window.

There is a noopener option for new windows and I've just tried that in my development copy, but that doesn't work, because we need Javascript access to the new window to be able to setup the print view! (Chrome just shows #blocked).

Looking at the Chromium bugs it might be this one.

I've added a comment to that thread with the information given here. Thanks!

Allan

rodegard

Hi Allan,

So that would explain the blocking of the original page, but why then when you click the print preview web page tab 'x', to close that page, does it prevent entering any text into any editor text box including the grid search box. But if you close it via the print 'Close' button all is fine?

allan

That sounds very much like a Chrome bug to me. I've just tried it and am also seeing it. Although interestingly, if I focus on a different window and then come back to the one that triggered the print while it is in that state, it then works! It seems like a flag in Chrome isn't being cleared when you close off the child window.

Two ways around this:

1. We shouldn't use a second window for the print view - we did actually take that approach with TableTools, but it caused so many styling problems...!
2. Do server-side generation of the print view, which would allow the noopener option to be used.

Or of course Chrome could fix this .

Allan