Skip to content
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

During uninstallations from ARP MSI's progress box is visible without DisplayInternalUI #4652

Closed
wixbot opened this issue Jan 13, 2015 · 10 comments
Milestone

Comments

@wixbot
Copy link

wixbot commented Jan 13, 2015

Please see image: http://1drv.ms/1svfQE6

Originally opened by bmurri

@wixbot
Copy link
Author

wixbot commented Jan 13, 2015

screenshot

Originally posted by bmurri

@wixbot
Copy link
Author

wixbot commented Jan 13, 2015

Please post logs too. (This isn't a general problem with v3.9.)

Originally posted by barnson

@wixbot
Copy link
Author

wixbot commented Jan 22, 2015

Release changed from v3.9 to v3.x

@wixbot wixbot added this to the v3.x milestone Dec 20, 2015
@rseanhall
Copy link
Contributor

@barnson @BMurri Why did we leave this open? I don't see any logs or repro info here.

@BMurri
Copy link

BMurri commented May 2, 2020

I remember the incident. I don't recall the resolution.

@rseanhall
Copy link
Contributor

From the screenshot, it looks like the BA was trying to install that MSI. Even if the bundle is doing an uninstall, if the BA decided to install a package with DisplayInternalUI set to yes, then its UI would be shown.

@BMurri
Copy link

BMurri commented May 2, 2020

The point was that DisplayInternalUI was never in any authoring.

ARP had launched the bundle. The screenshot was taken during Apply.

@rseanhall
Copy link
Contributor

This was fixed in the public commit 3ed4b2ed2e9a9b18a501dfd3b5c3a369e1225fa0 on 9/30/2011 committed to Codeplex. wiutil hadn't set the internal UI handler which meant the initial "Preparing to install..." dialog was shown. https://docs.microsoft.com/en-us/windows/win32/api/msi/nf-msi-msisetexternaluirecord

@BMurri
Copy link

BMurri commented May 2, 2020

That appears right. Why did a bug fixed in 2011 show up in 2015, though?

@rseanhall
Copy link
Contributor

For my own sanity, I have to assume it was built with an old version of v3.6. No one else has reported this issue, and there's no other explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants