Character-based icons not rendering in WebHelp Responsive

[jonathanpiasecki]

We have a customer creating oXygen WebHelp Responsive output from DITA XML source. Generally, the system works very well.

The customer has deployed the help system to a server in a secure environment without access to the web.

Some of the characters used for help UI navigation refuse to render in the oXygen WebHelp font. In particular, the "double up" and "double down" chevrons used for "expand sections" and "collapse sections", immediately beside the "print" icon in the help topic, refuse to render. They render as plain "k" and "l" (lower case L) characters. It is as if the oXygen WebHelp font is not loading.

The client sees these warnings in the browser console:

Refused to load the stylesheet 'https://fonts.googleapis.com/css?family ... 00,700,300' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'style-src-elem' was not explicitly set, so 'default-src' is used as a fallback.

topicFilename.html:1 Refused to load the font 'data:font/opentype;base64,{snipped the base 64 code for legibility}' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.

topicFilename.html:1 Refused to load the font 'data:font/opentype;base64,{snipped the base 64 code for legibility}' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.

topicFilename.html:1 Refused to load the stylesheet 'https://fonts.googleapis.com/css?family ... 00,700,300' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'style-src-elem' was not explicitly set, so 'default-src' is used as a fallback.

They are using Google Chrome Version 72.0.3626.109 64-bit.

While these appear to be Content Security Policy (CSP) warnings, if a CSP somewhere is saying "Hey, you're not allowed to self-load fonts", then ALL of the character-based icons in the help system would render as their plain Latin characters. But that's not what is happening -- this only affects the "double up" and "double down" chevrons.

I do not have access to the client's test environment. I cannot replicate this problem on any of my test environments.

If it is a CSP that is causing this, I do not think that I can get the client to change their CSP to allow the help system to self-load resources like this. I am thinking that my only alternative is to replace all of the character-based buttons with graphics. I'd rather not do that.

Any suggestions on the cause and how to correct this?

Thanks -- Jonathan Piasecki
Precision Content Authoring Solutions, Inc

[ionela]

Hi,

Could you please specify what oXgen XML version does the end-user run?
To further debug this issue, I think you should try the following:
- use a clean installation of oXygen XML with the default DITA-OT;
- run default DITA Map WebHelp Responsive scenario on our sample flowsers.ditamap;
- upload the output to the client environment.

Does the problem replicate also using our sample flowers.ditamap and the default configuration? If not, some parts of the customization may lead to this issue.

Regards,
Ionela

[jonathanpiasecki]

Hello --

Thanks for the notes. I've compiled the sample help system and have asked the client to test it in their environment.

Using WinMerge, I compared the files in the oxygen-webhelp directories from both the default help and the client's help. Other than the .js files derived from the content, the files were identical. So I don't think we are missing anything.

The WebHelp version info from build_dita.xml is --

<property name="webhelp.version" value="20.0-SNAPSHOT"/>
<property name="webhelp.build.number" value="2018020913"/>

Will let you know what the client finds.

Thanks -- Jonathan Piasecki