Does anybody know if there is some sort of bug or issue with the webBrowser activex control in .NET applications, in this case the embedded browser loads a web page that depends on javascript to play music previews. It works once but if you navigate to a new page in the system it stops working.
Viewing the same site in just a normal IE browser results in no errors at all (tested on several systems of various types).
It happens on several different OS's, XP 32 and 64 bit, Vista, Windows 7.
Its also not a java applet, just jQuery and the longtail video player with some JS to bind a preview link to the player. Im very confused as to why it works sometimes but not others.
Its also a large live system and getting lots of complaints.
Let me tell you this straight up. The default rendering engine on the WebBrowser control is fixed to ensure compatibility across all platforms.
Basically, if your installed browser is IE 7 - IE 9, then the rendering engine used is IE 7.0 only (by default).
If, however, your installed IE version is IE 6 or below, then the rendering engine used is IE 4.0, unless of course you set it otherwise.
There is a misconception that WebBrowser control uses whatever is currently installed (current IE version) but this is not true, since they do this to reduce backward compatibility issues. You can see (as proof) that this really is your problem by going to http://www.whatsmyuseragent.com in your normal browser, and then going to that website again in your WebBrowser control, you will see that it says MSIE 7.0 :).
I suspect your users (and you) who are on IE 6.0 would be experiencing the problems you've alluded to since their rendering engine being used is IE 4.0 (and IE 7 if they are running anything between IE 7 to IE9). This is really bad, especially if they are on IE 6, you should ask them to upgrade their browser if they are IE 6, then, IE 7.0 will be used regardless.
I'm not sure if, when IE 10.0 comes out, the WebBrowser control's default engine will go to 10.0 (if 10.0 is installed on system of course) or if it will remain as IE 7.0 even after IE 10.0 is released, we will have to see once it comes out. However, if we guess based on previous experience, I suspect IE 10.0 will be the last version that uses IE 7.0 rendering engine, and when IE 11 comes out, the default rendering engine will remain as IE 11 for all versions of IE between IE 11 & IE 14. This is just a guess by extrapolating what they've done in the past.
You can set the WebBrowser control to use the current installed version of Internet Explorer; if you want more information on how to do this, or how to further fix the rendering engine, let me know and I'll help you out with it.
Which version of .net are you using?
Also which OS?
Ive noticed within Vista that Java applets <applet> tags causes catastrophic issues. I believe this is due to it using Microsoft JVM for its java processing, which happens to be unsupported now. This does not occur in XP from what ive seen
The web browser control uses the same shell as the installed version of Internet Explorer, but in my experience, the full browser handles things more gracefully.
It is worth adding some debug to the JavaScript to see where the problem is - is it because longtail isn't registering as loaded, so no events are binding or is it because of a problem with the events.
Related
I was wondering if anyone knows what is going to happen with the win forms browser control in the .net framework after IE 11 support is dropped next month. From my understanding the browser control uses an IE shell, but if IE is no longer supported what will happen? are we just SOL? are the porting it to use Edge? just wondering if anyone has heard, I cant seem to find any info. Thanks!
Microsoft is not discontinuing support for IE 11; they're simply not developing another version of IE. According to Lifecycle FAQ—Internet Explorer and Edge:
"Internet Explorer 11 is the last major version of Internet Explorer. Internet Explorer 11 will continue receiving security updates and technical support for the lifecycle of the version of Windows on which it is installed."
Therefore, the answer is:
"The Winforms Browser control will keep working the same way it was before."
In my c# code, I'm working with Selenium version 3.4.
When working with the Chrome browser, the FindElemnt seems to be executed fast compared to IE11. Seems that the FindElemnt method faces some slowness when working with IE11.
Any suggestions??
Ensure you are not using the 64-bit version of the IE WebDriver. It appears to be a known issue. Based on this question there may be some ways to speed up the 64-bit version but I personally have found the 32-bit version to be more reliable.
Info on the underlying issue can also be found in this thread
After investigation of this issue, I have been able to debug the C++ code of the 64-bit
IE driver to determine the root cause. When you are running IE 10 or higher on a 64-bit
version of Windows, by default the process which hosts the containing window that includes the browser chrome (address bar, navigation buttons, menus, etc.) is a 64-bit process.
The process which hosts the window where content is actually rendered (within each
tab) is a 32-bit process. By default, the IE driver attempts to use a windows hook on the content-rendering window to make sure that a key-down message is properly processed before sending a key-up message. This is where the problem is. The windows hook is not installed, because a 32-bit process (the content-rendering process) can't execute 64-bit code. The only way to properly fix this will be to create a second (32-bit) executable to perform the wait for the key-down to be complete. Since this would amount to a massive
rearchitecture of the IE driver's binary components, no timeline is (or will be) available for this change.
Some notes. Careful readers will have already realized that this means that even when
you are running 64-bit Windows, you're likely using a 32-bit version of IE to render
the content. This is a powerful argument for continuing to use the 32-bit version of
the IE driver for IE 10 and above: you're not actually running against a 64-bit version
of IE.
If you insist that you must run the 64-bit version of IEDriverServer.exe, you have
two possible workarounds. First, you can disable native events by setting the "nativeEvents" capability to false using whatever mechanism your language binding provides for this. A more accurate workaround from an input simulation perspective would be to enable the "requireWindowFocus" capability, though this also has a windows hook dependency, which may manifest in other ways.
by james.h.evans.jr on 2014-01-31 19:23:06
Even using the 32-bit version, the IE driver is still significantly slower running the same tests as a Chromium based browser. I have had to add Waits due to the longer page load times using the IE Driver.
I wanted to extend my application to also use different browser. So I start using GeckoFX 45, but after some digging I noticed that Mozilla stopped development of XulRunner, so basically if my understanding is correct it does no have sense to invest in GeckoFX 45 as there will not be other version and I want to use as latest version as possible. Is GeckoFX project affected by stopped development of xulrunner as I think ? Is there any other alternative ?
Geckofx uses libxul which is part of Firefox. From my perspective (which may not be nuanced enough) libxul is essentially the gecko engine.
Firefox.exe -> xul.dll
In the past
xulrunner.exe -> xul.dll
existed and was supported.
geckofx -> xul.dll
Geckofx development isn't in itself affected by the stopping developing of xulrunner. Although it possible that there could be some negative consequences that makes Geckofx development harder due to there being one less user of xul.dll.
As for XUL (the UI specification) itself Firefox internally still uses XUL , although I guess it is unlikely that the XUL spec will get any further development.
I am using a web application which supports VLC plugin to run the video streaming.
For this i have done some approach as follows :
1. Open Chrome and Open url : chrome://flags/#enable-npapi
2. Enable NPAPI
3. Restart the browser.
When i applied above 3 steps then it works fine but from some days chrome doesn't supports these
npapi plugins.
So, What is the solution for it so that i can run
vlc plugin
in chrome as my asp.net application is based on it.
Sorry for my bad English!
From Chrome 45 and foward NPAPI is no longer supported it has been announced for a while now that they would do that by version 45, if VLC plugin relies on it then you might need to wait for an update on the plugin itself or move to other technologies.
The NPAPI page on Chromium.org lists some alternatives:
HTML5 Media Elements
WebRTC
In my opinion, the best thing to do would be to move to one of the newer technologies as Chromium team will probably not revert the depreciation of NPAPI. You could also warn your users to not update Chrome, but that would leave them open to vulnerabilities(Also, most users probably have auto-update enable so...).
Also, this question might be useful
As NPAPI is no longer supported in Chrome, you need to use different web plugin for video streaming, that's all. Browse yourself, there are several good stable ones, I use VXG plugin.
I'm developing an MVC app.
If I (on my Surface Pro) goes to http://www.whatbrowser.org/ it correctly says IE 10.
But if I go to my MVC app and print out the Request.Browser.Version, it returns 7.
Any idea why? Is Request.Browser.Version broken?
Thanks
Some of this is touched on in Detect Internet explorer browser version problems.
Last I knew Request.Browser uses the *.browser files that come with the installs of ASP.NET, and easily get out of date. Microsoft releases updates to them every so often, but not often enough. Currently there are some issues with webform pages breaking on IE10 without updated browser files.
Like the comments have said, browser detection is very broken. If you need to detect the browser, at the very least shy away from using the user agent string, and seriously consider why you need to know exactly what browser is used.
Request.Browser.Version doesn't always return the 'correct' browser version for IE because of many factors including compatibility view, meta tags etc.
You would be better off detecting browser capabilities instead. Further reading here: http://msdn.microsoft.com/library/3yekbd5b
As a personal preference, it would be best to detect the OS instead of the browser. Most of the common HTML5/CSS3 features are supported in IE9 and above and IE9 requires Windows Vista and up. The best way to do this using the User Agent is by checking the Trident. If there is compatibility view enabled via the browser or by using meta tags by the app itself, the wrong 'version' is returned but the Trident remains correct.
PS. This isn't fool proof but this would work most of the time.
Further reading about Trident here: http://msdn.microsoft.com/en-us/library/ms537503(v=vs.85).aspx#PltToken