CSH links not working in Microsoft Edge

[cdschroeder]

We recently converted our documentation to HTML5 (goodbye, CHM!), but are having problems with the CSH links. I don't know the exact calls used for the links (our software is written in Delphi, unfortunately), but the devs said they just call the generated CSH file and reference the 4-digit ID I assigned in Flare. The 4-digit number is preceded by a pound sign (#), but Microsoft Edge removes the # and everything after because it violates Windows File Protocol. This results in the help file opening to the home page, rather than the specified topic. The call works for all other browsers (Chrome, Firefox, Opera, and even IE). Anyone have ideas on how to fix this? I called Flare support, but they told me to "use another browser."

[RamonS]

Does it work when you serve it up from a web server? Or is the plan to ever only use HTML5 help serverless as local copy?

[cdschroeder]

We want to have it on a server, and also installed locally for customers without an Internet connection (we have quite a few). I think the devs plan to run a check for an Internet connection upon opening the file, then use the server-based one if possible. If no connection is found (or if any page times out during use), they will redirect to the local copy. But that infrastructure isn't in place yet, so we are just testing locally right now. Do you think there's a problem with installing it locally?

[RamonS]

For those who do not have Internet connection I suggest installing a lightweight server. There are several decent servers available for this. Then again, evaluate what the Win10/Edge user share is. If it is under 10% I would consider this to be a problem that can be reevaluated in a year. I'd think it to be unreasonable to p a lot of effort in to make things work on one utterly dysfunctional browser. Of course, if plenty of users are already on Win 10 you have no choice than to counteract the shortcomings of Microsoft products.

[cdschroeder]

Can you expand on the benefits of using a lightweight server? Is that going to solve the Edge problem, or is there another reason you are suggesting it? I haven't had any previous experience with lightweight servers, so please forgive my ignorance...

We don't have hard statistics on our user base, but I've been told that Edge support is non-negotiable (since it's the Windows 10 default browser). If we can't get it to work in Edge, it's probably back to the CHM file for us. And that's definitely the last place I want to be right now. We've talked about building our own web viewer as a possible last resort, but I'm not sure that will get approved.

[RamonS]

I may have assumed incorrectly, does it work fine using Edge when the help comes from a web server? If that is a 'yes', then the option would be to install a local server that does nothing else than serve up the help. A small server app is preferred as it doesn't have to do all the stuff that IIS or Apache do and often does not come with all the configuration baggage. Mongoose, thttpd come to mind, but there are several others. I've used one that came with a PHP editor in the past. Was rather simple, point it to the file location and start it up, done.

[cdschroeder]

Ah ok, I understand. We are in the process of setting the files up on our server, so I don't know yet if they will work correctly from there. My guess is not, since the issues seems occur when our software hands off the URL to Windows API. For some reason, Edge scrubs the # and anything after it when it comes through API (if you manually enter it or copy/paste, it's fine). But we are going to try it and see. If it does happen to work from the server, then installing a local server could definitely be an option. Thanks for your help!

[cdschroeder]

Still no ETA on the web server... any other ideas I could try in the meantime? I'm a little antsy to get this fixed. (Don't want to go back to CHM! )

Things we've tried so far (all yielded the same result - link opens when directly entered into Edge, but not through Windows API):
- Replaced # with ?
- Revised the call (per Support's suggestion) from "..\Default_Help_CSH.htm#1000" to "..\Default_Help.htm#cshid=1000"
- Enclosed URL in quotes
- Added MOTW

One of the devs also mentioned to me that she is concerned about how the the API call was implemented. She's wondering if CreateProcess is the right way to go, or if there's a better way to open the default browser. I'm not a terribly code-savvy person (basic HTML/CSS is about as far as my knowledge goes), but I thought I'd mention it in case it rings bells for someone more experienced. She's going to try it out later if she gets a chance, but I'm not sure how soon that will be.

Any thoughts?

[kgdyall]

We are running into a similar problem on Windows. We have been using HTML5 help with our own Qt panel that serves up the pages with QWebKit (this because we run on Windows, Mac, and Linux, so use Qt for our GUI). The panel was axed recently due to some other software problems, so now we are going with serving the help in the default browser. Our developer found that there appears to be a bug in the the Windows API for opening a url, where it discards the fragment - which is probably what you're running into. The current strategy is to use the registry to locate the default browser and bypass the API. We couldn't get it to work at all with Edge, so if Edge is the default we are using IE instead. Don't know whether anyone has complained to Microsoft about this - I didn't see any reference to a MS bug report in the developer's comments. I'd certainly be interested to hear of any other strategies or progress on the Windows API issue.

[cdschroeder]

We are running into a similar problem on Windows. We have been using HTML5 help with our own Qt panel that serves up the pages with QWebKit (this because we run on Windows, Mac, and Linux, so use Qt for our GUI). The panel was axed recently due to some other software problems, so now we are going with serving the help in the default browser. Our developer found that there appears to be a bug in the the Windows API for opening a url, where it discards the fragment - which is probably what you're running into. The current strategy is to use the registry to locate the default browser and bypass the API. We couldn't get it to work at all with Edge, so if Edge is the default we are using IE instead. Don't know whether anyone has complained to Microsoft about this - I didn't see any reference to a MS bug report in the developer's comments. I'd certainly be interested to hear of any other strategies or progress on the Windows API issue.

Our developer eventually figured out a workaround! Here's the info he gave me. Hopefully it will help you too!

Description: CSH links don't work in Microsoft Edge.
Notes: This is only an issue for files which meet all of the following criteria: 1) Are local, 2) Are opened through Windows API, 3) Contain the # sign. Files which meet these criteria are viewed as a threat, so Microsoft Edge removes the # and any characters following.
Solution: Host HTML5 help on a web server. Since this is not currently an option, we implemented a workaround instead.
Workaround: (Must be implemented software-side by a developer, as part of the CSH call process) When the customer calls for CSH:

