I have talked about this on a previous post, but hadn't received any feedback on it directly (probably cause it was a multi-question post). However we are noticing some major differences in behavior between how some of our web pages behave in embedded mode VS external.
It's hard to provide specific examples because I don't know what is wrong, obviously some sort of web script is error-ing out, however I don't know why or how to find it. So first question would be how can I debug a web page (IE) in RDM? Any applicable logs or some sort of debug mode that can be enabled?
I am aware that RDM uses ActiveX controls to render the IE page. Now I HATE (with a passion) Internet Explorer, so I try my best to stay away from running it directly however the sites we work with require IE. So I try to use Chrome as much as I can if possible. For example, I have a Chrome Add-on called 'IE Tab' that emulates IE within a Chrome tab. It actually works REALLY well. I have never had any issues with it not working or varying from what the real browser does. Now, I'd imagine this addon works differently from what RDM does, however I wanted to share in case this would help y'all to gain insight on how you "could" better the IE embedded tab module. For the most part, it's usable, but these small things force us to open it externally and re-login etc, and also we can't ever fully trust the behavior of the page since we have no idea what is causing these scripts to error.
We'd like to see some improvement in this area, ideally just normal predictable browser behavior.
We "might" be able to provide a specific example, so send me a PM (site is behind a login) if you would like to see something like that.
HB
Hello,
I am not a developer, but I think that you are encountering issue with IE embedded because our integration is based on Microsoft ActiveX and since IE is being phase out by Microsoft, I don't think that they still offer updates regarding IE. I will ask our engineering department to have a look at your topic and reply here.
That being said, regarding the script errors that you receive, the only solution that I can proposed is to enable the Hide script errors option in the properties of your IE entry. Please note that this option is only available in embedded mode.
Best regards,
Jeff Dagenais
Hello,
Unfortunately since we use the .NET web browser control to simulate IE in embedded mode, we're restricted by what we can change in how it acts. I don't think we can do much in regards to the support of scripts.
In RDM, you can check in File > Options > Types > Web and change the IE mode to a different version, perhaps it will help change the behavior.
Regards,
Hubert Mireault
@Hubert,
Can you send me a link to a resource page pertaining to the .NET web browser control that y'all are using or/and maybe a code snippet of how y'all are using it? Perhaps I can run it in my own demo application so I can test what does and doesn't work and what can be done about it.
In the mean time I will meddle with 'IE Mode' that you mentioned and see if anything behaves differently.
HB
We use the System.Windows.Forms WebBrowser: https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.webbrowser?view=netframework-4.7.2
We don't change anything that should affect the execution of scripts, so you'd just need to use the control as-is in your test application.
Regards,
Hubert Mireault
Are you able to share how y'all enforce a particular 'IE Mode' with that control? I'm looking into it and don't see many direct ways.
HB
To do this we set a registry key located in HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION with the same executable name set to 11000 (IE11), 10000 (IE10), 9000 (IE9), etc. You can find more information on this MSDN article under the "browser emulation" category: https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/general-info/ee330730(v=vs.85)
Regards,
Hubert Mireault
Got ya! I had literally just confirmed that was what y'all were doing. Looking at the registry on my PC, I see that it is being set to '11000', which makes sense cause I have 'IE Mode' set for IE11.
Now looking at this forum post, I am seeing that if it is set to the code above AND !DOCTYPE is not present then IE7 will be used. I think this might be the problem, since I don't see a !DOCTYPE on the sites we are working with. Is it possible for y'all to patch this setting so that we can override and pass in our own values? Looking at the post I shared, '11001' seems like it might work for us. I tried changing it manually in the registry after the program had executed, but I didn't see any differences in behavior.
HB
Could you change the registry key while RDM is closed and then open it? It might not apply without a restart of the application.
If changing the registry key manually doesn't work, then that wouldn't fix the issue since for "IE mode" this is the only thing we change.
Regards,
Hubert Mireault
When I change the key while RDM is closed, RDM will just overwrite it next time it's open.
HB
Sooo, messing with my own application I was able to test the different varieties of codes and see what does and doesn't work for our use case. Neither 11000 nor 11001 worked, however dropping it all the way down to 7000 DID work. Which makes sense cause of how our app requires compatibility mode (way outdated and reliant on features of the time).
Now, another thing I noticed was that if a completely deleted the key for the .exe and didn't recreate it, the application would work as expected, perhaps piggybacking on the current local setup/config? So maybe that should be the appropriate solution so that other types of browsing sessions work properly. Can we add an option to completely remove that registry key?
HB
Looking at the code if you apply the "default" mode it should remove the registry key. Can you check?
Regards,
Hubert Mireault
It does remove it, however upon restarting RDM, it adds it back in as 11000 AND checking the 'IE Mode' in options again shows that it was set back to 'Internet Explorer 11' rather than 'Default.
HB
Does the application read the registry key on load to determine what value to set the 'IE Mode' to, OR is it stored in a config file somewhere? I'm looking at '%LocalAppData%\Devolutions\RemoteDesktopManager\RemoteDesktopManager.cfg' but can't find where it is set.
HB
Here is how we read the IEEmulation mode
try
{
int? value = RegistryUtils.GetIntegerValue(
Registry.CurrentUser,
RegBrowserEmulationKey,
Path.GetFileName(ReflectionUtils.AssemblyExecutable));
if (value == null)
{
value = 0;
}
switch (value)
{
case 7000:
return IEBrowserEmulationMode.IE7;
case 8000:
return IEBrowserEmulationMode.IE8;
case 9000:
return IEBrowserEmulationMode.IE9;
case 10000:
return IEBrowserEmulationMode.IE10;
case 11000:
return IEBrowserEmulationMode.IE11;
default:
return IEBrowserEmulationMode.Default;
}
}
catch (Exception ex)
{
LogManager.LogDebug(ex);
return IEBrowserEmulationMode.Default;
}
David Hervieux
@David,
Any comments on the behavior I mentioned for the default option?
HB
Hello,
I did more investigation and if you set default, RDM update it to the latest. I will add 11001 (IE 11( Edge mode) and Custom). Custom will not change what you have. What do you think?
Regards
David Hervieux
So with the way you're planning on setting up custom, will it use whatever value is already set in the registry prior to the application loading? Is that what you are meaning? That would work! Although I'd say a better approach would be just have a free entry textbox along with the Custom option that way we could specify our own code if need be and IF blank then don't set the key at all (along with deleting the existing entry). Something like that.
Personally I don't mind editing the registry myself, however the textbox route would be easier for the user experience so that they don't have to meddle with the registry BUT do need a custom code.
HB
Yes the custom will let you keep what you will set but I will also add Internet Explorer 11 (Edge) as an option.
Regards
David Hervieux
Sounds like a plan. Thanks for looking into this! Is this something you'll be able to implement easily enough by the next patch?
HB
I've already done it :)
Regards
David Hervieux
You da man! Appreciate all your help, on this one and my numerous other tickets.
HB
@David,
I finally got around to testing this out, and there is a flaw. Since the state of the IE mode is determined by the current value of the reg key on load of RDM, and that configuration value is not stored in RDM config's itself (that I know of), default is assumed WHEN no registry key exists, however that is exactly what I need my custom option to operate as. Basically I just need RDM to not mess with registry key at all. Would it be possible for you to add a checkbox option for enabling 'IE Mode check' or something like that. Any other ideas?
HB
@David,
Hate to be a bother, but unfortunately this is preventing me from being able to use some of our web connections from within RDM as embedded. 90% of them require the compatibility mode for IE 7, while some utility sites don't require any mode set. From my testing, removing the registry key completely will respect the 'Compatibility View Settings' that is already preset per domain from with in IE itself, which is exactly what I need.
Sorry for the delay, we have lot of people on vacation for the Holidays. Have you tried the latest version of RDM and try to set Custom? Custom does not change anything in the registry.
Regards
David Hervieux
@David,
See my previous response. That was what I experienced after updating to the latest version of RDM. Seems to just be an conflicting case set when the application loads.
HB
I think I understand. I will try to work on this.
Regards
David Hervieux
@David
Any progress? Luckily 90% of all our connections need this compatibility mode enabled anyhow, but I'd like to start using some of these other sites within RDM eventually. :)
I did the implementation in the current beta.
David Hervieux
Nice. When do you think the beta will be released into production? Do you have set release cycles?
HB
Hello,
We're currently doing some fine-tuning and we'll be releasing 2019 as a stable release once we judge it ready. We're shooting for a release in a few weeks, but we can't be sure of when exactly.
Regards,
Samuel Baker
Any traction on this?
HB
Hello,
According to the last reply on this forum thread, I suspect that the fix you were looking for is already implemented in RDM 2019.1.41.
Do you still experience this issue with this version?
Best regards,
James Lafleur