www.xxx.com has 'refused to connect'. Yet if I change the target window to a 'New Window', the link works correctly, but of course it's now appeared in a separate browser window - which is not what I want.
Can you advise me?
Regards,
Andy Pybus
When I link to valid webpage and specify the target window as the 'same as the referring topic', I consistently get a message saying that Domain 'refused to connect'
Moderators: Alexander Halser, Tim Green
-
- Posts: 8
- Joined: Tue Dec 27, 2016 1:03 am
Domain 'refused to connect'
You do not have the required permissions to view the files attached to this post.
-
- Posts: 8
- Joined: Tue Dec 27, 2016 1:03 am
Re: Domain 'refused to connect'
I've just realised that the problem lies with the handling of cookies by the Xamarin Forms Android browser. I'm working on a solution...
- Tim Green
- Site Admin
- Posts: 23182
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: Domain 'refused to connect'
Hi David,
Irrespective of whether you can solve your cookie problems or not, displaying external pages in the WebHelp topic pane should be avoided. Some skins won't allow you to do this at all and will automatically open in another page/tab, no matter what you set. The problem is you are injecting a whole package of HTML, CSS and scripting into the page that the WebHelp system knows nothing about and has no idea how to deal with, and it can and often will interfere with the proper functioning of the system.
If you don't want to open in a new page/tab, then at least use the option to open in the top frame. That will completely replace the WebHelp with the target page, and the user will then have to use the browser Back/Previous feature to return. That is fine, but injecting foreign pages into your WebHelp is bad practice.
Irrespective of whether you can solve your cookie problems or not, displaying external pages in the WebHelp topic pane should be avoided. Some skins won't allow you to do this at all and will automatically open in another page/tab, no matter what you set. The problem is you are injecting a whole package of HTML, CSS and scripting into the page that the WebHelp system knows nothing about and has no idea how to deal with, and it can and often will interfere with the proper functioning of the system.
If you don't want to open in a new page/tab, then at least use the option to open in the top frame. That will completely replace the WebHelp with the target page, and the user will then have to use the browser Back/Previous feature to return. That is fine, but injecting foreign pages into your WebHelp is bad practice.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
-
- Posts: 8
- Joined: Tue Dec 27, 2016 1:03 am
Re: Domain 'refused to connect'
Dear Tim,
Thanks for your advice (which I'll take!!). I'm writing help systems for apps running on smartphones and had hoped to avoid opening a separate browser application and instead 'contain' the information on the HelpPage within the application itself. I guess it's not to be!
Interestingly, many of the hyperlinks work in the manner which I had intended, whereas others either 'refuse to connect' or display a blank window.
Thank you again for your advice,
Regards,
Andy
Thanks for your advice (which I'll take!!). I'm writing help systems for apps running on smartphones and had hoped to avoid opening a separate browser application and instead 'contain' the information on the HelpPage within the application itself. I guess it's not to be!
Interestingly, many of the hyperlinks work in the manner which I had intended, whereas others either 'refuse to connect' or display a blank window.
Thank you again for your advice,
Regards,
Andy
- Tim Green
- Site Admin
- Posts: 23182
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: Domain 'refused to connect'
No chance, unfortunately. We struggled with that for a long time before realizing it was hopeless. The sandboxed environment for apps on Android and iOS just makes it impossible, because WebHelp functionality needs a browser and a full web server. The most you can do in a WebView inside an app is very basic single HTML pages with no scripted functionality, and that really needs to be within your own application.David Pybus wrote: ↑Sun May 09, 2021 2:18 am Thanks for your advice (which I'll take!!). I'm writing help systems for apps running on smartphones and had hoped to avoid opening a separate browser application and instead 'contain' the information on the HelpPage within the application itself. I guess it's not to be!
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.