Has anyone ever had an issue with Flare's help output conflicting with the application? The web app I write help for has a tabbed layout. The behavior we are seeing is that once someone clicks the help link, the GUI tabs stop working, and the user must refresh the browser page before the tabs will work again. We've been able to trace the problem to the Default.js file in the top folder of the help output, to the line that includes the jQuery library. This is line 211in Flare 11, and line 67 in Flare 9.
We can partly fix the issue by commenting out this line in Default.js. I'm not sure why the help still works with the jQuery library commented out, possibly because the application also uses jQuery. If we build the help using Flare 9, commenting out line 67 makes the application work perfectly. No issues with the tabs or help. But if we build the help with Flare 11, commenting out line 211 fixes the tab issue, but then adds the issue that you have to click the help link twice before the help opens.
So has anyone else ever seen issues like this where it seems like Flare's jQuery is conflicting with the application? Or does anyone know what may be going on here?
Default.js conflict with GUI
Re: Default.js conflict with GUI
1) How exactly does your application open the help?
2)
Normally, your app would just have a link to your help (to Default.htm).
As the help is opened in a separate page to your app, then you shouldn't be able to have any conflict between the app and the help.
So if the app doesn't work after clicking the link, presumably it's just a problem in the app.
So what I don't understand is how there's a conflict, unless the app and your help are both running together in the same page; e.g. you have app code embedded in your help pages.
If you run app code from the help pages, then you might have a jQuery conflict, because Flare already includes jQuery in its output, and your app code might require a different version.
If that's the case, your app developers will need to use something like RequireJS, so that their code uses a different version of jQuery.
2)
Can you give more detail on how this the problem?Carlsen wrote:We've been able to trace the problem to the Default.js file in the top folder of the help output,
Normally, your app would just have a link to your help (to Default.htm).
As the help is opened in a separate page to your app, then you shouldn't be able to have any conflict between the app and the help.
So if the app doesn't work after clicking the link, presumably it's just a problem in the app.
So what I don't understand is how there's a conflict, unless the app and your help are both running together in the same page; e.g. you have app code embedded in your help pages.
If you run app code from the help pages, then you might have a jQuery conflict, because Flare already includes jQuery in its output, and your app code might require a different version.
If that's the case, your app developers will need to use something like RequireJS, so that their code uses a different version of jQuery.
Re: Default.js conflict with GUI
The help is called via JavaScript as outlined in the Flare help.
I don't know how or why Default.js is a problem. All I know is that the line where the jQuery is inserted causes the problem. That's the line the debuggers traced the issue to, and if that line is commented out, the problem goes away. What I find odd is that with this line commented out, the help still seems to work fine so I don't know where Flare help uses jQuery. It certainly doesn't use it in any of the widgets I tend to use.
Also, no application code is running on the help pages. They are distinct and separate. (Doing something like that seems like it would be a lot more trouble than it would be worth.) There is just something about the call to the help makes the application freeze.
Regardless, it doesn't matter so much at this point. The developers wrote some convoluted workaround to make everything play nice together, so all is well. And I don't think the problem was in Flare. More than likely the developers did something behind the scenes that broke it.
I don't know how or why Default.js is a problem. All I know is that the line where the jQuery is inserted causes the problem. That's the line the debuggers traced the issue to, and if that line is commented out, the problem goes away. What I find odd is that with this line commented out, the help still seems to work fine so I don't know where Flare help uses jQuery. It certainly doesn't use it in any of the widgets I tend to use.
Also, no application code is running on the help pages. They are distinct and separate. (Doing something like that seems like it would be a lot more trouble than it would be worth.) There is just something about the call to the help makes the application freeze.
Regardless, it doesn't matter so much at this point. The developers wrote some convoluted workaround to make everything play nice together, so all is well. And I don't think the problem was in Flare. More than likely the developers did something behind the scenes that broke it.
Re: Default.js conflict with GUI
Ah, I see.
I never use the javascript method for CSH, only the URL method.
If you're using the javascript method for CSH calls, then your app would have to include a link to csh.js in the help ouput.
The csh.js file actually includes jQuery (and RequireJS), so I think it's more likely that the problem is related to csh.js rather than Default.js.
Anyway, I'd suggest using the URL method for CSH, rather than the javascript method; so you shouldn't need any workarounds.
Also, if you've found a bug in the javascript CSH method, then report it to MadCap.
I never use the javascript method for CSH, only the URL method.
If you're using the javascript method for CSH calls, then your app would have to include a link to csh.js in the help ouput.
The csh.js file actually includes jQuery (and RequireJS), so I think it's more likely that the problem is related to csh.js rather than Default.js.
Anyway, I'd suggest using the URL method for CSH, rather than the javascript method; so you shouldn't need any workarounds.
Also, if you've found a bug in the javascript CSH method, then report it to MadCap.
Re: Default.js conflict with GUI
I've recently had a similar issue. Dev. here traced it to jquery. They had to replace the most current version of jquery they use with an older one. I spoke with tech support about it but they more or less said we're on our own. At any rate, it's fixed and it sounds similar to what you're seeing.
Re: Default.js conflict with GUI
If the issue was making CSH calls using the javascript method, then that's an issue for MadCap to fix.bill b wrote:I've recently had a similar issue. Dev. here traced it to jquery. They had to replace the most current version of jquery they use with an older one. I spoke with tech support about it but they more or less said we're on our own. At any rate, it's fixed and it sounds similar to what you're seeing.
If the issue was with using your own jQuery in a Flare project (and you needed to use a different version of jQuery to that used by the HTML5 output), then yes you would have to sort that one out yourself (for which I'd suggest using RequireJS).