-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove XBAP-related dead code from Application/BrowserInteropHelper, finish cleanup #9865
Conversation
318c2f7
to
6c8931f
Compare
Looks like one of the changes in #9220 was here. Rebased and resolved merge conflicts. |
6c8931f
to
d562996
Compare
Resolved merge conflicts 01 |
d562996
to
4337790
Compare
Fix merge conflicts after #9521 |
4337790
to
5b800e2
Compare
Resolved merge conflicts after #9855 @harshit7962 Can we go with this one and #9943 next? |
@harshit7962 Awesome, let me know at which part you'd like me to resolve the conflicts. I feel its counter-productive to do it now should a style-PR get merged meanwhile as that will mess up the resolutions. |
Sure, will let you know when the PR is ready to be merged. It would be better to resolve the conflicts at that time. |
...icrosoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Interop/BrowserInteropHelper.cs
Show resolved
Hide resolved
@h3xds1nz, we are done with the test pass and its all green. We are ready to take this change in. |
5b800e2
to
cf2f430
Compare
@harshit7962 Great, should be merged/rebased properly I hope. |
@h3xds1nz, thanks for the contribution. We are working on getting in the PRs that have passed the tests. Please let us know if any of these you would like us to prioritize. Also, feel free to mention any PR that you would like us to include in the next test run. |
Description
This continues the work started in #9855, removing rest of the internal properties in
BrowserInteropHelper
and thanks to this we can remove dead code in other places of the codebase (Application
,AppSecurityManager
, etc.) I've separated the two as those deletions might be a bit harder to grasp, while the first one is easier to understand imho.SiteOfOriginContainer.BrowserSource
is never set, thus it is alwaysNULL
.Uri
inBrowserInteropHelper
in alwaysNULL
.GetReferer
method inBindUriHelper
depends on this value, ifBrowserSource
is NULL, it returnsNULL
.httpRequest.Referer
ofWpfWebRequestHelper
would end up beingNULL
anyways, no-op / dead code.Application.MimeType
is never set, thus it is alwaysMimeType.Unknown
.IsViewer
ofBrowserInteropHelper
is alwaysfalse
.IsInitialViewerNavigation
is alwaysfalse
and its underlying value does not matter at all for any operations. So we can remove any setters; and then we can remove it from both conditions; which makes it unused.Application.ServiceProvider
is never set (classes doing it don't exist anymore), so it is alwaysNULL
.GetService
also don't exist anymore, so the whole method does not matter.AppSecurityManager
just call themselves, besides that we were still callingClearSecurityManager
from Application but it is never initialized anymore so there's nothing to clear.SecurityMgrSite
is never initialized anymore, so we can remove it as well.Customer Impact
Decreased size of assemblies, tiny bit of perf, cleaner codebase for developers.
Regression
No.
Testing
Local build, app run.
Risk
Low, the code is a dead code or it doesn't do anything.
Microsoft Reviewers: Open in CodeFlow