Skip to main content
Participant
October 4, 2013
Answered

Viewing Generated Robohelp 10 .htm files locally results in refresh loop

  • October 4, 2013
  • 2 replies
  • 5525 views

But the files are viewable on a server (we've tried two servers). Any ideas?

This topic has been closed for replies.
Correct answer Jeff_Coatsworth

@Colum - I'm seeing the same behaviour using Chrome version 30.0.1599.69 on a locally generated WebHelp test done using the sample Salesbuilder project. I've checked the settings to see if JavaScript is enabled & it is. This used to work just a little while ago, but some update in Chrome has busted this again it seems. I've filed a bug report with Adobe this morning about it.

Update - it also fails when located on a LAN server too. I'll test next with the "local file access" flag to see if it's a "security" issue ;>)

Message was edited by: Jeff_Coatsworth Added Update


OK - further update - adding the "--allow-file-access-from-files" flag to the Chrome shortcut does solve the issue. So it's definitely some change that Chrome has made that's short-circuiting the fix that Adobe made to RH to get around this before.

2 replies

Adobe Employee
October 21, 2013

Hi All,

Adobe has released solution for chrome issue. Please look http://helpx.adobe.com/robohelp/kb/webhelp-output-fails-load-chrome.html

keitaaoki
Participating Frequently
November 19, 2013

How about on the Mac OS X?

There seems to be still a problem when replaced with new "whproxy.js".

The left pane is not displayed in Chrome (version 31) on Mac OS X.

Jeff_Coatsworth
Community Expert
Community Expert
November 19, 2013

Chrome on a Mac – hmm. Never dealt with that, ever – if the RH fix is still busted in that scenario, you’d better file a bug report with Adobe.

RoboColum_n_
Legend
October 4, 2013

You'll have to give us some more detail to have a chance of helping you. What do you mean by "refresh loop"?

jsopranosAuthor
Participant
October 4, 2013

The page does not load. It's blank and the window just keeps flickering.

Jeff_Coatsworth
Community Expert
Community Expert
October 8, 2013

Aargh, I just looked with the same version (30.0.1599.69) and I have the same issue. Be sure to report this as a bug to Adobe (https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform) It seems Chrome has made the cross frame communication even stricter with this patch.

I have found a dirty fix that may help. It seems to work fine, I gave WebHelp a spin, but I haven't thoroughly tested it. I hope Adobe can come up with a nice fix.

Please note: this fix is extremely dirty and should only be used as a workaround. I cannot guarantee that your WebHelp will work correctly!

Saying that, here's a fix:

1. Open whproxy.js with a text editor.

2. Find the function getStubPage.

3. Replace the function with the following function:

function getStubPage() {

    if (!gbInited) {

        if (msgHandlerProxy.checkChromeLocal()) {

                              try {

                                        var oWnd = top.frames['ContentFrame'];

                              } catch(e) {

                                        var oWnd = top;

                              }

            if (typeof (oWnd) != 'undefined' && oWnd != null)

                gWndStubPage = oWnd;

            else

                gWndStubPage = top;

            if (gWndStubPage == this)

                gWndStubPage = null;

        }

        else

            gWndStubPage = getStubPage_inter(window);

        gbInited = true;

    }

    return gWndStubPage;

}

Greet,

Willam


@Willam - already filed ;>)

I'll give your dirty fix a run through tomorrow & let you know.