The XPInstall based installer only installs talkback on x% of the installs when doing a basic install. For the NSIS installer we should always install talkback and disable it for x% of the basic (perhaps complete too?) installs. This will then fix the issue where a bug reporter is asked to submit a talkback incident id and they have to run setup to install talkback. There will be a new issue where the bug reporter may have to enable talkback in the extension manager but this is much simpler than having to run the installer to install talkback which will often require a download of the installer first. This will be a bit tricky without adding one-off code to the Extension Manager and I'd prefer if it could all be done by the installation though I doubt that will be possible.

I think we should add EM code to install extensions "disabled by default". Not using install.rdf arcs, but perhaps a override.rdf or override.ini next to it?

I was thinking we could just support userDisabled="true" in the install.rdf. The installer could then add it to the install.rdf on install and the change to the EM code would be greatly minimized for this. Any problems you can think of with this approach?

It will break incremental MARs.

doh! OK, I think your suggestion of an override file will likely be the way to go.

So, I can't think of a reason why we would want to manage any other settings in this manner since they can be managed from the install.rdf but I haven't thought on it very long. If there aren't any others we could just check if the file exists and not bother with opening it. Do you think there is any value in only allowing this for extensions installed into app-global? I think the logic should be as follows with the only question being whether an override should be applied for the complete install case. I think not but this has the potential of increasing the number of users with talkback installed and enabled significantly. Basic Install: if upgrade if talkback exists install it - no override else if new install add override with override per x% Complete Install: install talkback - no override? Advanced Install if talkback selected install it - no override

> thought on it very long. If there aren't any others we could just check if the > file exists and not bother with opening it. Do you think there is any value in > only allowing this for extensions installed into app-global? Not if it makes things more complicated, no. You might ask mkaply if the CCK would benefit from being able to override any other properties. Agreed about the talkback defaults... if the user chose "complete" I expect they'd want to have talkback enabled.

One change to Basic Install: if upgrade if talkback exists install it - no override + elseif talkback doesn't exist install it with override per x% else if new install add override with override per x%

I used QueryPerformanceCounter for the seed since it is an Int64. I over 300,000 runs and the deviation was less than 0.1%

(In reply to comment #7) > One change to Basic Install: > if upgrade > if talkback exists install it - no override > + elseif talkback doesn't exist install it with override per x% > else if new install > add override with override per x% Wouldn't that effectively change the "install for x% of users" algorithm? Over a long time, the % of upgraders with talkback enabled will approach 100% -> Because each time they upgrade, they have a x% chance of getting it, with no corresponding chance of losing it. I'd suggest: if upgrade if talkback exists install it - no override + elseif talkback doesn't exist install it with override else if new install add override with override per x%

It does change it but not quite the way you stated. For upgrades it would install talkback for the 90% that didn't already have it installed and enable talkback for approximately x% where x is currently 10. I agree with installing it disabled for all of the 90% upgrade case though I'm not sure what to detect on without a significant change to the current flow.

Comment on attachment 223754 [details] [diff] [review] patch - install disabled when upgrading an install without talkback >Index: toolkit/mozapps/installer/windows/nsis/installer.nsi >+ ${AndIf} ${FileExists} "$INSTDIR\greprefs" What is this line for? >Index: browser/installer/windows/nsis/defines.nsi.in >+# Percentage of new "Standard" installs to enable talkback for >+!define RandomPercent "10" I think that for alphas/betas we want this to be a large number; perhaps not 100% because we want to test this feature, so how about 75%?

(In reply to comment #12) > >+ ${AndIf} ${FileExists} "$INSTDIR\greprefs" > > What is this line for? We need a way to know if this is an upgrade or not and this directory is probably the one that the uninstaller will be most successful in removing (e.g. 3 files with no subdirectories) so I went with it. I could go with the main exe but that changes per app. I considered going with a reg key but we don't manage those all that well yet. > >+# Percentage of new "Standard" installs to enable talkback for > >+!define RandomPercent "10" > > I think that for alphas/betas we want this to be a large number; perhaps not > 100% because we want to test this feature, so how about 75%? Sounds good. We'll have to remember to change this of course.

Patch as checked in. I updated the EM comment and made the percentage 75

Fixed on trunk

Why 75%? I thought it was decided in bug 333656 that it should be 100% for trunk.

Comment on attachment 223832 [details] [diff] [review] checked in Benjamin, need this on the branch and do you want me to bump this up to 100%?

Comment on attachment 223832 [details] [diff] [review] checked in I'd like to test the randomizing feature, so it should stay at 75%

Checked in to MOZILLA_1_8_BRANCH