RoboHelp 2017 - Some links in Responsive HTML5 output are broken on iPhone

[Faeneth]

Hello,

we are currently using Adobe RoboHelp 2017 to create the help system for our new product. We really liked the Indigo layout, so we customized it (heavily) and applied it. That is working great so far.

However, I noticed today that some of the links in the topics themselves are not working on iPhone (iPhone SE and iPhone 6). When I tap them, the same page is just reloaded and sometimes after the tap, the content is no longer scrollable.

I thoroughly tested the links on other devices (Android Galaxy S4 mini, iPad, Android Galaxy Tab S2, iMac, various Windows 10 browsers) and the links work everywhere else.

You can check this behavior yourself on iPhone: For example, in CELUM Marketing Project Management Help the links (light blue, bold text) in the section "First steps" don't work at all and only reopen the same page ("Get started") again, while the links in the bullet list on the same page work fine.

On other pages it is also wildly different between links and pages and I can't really see a pattern why some links are failing while others are not.

I would really appreciate your help with this problem, thanks very much.

Technical details:

RoboHelp 2017 Version 13.0.1.279 - I haven't installed Update 2 yet after I found out that the search is broken in that one.

We are also using the link_to_dropdown.js script provided by William Van Weelden, but the links on the "Get started" page don't lead to a dropdown, just to normal RoboHelp topics.

[Peter Grainge]

Your link is just going to the RoboHelp forum, not your help.

However, whilst there are some problems with Update 2, there were problems before. Willam has provided a fix for the Update 2 issues at Tracker​

Personally I would apply Update 2 and then Willam's fix but that's your call.

---

See www.grainge.org for RoboHelp and Authoring information

@petergrainge

[Peter Grainge]

Thanks to Rick for pointing out that the link in the thread works but if you click the "same" link in the email notification of the post, then it errors.

That said, the answer remains the same as I cannot test on an iOS device.

---

See www.grainge.org for RoboHelp and Authoring information

@petergrainge

[Faeneth]

Thank you for the quick reply.

I will try installing Update 2 and the fix as you suggested. I'll keep you posted how it went.

[Faeneth]

Hello,

I was unfortunately pretty busy with other stuff in the last couple of months, but now I finally got around to making the update to Robohelp Update 2.

