Closed Bug 522065 Opened 11 years ago Closed 11 years ago

PCA complains when installer is cancelled

Categories

(Toolkit :: NSIS Installer, defect, P2)

x86
Windows 7
defect

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- .7-fixed
status1.9.1 --- .11-fixed

People

(Reporter: emk, Assigned: robert.strong.bugs)

References

Details

Attachments

(3 files)

Steps to reproduce:
1. Run installer on Windows 7.
2. Cancel the installer.
Actual result:
Program Compatibility Assistant will pop up.
Expected result:
PCA should not pop up.

We need to update manifest to Windows 7 format to satisfy PCA.
http://forums.winamp.com/showthread.php?postid=2525010
Jim, Vlad, and Rob... just a heads up that firefox.exe might need this added as well.

http://code.msdn.microsoft.com/Windows7AppQuality
download the current release available towards the top on the right
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
      <application>
        <!—- The ID below indicates application support for Windows Vista -->
          <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
        <!—- The ID below indicates application support for Windows 7 -->
          <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
      </application>
    </compatibility>
  </assembly>
Flags: blocking1.9.2?
Priority: -- → P2
I don't recall seeing this when I've installed Firefox or Minefield. What do we need to do to trigger this dialog?
I don't know... the first I heard of this happening was last night via a blog entry.
Summary: PCA compains when we canceled the installer → PCA complains when installer is cancelled
Blocks: win7support
I believe it only happens if the executable looks like an installer ("setup" in the name, etc.) and exits *without* adding a Programs and Features entry (may also count updating). A successful install won't trigger it. AFAIK it just suggests re-launching elevated, guessing that the install most likely failed because it didn't elevate.

As long as Firefox's setup elevates by itself (either at the start due to manifest or during the process) when installing for all users, it can be marked compatible with Windows 7 to avoid the PCA. However, if no elevation occurs w/o the user explicitly requesting it (e.g. via Explorer's context menu) then I'd strongly suggest against marking it compatible, since the PCA will be helping people get Firefox installed in that case.

I don't believe Firefox itself would benefit from being marked compatible given the list of things that affects, but that can be infestigated seperately.
Firefox installer asks elevation by itself. We should not rely on the compatibility feature which can be turned off.
Moreover, users can cancel the setup at their own will (as I showed in STR). PCA dialog will confuse them in that case.
Only your first point actually matters. :P
Rob, here the screen of the PCA on W7 trying to install hourly win32.installer.exe files.

I get the PCA error even after setup.exe launches Minefield (firefox.exe) just fine.  I close Minefield, then the PCA pops up just for the installer.exe (no mention of the setup.exe or firefox.exe)
Blocking for investigation; rs, I'll leave it up to you to decide if this is a common issue or not. I don't see what the reporter says is happening, but I also don't cancel installs ;)
Flags: blocking1.9.2? → blocking1.9.2+
Assignee: nobody → robert.bugzilla
Cancelling installs for many installers pops up that dialog, for the reasons that Silver outlines.  It's confusing, but it's not really our UI, and I don't think we would hold the release for it.  Even "wanted" seems like a stretch given our schedule and load at this point, but I'm in a stretchy mood.
Flags: wanted1.9.2+
Flags: blocking1.9.2-
Flags: blocking1.9.2+
Duplicate of this bug: 531388
Duplicate of this bug: 567497
This bug will occur even if I didn't cancel the installer (see the duplicate bug for details).
(In reply to comment #12)
> This bug will occur even if I didn't cancel the installer (see the duplicate
> bug for details).

Confirming, as I was seeing a similar experience.  Though I haven't seen it much since my first comment 7.  Using Win7 32bit.
Depends on: 569058
This will take care of the installer portion... we'll still want to fix bug 569058.

This changes the manifest resource to

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="7zS.sfx.exe" type="win32"/>
<description>7-Zip Self-extracting Archive v4.42</description>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*"/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges><requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
</application>
</compatibility>
</assembly>
Attachment #448695 - Flags: review?(ted.mielczarek)
Attachment #448695 - Attachment description: atch to update the manifest of the 7zSD.sfx → patch to update the manifest of the 7zSD.sfx
Attachment #448695 - Flags: review?(ted.mielczarek) → review+
Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/6a40f493664d

Bug 569058 along with Bug 569534 will fix this for the uninstaller.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: in-testsuite-
Flags: in-litmus-
Resolution: --- → FIXED
Comment on attachment 448695 [details] [diff] [review]
patch to update the manifest of the 7zSD.sfx

Drivers, this updates the 7-zip stub manifest for Windows 7 and we should take it on the branches
Attachment #448695 - Flags: approval1.9.2.5?
Attachment #448695 - Flags: approval1.9.1.11?
cc'ing a few people from SeaMonkey and Thunderbird... you'll want to do this for your 7zSD.sfx files in other-licenses.
Filed bug 569791 for SeaMonkey and attached a patch

Filed Bug 569789 for Thunderbird and attached a patch
Thanks, Rob!
We store the manifest resource in binary in the tree?
It is a resource in the 7-zip self extracting archive itself and we update it when necessary using reshack.exe since we don't compile it at build time. Examples

http://hg.mozilla.org/mozilla-central/log/7e685b61a291/other-licenses/7zstub/firefox/7zSD.sfx

http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/other-licenses/7zstub/firefox/7zSD.sfx&rev=HEAD&mark=1.5
Comment on attachment 448695 [details] [diff] [review]
patch to update the manifest of the 7zSD.sfx

a=LegNeato for 1.9.2.6 and 1.9.1.11. Please land this on mozilla-1.9.2 default and mozilla-1.9.1 default.

Code freeze is this Friday @ 11:59 pm PST.
Attachment #448695 - Flags: approval1.9.2.6+
Attachment #448695 - Flags: approval1.9.2.5?
Attachment #448695 - Flags: approval1.9.1.11?
Attachment #448695 - Flags: approval1.9.1.11+
You need to log in before you can comment on or make changes to this bug.