Print functionality is not working in portlet

[mchoudhary]

We are using smartGWT v9.0p_2013-07-29/PowerEdition Deployment (built 2013-07-29).

We are trying to invoke the native print dialog with the print layout. It is working fine on local machine but does not come when deployed on our dev server.

Our application is running as an IFrame portlet and when print is triggerd, getting the following message in the browser.

"The frame requesting access set "document.domain" to "com", but the frame being accessed did not.
Both must set "document.domain" to the same value to allow access"

Code is given as below -

Canvas.printComponents(printObjectList.toArray(new Object[] {}));

Please let us know if we need to make any configuration change.

Thanks

[Isomorphic]

This is web basics and is unrelated to SmartGWT - we would suggest Google searches such as "same origin policy" and "document.domain" in order to understnand what's going on.

[mchoudhary]

As per the "same origin policy" the document domain should be same. And we have our applications in same domain.
One application has the iframe that includes the other. Both are deployed on same server and has same domain.
And even the error in Chrome says so:

Blocked a frame with origin "http://del.spint.com" from accessing a frame with origin "http://del.spint.com". The frame requesting access set "document.domain" to "del.spint.com", but the frame being accessed did not. Both must set "document.domain" to the same value to allow access. printFrame.html?id=isc_PrintCanvas_0&title=Print%20Preview:17

Is there any bug in print functionality in portlet mode?

[Isomorphic]

We are not aware of anything that would cause this problem with the printFrame functionality and have never seen it on our end.

We'll probably need a way to reproduce this issue in order to comment further. Sorry we can't be more help on this.

[mchoudhary]

Print functionality is not working in portlet

Thanks for your response. This issue was resolved at our end.

[Raindy]

Thanks for your response. This issue was resolved at our end.

I'm encountering the same issue, could you tell me how you solve it?

[Raindy]

I'm using smartgwt-4.0.
After dig in-depth, I find that this issue is caused by the file printFrame.html(in the jar of smartgwt.jar and under package of com/smartclient/public/sc/system/helpers)
Here's the code snippet extracts from printFrame.html:

if (!window.isc && document.domain && document.domain.indexOf(".") != -1
&& !(new RegExp("^(\\d{1,3}\\.){3}\\d{1,3}$").test(document.domain)))
{

var set = false;
while (document.domain.indexOf(".") != -1) {
try {
if (window.opener && window.opener.isc) break;
if (window.top.isc) break;

if (!set) { document.domain = document.domain; set = true; }
else { document.domain = document.domain.replace(/.*?\./, ''); }
} catch (e) {
try {
if (!set) { document.domain = document.domain; set = true }
else { document.domain = document.domain.replace(/.*?\./, ''); }
} catch (ee) {
break;
}
}
}
}

This expression "if (window.top.isc) break;" is came to notice, if your application is running as portlet inside an IFrame, "window.top" refer to the portal window, which means "window.top.isc" may be undefined, in that case the "document.domain" going to be changed, finally cause the issue of "violate same original policy".

Anyone know why here need to change the value of "document.domain"? really appreciate if someone can share the idea behind it.