Locally installed webhelp - problems in Microsoft Edge

[MSCaroline]

I'm working with RoboHelp 2017, generating webhelp that is hosted on a server and also installed with our software. Our software is aware of whether or not an Internet connection exists, and will call the locally installed help in the event that there is no Internet connection (or in the event that the user has turned off the use of web-based help via the application setup).

When the default browser is set to Microsoft Edge (tested in version 41.16299.334.0), local help runs into some problems. One is that the navigation panel is blank. This seems to be addressed by reloading the page, so it's not an absolute deal-breaker, although I'd sure love to fix it. The major issue, however, is that context sensitivity does not function at all-- the help simply opens to our designated default page. Context sensitivity works fine on the hosted help, and works on both hosted and local help in other browsers.

Anyone have any insight on this? Many thanks.

[Peter Grainge]

If the help is opened locally by you after generating it, is the navigation pane blank then?

Have you selected the Mark of the Web check box when generating?

---

See www.grainge.org for free RoboHelp and Authoring information.

@petergrainge

[MSCaroline]

Hi Peter! Yes, Mark of the Web is selected. I've just spent a couple of hours testing this with one of our QA guys, because I'm running Windows 7 and therefore don't have Edge. 🙂 The navigation panel issue is not reliably reproducible, and when it does happen it can be fixed by reloading, so I'm inclined to think it's an incomplete page load issue. Interestingly, when the local help is opened either by CSH call or directly from the C drive, parts of the frameset flicker-- specifically the Contents/Search tabs and the search box that we've placed at the right side of that same bar. So it seems like local help is doing something weird on load in general.

I'm really far more puzzled by (and concerned about) the fact that context sensitivity isn't working in the local help. I mean, it's better than what happens in Chrome (where they get a blank browser window!), but it's certainly less than desirable.

[Jeff_Coatsworth]

What's your point version of RH2017? Are you fully patched up?

[MSCaroline]

Jeff, yep, that's the first thing I checked. 🙂 Version 13.0.2.334.

[Jeff_Coatsworth]

Did you apply Peter's fix from this thread - ToC books not opening in Chrome ? It may have an impact on displaying in Edge too.

[MSCaroline]

I did apply that fix, about a month ago, due to issues in Chrome.

[Peter Grainge]

I have asked someone else for assistance on the context sensitive problem.

On the local issue, I am not seeing that problem with the standard settings. In IE you have to either use Mark of the Web, which you have, or go to Advanced Settings and allow Active X to run.There is no equivalent I can see for Edge. Is the problem only when the help is called from the app (not CSH)?

---

See www.grainge.org for free RoboHelp and Authoring information.

@petergrainge

[Willam van Weelden]

As for the Context Sensitive Help, does that work if a different browser than Edge is being used? And it is only a problem for the local help, not for the hosted version?

[MSCaroline]

Willam, it seems to work just fine in IE, regardless of whether it's local or hosted. And in Edge, the hosted version works as expected. So it's just the local version that's acting up.

Peter, which problem is it that you say you're not seeing? If you're referring to the navigation panel issue, I'm not suprised. It's proving to be quite unpredictable. The flickering is more persistent, but might be more or less noticeable depending on the relative speed/burliness of your machine, I guess!

[Peter Grainge]

Yes, the navigation panel is what I was saying works for me. Try clearing the cache?

Does this only occur if the help is called locally from the app or does it also occur if you open it directly from your hard drive?

---

See www.grainge.org for free RoboHelp and Authoring information.

@petergrainge

[MSCaroline]

It occurs regardless of how the help is called, apparently. But there again, quite unpredictably-- it might happen on one out of every 20 times that I load the page. Interestingly, neither the blank nav panel nor the flickering happen in IE, so I suppose they might be related. We discovered today that the flickering stops as soon as we move the mouse.

Clearing the cache doesn't affect the behavior.

[Willam van Weelden]

Hi,

I ran some tests and there is what I found:

On Edge with local WebHelp, I can get CSH to work without specifying a window, using the URL

file:///<path>/index.htm#<id=3>>newwnd=false

When I also specify a Window, the help opens in Edge like I expect, including the skin:

file:///<path>/index.htm#<id=7>>newwnd=false>>wnd=webhelp

This is the same behaviour as I get in Chrome and FF.

How is your developer calling the help?

[MSCaroline]

My apologies for the extended silence-- I got called away to some pressing projects. ANYWAY...

Our local help call looks like this:

file:///<path>/index_csh.htm#944,withnavpane=true

(or whatever other map #, 944 being just an example here)

Just tested with the latest RoboHelp update, with same results as before.

[SGRoeh]

Hi MSCaroline,

Were you ever able to resolve this issue with the MS Edge browser?

We're having the same issue where the Edge browser will not serve up the correct help page using context sensitivity.

After pressing F1 on a known item in our app we've assigned a map ID to, I never see the map ID # come across in the address bar prior to delivering the correct page as in other browsers. It's as if Edge will not recognize the RoboHelp(?) js that's trying to process the request in the background.

If I reset the default browser to Chrome, FF or IE11, I see the map ID # in the address bar momentarily as the request is being processed and then the correct topic appears. In Edge however, the map ID # is never seen in the address bar - at all.

I'm wondering if, as Peter mentions, there's an ActiveX (or other) setting that isn't allowing the script that handles processing the request to run. I too have thoroughly searched through the Edge settings and could not find anything relevent.

I came across this chat on the windowscentral site related to ActiveX plug-ins as they apparently are deprecated and deemed "legacy technology":

https://forums.windowscentral.com/edge/374112-where-activex-compatibility-settings-edge-browser.html

I'm not sure if this is the issue with Edge not supporting context sensitivity but it's something Adobe needs to look into. Maybe RH2019 resolves this? I'm not sure but I too am still using RH2017.

I hope this helps.

[BilderbergCEO]

We solved the problem using the solution described here:

https://stackoverflow.com/questions/59294780/requestnavigate-to-hyperlink-with-page-anchor

Basically, you need have your app check the registry to see what the default browser is, then tell Windows to open help using that specific browser.