Printing doesn't work when page is in a frameset.

[ssouthwell]

Don't laugh; we have a website we're implementing SmartClient 9.0 in that uses a frameset. The frameset is served on the same domain as our SmartClient code.

What we've discovered is that when we use the showPrintPreview() method on a grid that is inside a frameset, we get these messages in the JavaScript console:

Error: Permission denied to access property 'isc'
ReferenceError: params is not defined

If we instead open our app into its own window we don't have this problem at all. (Actually it shows the print preview with another problem I'll describe separately).

I see that printFrame.html seems to have some code in it that attempts to mess with document.domain, and I just don't understand what is going on here. Our isomorphicDir is set the same as our URL for the app itself:

"/scr/isomorphic/"

Any pointers here on how to get this working without getting rid of the frameset?

[Isomorphic]

printFrame.html has to contact the frame that loads it in order to get the printed HTML content it should display.

The code you see in printFrame.html is trying to automatically match the document.domain value of the parent page so that you don't have to edit printFrame.html to set a matching document.domain value.

The error you're seeing suggests that, for some reason, printFrame.html can't seem to contact the loading SmartClient frame.

As you allude to, framesets really are a bit archaic, but we don't know of any reason why printFrame.html would misfire in that context. If you can put together a simple test case showing this happen, it might be clear what needs to be adjusted.

[ssouthwell]

...
The code you see in printFrame.html is trying to automatically match the document.domain value of the parent page so that you don't have to edit printFrame.html to set a matching document.domain value...

That is what confuses me, and is what I think may be breaking it. Our pages are served out, lets say by host-name.company.com. If I use Firebug to look at document.domain in printFrame, the value after this error was sitting at company.com.

I'll see if I can create a test case, but it may be affected by how it is served out.

[ssouthwell]

Test case

The attached test case illustrates the problem. You may have to adjust paths a bit to make it work, but put both .html files in the same directory.

Load up printtest.html in your browser and click "Print Grid". You should see that it loads up a print preview.

However, if you load up printframe.html, it puts printtest.html into a frame. From there, the "Print Grid" function throws JavaScript errors.

If this doesn't reproduce for you, please let me know and I will try to get you a link to this on our webserver so you can see it in action.

[Isomorphic]

We'll queue this up to be looked at. To set expectations, since it involves framesets and you don't have support, it's going to be behind a lot of other tasks.

It would help if you can confirm you've tried this by dropping it in the standard SDK (and not some other environment which might be doing extra stuff..) and reproduced the problem there, and with which browsers.

One red flag is an attempt to load "application.css", which you didn't include.

[ssouthwell]

We appreciate whatever help you can provide. I will check with our client about purchasing support.

You can ignore application.css and delete that line from the test. I've confirmed the problem still exists without it.

I'll load this test into the standard SDK and give that a try.

[ssouthwell]

To reproduce in the SDK

Using the SmartClient_v90p_2013-10-23 SDK:

- Place the attached files in the smartclientSDK directory
- Edit your /etc/hosts file so that you can hit your machine using localhost.localdomain:

127.0.0.1	localhost.localdomain

- Start the embedded server
- Access the URL: http://localhost.localdomain:8080/printframe.html
- Click "Print Grid", and watch the error console.

Note that the problem doesn't exist when you just use the localhost hostname: http://localhost:8080/printframe.html

There is something there in the way it's dealing with the domain name that is messing things up.

[ssouthwell]

Found the problem; here's the fix

in isomorphic/system/helpers/printFrame.html:

Replace this line:

if (window.top.isc) break;

With this one:

if (window.parent.isc || window.parent.document.domain == document.domain) break;) break;

I am not sure why window.top was being used, but what was happening is that the code at the top of printFrame.html was trying to set the document.domain without even checking whether it might already be the same as window.top. Since it really seems to use window.parent further below, I replaced window.top with window.parent, and added a check to ensure the domain actually differs before attempting to start stripping off subdomains.

This solved my problem, although I'm not entirely sure I understand what the domain-setting code here is trying to solve, so you may want to test that.

[Isomorphic]

Thanks for the possible fix. Can you show your complete printFrame.html, it looks like maybe it's from an older version than 9.0?

FYI on what that code does: if you are loading from foo.bar.com and have set bar.com as document.domain, if printFrame.html is loaded from foo.bar.com it must set document.domain to bar.com to be allowed to access the parent page that loaded it.

The code in printFrame.html does this automatically.

[ssouthwell]

Thanks for the possible fix. Can you show your complete printFrame.html, it looks like maybe it's from an older version than 9.0?

Fix file is attached.

Agreed, it looks old. I was tempted to convert it to HTML 5, but didn't want to go any further than needed, since I figure you guys will update it at some point. This file was fresh out of today's build.

In my debugging, I learned that it was simply trying to strip off the left-most part of the domain - sort of regardless of whether it needed to. That was causing problems because the calling screen still had the full domain.