winforms
winforms copied to clipboard
dotnet
Mark `WebBrowser` and all related (e.g., HTML* types) as obsolete
Is your feature request related to a problem? Please describe
The WebBrowser control is based on IE Trident engine, which is almost universally unusable for general web browsing these days. It is also based on COM/ActiveX, which poses difficulties in trimming/native AOT scenarios.
Also, Internet Explorer 11 has been retired and is officially out of support as of 15 June 2022. Whilst the underlying Trident engine (mshtml.dll) isn't being removed (yet?) from Windows, the general guidance is to use the modern replacement, which is WebView2 web browser control.
Describe the solution you'd like and alternatives you've considered
For .NET 7 and .NET 8 decorate all web- and html-related types as obsolete (error: false) with a link to directing developers use WebView2 control instead.
The obsoletion process entails the following:
- marking the API as obsolete, which will emit a build warning with a link to more information (refer to https://github.com/dotnet/designs/blob/main/accepted/2020/better-obsoletion/better-obsoletion.md),
- documenting the obsoletion (the team will work with the docs team to make sure the docs are updated),
- enhancing the .NET Upgrade Assistant to guide developer to use the WebView2 API instead (the team will work with .NET Upgrade Assistant team).
The obsoletion will also happen in several stages:
- .NET 7/8 release - build warnings/documentation only
- (likely) subsequent release - build errors / implementation removal
- (possibly) subsequent future release - complete removal of API.
Will this feature affect UI controls?
The affected controls will need to be made hidden from the designer.
Better idea: Replace just the internal implementation with the new browser control.
I don't think this is feasible - the API surface is different, the types are different, the deployment model is different... It sounds similar to "I want to continue building VB6 apps, just plug the .NET runtime under the covers".
Bye bye IE. let mark classes as obsolete. What are internal position? Does any discussion should happen for this plan?
Does any discussion should happen for this plan?
The team has discussed this proposal and reached an agreement that this proposal is worth pursuing further. However, the team doesn't currently have any cycles to work on this further. If you're keen, you're welcome to start working on this.
The obsoletion process entails the following:
- marking the API as obsolete, which will emit a build warning with a link to more information (refer to https://github.com/dotnet/designs/blob/main/accepted/2020/better-obsoletion/better-obsoletion.md),
- documenting the obsoletion (the team will work with the docs team to make sure the docs are updated),
- enhancing the .NET Upgrade Assistant to guide developer to use the WebView2 API instead (the team will work with .NET Upgrade Assistant team).
The obsoletion will also happen in several stages:
- current release - build warnings/documentation only
- (likely) next release - build errors / implementation removal
- subsequent future release - complete removal of API.
enhancing the .NET Upgrade Assistant to help converting MsgBox to MessageBox API.
Not clear what this is means. Does MsgBox uses HTML related classes internally? Where is .NET Upgrade Assistant lives. Ahh, I found link at the bottom of marketing page.
Can MsgBox => MessageBox API conversion treated as separate issue? Or at least work can be split in half that way. Also if you mark this as good first issue, maybe somebody except me can help.
🤦♂️ Haha, I copied that from another issue and missed that bit. I now updated the text above.
Don't hurry up with that. Windows 8.1 is with extended support until January 10, 2023 and as we all know it it has IE11, Trident. Trident itself is fully working and functional in Windows 10,11 and not marked as obsolete. It makes sense to obsolete it here when Microsoft plans removing Trident ? I think this won't happen anytime soon as this will end HTA,Vbscript,Jscript and everything related. That means end of job of many system administrators and WW3
I strongly oppose the removal of the WebBrowser control. I think it should be replaced by its new Chromium equivalent. Since backwards compatibility would be broken anyways by removing it, you might as well keep the intuitive class name but replace it with something newer, and try to reimplement most of the methods in the Chromium engine, with the exact same method names to provide developers with a familiar interface. If I am not mistaken, the WinForms implementation in Mono is reimplemented in Gecko, so it wouldn't hurt to reimplement it in Chromium, just like Edge.
WebView2 could be used as a replacement, but it needs a wrapper to add key back missing functionality. The biggest missing feature is the ability to view the document source which is trivial in WebBrowser.
Webview2 uses many resources on a multi users environment (Such as UDF). We decided to keep good old webbrowser.
Note that we will never remove API from the surface area. We also won't remove the ability to use this. When Windows removes Trident (likely never) then this won't work.
@JeremyKuhne
Note that we will never remove API from the surface area. We also won't remove the ability to use this. When Windows removes Trident (likely never) then this won't work.
What does "Note that we will never remove API from the surface area. We also won't remove the ability to use this." mean in reality?
- The API will always exist but at some time in the future (if Windows removes Trident) it will not do anything, so why keep it?
- Sometime in the future (just before Windows removes Trident) you will reimplement the broken parts and it will work transparently.
- Something else.
If the second is true, why mark it as obsolete. If 3 that?
@paul1956 we'll never remove surface area as that is a binary breaking change. Implementations may change or get removed, but I really doubt that will happen in the foreseeable future. I doubt we would ever reimplement this API over anything else as the cost would be quite high.
I don't make the decisions ultimately, but I know it would take an awful lot for Windows to remove Trident all together as it would be such a major impact. They still ship the VB6 runtime after all. :)
Ultimately, we'll probably do things to encourage you to move off of this, but we have no plans to make this functionality completely inaccessible.
@paul1956 we'll never remove surface area as that is a binary breaking change. Implementations may change or get removed, but I really doubt that will happen in the foreseeable future. I doubt we would ever reimplement this API over anything else as the cost would be quite high.
I don't make the decisions ultimately, but I know it would take an awful lot for Windows to remove Trident all together as it would be such a major impact. They still ship the VB6 runtime after all. :)
Ultimately, we'll probably do things to encourage you to move off of this, but we have no plans to make this functionality completely inaccessible.
The app stopped using it a long time ago, but lost some functionality because it was difficult to implement with WebView2 (when it was done), if WebBrowser was to be continued to be support, I might consider going back. But at the same time WebView2 is getting more functionality so it might not necessary.