Unfortunately, the Update (with Mr. Van Weelden's fix applied) did not fix the issue.

At least I identified the behavior which causes some links to break and some to work: On iOS-devices, the scroll position of a link's source page is jumped to on the link's target page. This leads to the behavior that links that lead from, e.g., the bottom of a long topic to a shorter topic, are not followed properly. Instead, the source topic (the same topic where the link was tapped) is displayed again, with the top scrolling position. If the link on the source page can be reached without scrolling too much, then the target page is opened fine.

I opened a bug for this issue in January, after I found another Forum entry for it: Tracker

My RoboHelp version after the update is now 13.0.2.334, the problem occurs in our customized Indigo-layout and I also tried it with all uncustomized Responsive HTML5 layouts (Indigo, Azure Blue, Charcoal Grey). All layouts have this bug.

Do you have any idea how this could be fixed or what else I can try? I suspect it has something to do with how iOS handles iframes or links in general, but I don't know how to fix this.

Thank you very much,

Birgit Matuolis

[Peter Grainge]

Adobe have since created a fix that will be in their next update but for now is on my site in Item 13 in Using RoboHelp 2017 I doubt though that this will address this issue but you could try it making sure you reverse Willam's fix.

I'm not an iOS user so I cannot look at your links and see the problem and I am not sure I am following what you say. Is it that if you tap a link in Topic 1, what happens depends on where you were in that topic. If the link was way down the topic you then you stay on that page but if the link is near the top, then it works.

That makes no sense at all to me as a link is a link and it should not matter where it is in the page. I also think if this was an iOS issue, we would be seeing others reporting it.

First step for me would be to create a new project with two or three topics that should replicate this and do not apply any customisation. Does the problem still occur then?

---

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

@petergrainge

[Faeneth]

"Is it that if you tap a link in Topic 1, what happens depends on where you were in that topic. If the link was way down the topic you then you stay on that page but if the link is near the top, then it works."

Yes, that is exactly what the behavior is. If Topic 1 contains a link to Topic 2 somewhere in the middle/end of Topic 1, and Topic 1 is a lot longer than Topic 2, then the link to Topic 2 is not followed. If Topic 2 is longer than Topic 1, the link is followed.

Okay, I will apply your fix to the IE11 thing (I also don't expect this to fix my issue, but one never knows), then I'll try a new project with the two or three topics to see if this is reproduceable in a fresh project.

If it is reproduceable, it may really be an iOS bug. Btw, somebody did bring this issue up in the Forum and created a bug for it before, but the bug wasn't migrated to the new bug base: Re: Bookmark links do not work in responsive in mobile browsers

This forum entry is also mentioned in the bug I created.

[Faeneth]

Hello,

I tried setting up a new project with three topics, one long, one short, one mid-length and anchors and hyperlinks on different positions in these topics (start, middle, end).

The good news is that all links are at least followed in iOS-devices in a completely fresh project.

The bad news is, that the link behavior is still somewhat erratic. Sometimes, after a link is followed and the target topic is opened, the page is cut off and no scrolling is possible anymore on the target page. I suspect that this problem happens under the same circumstances as my original problem (Links from longer topics to shorter topics seem to produce this behavior).

I will investigate in our help project (where the problem originally occurred) what could be causing the problem that certain links aren't followed at all. It doesn't seem to be a pure Layout-Problem, maybe we have something in our content which causes this.

Thank you for your help so far.

As a side note:

I applied the files from Item 13 on your site (the files in "ie_load_problem_fix.zip"). Unfortunately, it broke the linking between the topics and the TOC, therefore I reverted back to William Van Weelden's ZIP file (which is attached in the bug RH-960 Tracker ). With that one, the TOC is properly refreshed when a new topic opens. I attached two videos which show the behavior in Google Chrome on Windows 10 with your files applied and with Mr. Van Weelden's files attached, in case you are interested:

Output Indigo with your files applied:

Output Indigo with WVWÄ's files applied:

I also reproduced it on iOS-devices and IE11.

[Peter Grainge]

There is only one file on my site but Willam's fix was in two files. Did you revert the file that Adobe did not change back to the original? If not you have a mismatch.

---

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

@petergrainge

[Faeneth]

I applied all the files which were in the zip-file on your site (not counting readme.txt). That included the loadparentdata.js, which I also applied according to what was written in readme.txt.

However, the zip-file from your site contained more than one other file. It contained the following:

- common.min.js

- layout.min.js

- loadparentdata.js (the reverted version)

- loadprojectdata.js

- mhtopic.js

- readme.txt (I did not apply this one).

Should I have skipped other files from your zip?

[Peter Grainge]

Willam's fix was based on changing only these two files.

- loadparentdata.js

- loadprojectdata.js

Adobe's fix is based on changing

- common.min.js

- layout.min.js

- loadprojectdata.js

- mhtopic.js

I added Adobe's original loadparentdata.js to to the zip file to reverse the revised files created by Willam van Weelden for anyone who hadn't created a backup.

It sounds like you now have both of of Willam's files plus Adobe's other files (common.min.js / layout.min.js and mhtopic.js). I can't say how well that will work, It might be OK, I simply don't know. I did put in the text file It maybe that the other files in this zip file will work with his revised loadparentdata.js but that is untested.

It wasn't intended that the Adobe fix would be applied and then reversed. Hopefully you retained the old versions of the additional files. If not, I can only suggest you install the trial version of RoboHelp on another machine, apply Update 2 and then copy the required files from there.

---

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

@petergrainge

[Peter Grainge]

Just to add, the Adobe fix has not caused anyone else a problem so I am wondering if the issue you encountered is just related to your project.

Have you tried deleting the CPD file and reopening RoboHelp. That often fixes issues that cannot otherwise be explained. RoboHelp creates a fresh one on reopening using information in other files. That said, your new project is having issues too so I wouldn't hold my breath that this will fix it.

When you say The bad news is that the link behavior is still somewhat erratic you do mean in the new project don't you? I just want to be sure the new project is not 100% OK as if it is, then it would suggest different ideas.

---

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

@petergrainge

[Faeneth]

Regarding the problem with loadparentdata.js:

I retained the original files (thankfully).

However, I did apply the loadparentdata.js which is located in your zip-file. That means that I did copy this file into the Adobe <Robohelp installation directory>/RoboHTML/ResponsiveHelpExt/widgets/common/scripts and William Van Weelden's file was successfully overwritten with the version from your zip-file. The version from your zip-file has the same content as the original file which I made a backup of - I compared them. I also copied the other files from your zip file to the scripts directory.

I also just now deleted the .cpd file in the new test project and then recompiled the project. However, the same issue from the video is still there.

Maybe it has something to do with my computer? It is a Windows 10 machine with the latest Windows Update applied. Anyway, I will probably for now keep William Van Weelden's fix, because that works for the RoboHelp projects on my machine.

Regarding the linking problem:

"When you say The bad news is that the link behavior is still somewhat erratic you do mean in the new project don't you? I just want to be sure the new project is not 100% OK as if it is, then it would suggest different ideas."

Yes, I mean the erratic behavior happens for my new test project (the same one that stars in the videos I linked). It has only the uncustomized Indigo layout and the default.css applied, but without any changes to the styles.

[Peter Grainge]

OK but as indicated Willam's fix was intended to work with the original files I have specified.

---

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

@petergrainge

[Faeneth]

Could you please clarify what you mean by that?

To make it work again and apply WVW's fix, I first replaced the files from your zip with the original files again (I have backups of all the files that are in your zip, I made them before I originally applied your fix) and then I copied William's files in again, which means that only his loadprojectdata.js and his loadparentdata.js are applied in the end.

Then I recompiled the project again and the TOC-Topic sync worked again.

Frankly, I don't know how else I should revert your fix and reinstate WVW's fix.

[Faeneth]

Anyway, this discussion is not my primary concern - the more important topic for me is the link issue.

As I said, I will investigate what might be wrong with my customized project in comparison with the uncustomized test project, that would lead to the links breaking.

[Peter Grainge]

I realise it's not your primary concern but what I am getting at is not throwing anything else at the issue.

Put another way, when you went with Adobe's fix you applied all the files in the zip on my site. If you are reverting to Willam's two files, then you need to revert all the other files you changed.

So when reapplying Willam's files, you also needed to revert to the originals of these files.

- common.min.js

- layout.min.js

- mhtopic.js

Sounds like you have done that. Apologies if I confused things but didn't want a mix of Willam's files and the updated files causing other issues.

---

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

@petergrainge

[Faeneth]

So when reapplying Willam's files, you also needed to revert to the originals of these files.

- common.min.js

- layout.min.js

- mhtopic.js

That is exactly what I did, as I wrote above. No need to apologize, I realize that you want to make sure that I did everything the right way.

As for the linking issue - I will investigate this in our help project and let you know if I manage to resolve the issue. Could take me a while, though.

Thank you for your help.

[Peter Grainge]

Have you also checked iOS forums to see if this issue is posted there?

---

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

@petergrainge

[Faeneth · Accepted solution]

I was able to solve this issue now by taking a closer look at both the CSS for our customized RoboHelp template and the CSS for the topics (default.css with custom styles in it).

Turns out that something was wrong with my default.css which prevented the linking and scrolling to work correctly.

In case somebody has runs into the same problem, I recommend removing all styles from default.css, then testing the output, and then gradually adding the custom styles back in (with multiple output checks) to find out which CSS is at fault. Then work around or remove the faulty CSS statements.

[ahmed2302]

Hi Faeneth,

I am also facing the same issue, could you please guide me which CSS statement I need to check. Is it related to the Hyperlinks??

Thanks

[Faeneth]

Hi Ahmed,

unfortunately I don't have the SVN history for the file from April 2018 anymore, so I can't tell you exactly what it was.

If I remember correctly, it had something to do with the styles for html and body elements, but I can't remember which statement.

My suggestion is to back up your default.css file, remove all your custom styles from the default.css (or revert it to the out-of-the-box version of the file), compile the help and see if the scrolling problem still occurs. If the scrolling problem is gone, you know that some of your custom CSS breaks it.

Then you can gradually add your custom styles again and recompile the help after every change to see if the problem reoccurs. As soon as it reoccurs, you can take a closer look at the last styles you added (remove and gradually re-add just those styles) and thus find the culprit.

Sorry I can't offer anything more specific.

Cheers!