This content has been marked as final. Show 7 replies
Welcome to the forum.
Blockers should not block webhelp popups as they are user initiated when they click on a link. My understanding is that blockers are designed to prevent unwanted popups.
I think the other main issue is ensuring webhelp is the appropriate type of help, that is it will be run from a server rather than being installed on the users PC.
Thanks for the information! This helps.
Hello. I created a Web Help project. Some of its topics are linked to the Help button in a web-based GUI (contex-sensitive help). The Web Help is accessed from a server. When accessing the linked topics from the web-based GUI, the topics display normally in the IE, while in Firefox 2.0, the the famous "allow blocked..." message is displayed in that "intermediate" "dummy" window at the bottom of the page.
My question is: Is this a Firefox feature (enhanced security if compared to IE), or am I missing something? In other words, is there any other way to bypass the described Firefox related problem, apart from users answering the famous "allow blocked..." message the first time they start the context-sensitive help or apart from lowering the security settings in Firefox?
Welcome to the forum Primož Kuštrin
The answer that has been marked as correct doesn't answer your question so it follows your question is different in which case a new thread is best.
I just pointed Firefox 2 at a webhelp setup and saw no such message, it never did apply to Firefox, also I don't see any dummy window, not sure what you are referring to.
It sounds like this may be to do with the way the help is called. Try opening some webhelp yourself pointing to the start page. If what you see is correct, that supports the theory that the call is the problem.
Thank you for your welcome and your reply. I created another thread in the WebHelp section, there I further explained and clarified the problem in more detail.
We are experiencing a similar problem, but it is occurring in Both FF2 (Firefox 2) and IE7. In both cases, the context sensitive help feature of RoboHelp that we are utilizing triggers the popup blockers. Is Adobe planning a patch to get around this?
In looking at the script code supporting the context sensitive help, we've also found some obvious logic errors and code paths that are impossible to execute.
This is pretty critical as we are trying to get a release out the door.
I created a new thread with the detailed description of this problem, since the thread here supposedly does not deal with the problem i described. You can find the new thread here:
(RH Forums > WebHelp > Firefox blocks context-sensitive webhelp)
Note that in IE 6.0.2900.2180, the CHS files are not blocked if placed on a web server.