1. Get the file name + path where you want to create the temporary HTML file. For example,

Code: Select all

MyTempFile = 'C:/myTempFile.html'

2. If MyTempFile exists, delete it.
3. Create new MyTempFile.
4. Get content to be written to the HTML file (build string). For example:

Code: Select all

<html>
<meta http-equiv=Refresh content="0; url=file:///C:/myFile Name.htm#' + ContertIntToStr(myID) + ' "><body></body>
</html>

5. Write this string to MyTempFile.html.
6. Close file so it can be opened by other processes.
7. Use any Windows API to open MyTempFile.html. We used ShellExecute:

Code: Select all

ShellExecute(0, 'OPEN', PChar(MyTempFile), '', '', SW_SHOWNORMAL)

8. The link inside MyTempFile opens the correct URL. Because the API call executes before the link is opened, there is no reason for the # sign to be removed, and the link remains intact.

[RamonS]

Thanks for sharing! Quite a bit of work to overcome the deficiencies of Edge.

[Nita Beck]

Thanks for the detailed write-up, Casey. This might be the exact info I need to give a client's developers for whom we're having a similar issue as your original issue.

[cdschroeder]

Thanks for sharing! Quite a bit of work to overcome the deficiencies of Edge.

Thanks for the detailed write-up, Casey. This might be the exact info I need to give a client's developers for whom we're having a similar issue as your original issue.

No problem! I remember responding to another question on this topic a few months back, but I guess I never answered my own post. Hopefully this helps you and anyone else with this issue.

[DWMartin]

I just came across the same issue with "Edge", "#", "file:///" protocol and Delphi (it is actually a Windows issue since developers from every language [i.e. C++, C#] are facing it as well).

After a lot of research I came to a solution that supports all common browsers (IE, Chrome, Firefox, Opera, Vivaldi, ...) and Edge. And it also accepts queries (?) and fragments (#) in the URI:

Code: Select all

// OpenHelp('C:\temp\Default.htm', '123');

procedure TSomeClass.OpenHelp(const AHelpFileName, AHelpID: string; ASearchQuery: string = ''; APickFirst: boolean = False);
var
  URL: string;
  BrowserPath, FileName, Parameters: PWideChar;
begin
  URL := Format('file:///%s', [AHelpFileName]);
  if AHelpID <> '' then
    URL := Format('%s#cshid=%s', [URL, AHelpID])
  else if ASearchQuery <> '' then
    URL := Format('%s#searchQuery=%s&firstPick=%s', [URL, ASearchQuery, BoolToStr(APickFirst)]);

  URL := StringReplace(URL, '\', '/', [rfReplaceAll]);
  URL := StringReplace(URL, ' ', '%20', [rfReplaceAll]);

  BrowserPath := StrAlloc(MAX_PATH);
  Parameters := nil;

  if FindExecutable(PWideChar(AHelpFileName), nil, BrowserPath) > 32 then
  begin
    Parameters := PWideChar(URL);

    if SameText(ExtractFileName(BrowserPath), 'LaunchWinApp.exe') then
      // Default browser is a Windows Store App (and most likely it is Edge)
      FileName := 'shell:AppsFolder\Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge'
    else
      // IE, Chrome, Firefox, Opera, Vivaldi, ...
      FileName := BrowserPath;
  end
  else
    FileName := PWideChar(URL);

  ShellExecute(0, nil, FileName, Parameters, nil, SW_SHOWNORMAL);
end;