912925 - Fresh install on a new tablet doesn't offer firefox as a default option

Status: RESOLVED WORKSFORME

(Firefox for Metro Graveyard :: Install/Update, defect)

Description

[Jim Mathies [:jimm]]

We still have this problem for fresh installs after click yes on the first default browser prompt.

Comment 1

[Jim Mathies [:jimm]]

Attachment: Screenshot (1).png

Comment 2

[Jim Mathies [:jimm]]

If I click off the dialog the default programs window opens. From there I can choose firefox (which is listed). The program has 6 out of 8 defaults. Selecting firefox there and setting it as the default completes successfully and I'm able to launch metrofx from the start screen.

Comment 3

[Jim Mathies [:jimm]]

To test fixes I think we'll have to invest some time in wiping win8 and reinstalling fx to confirm.

Comment 4

[Brian R. Bondy [:bbondy]]

I remember you reporting this before as well but I couldn't reproduce with fresh installs.  I think it's an intermittent problem.  Just a thought, but maybe we launch the flyout before helper.exe has a chance to finish registering itself intermittently.

Comment 5

[Brian R. Bondy [:bbondy]]

So I suspect if you would have clicked on the Windows initiated prompt for defaults instead of the Firefox one, Nightly wouldn't be listed there either.   I think the installer is not setting up the StartMenuInternet keys properly or something like that.

These keys get re-fixed when you click yes to default from within Firefox.  But helper.exe is launched without waiting for it to finish, so for that one time you'll not see Nightly listed but the next time you do it you would.
 
To half fix the problem, i.e. fix from within Firefox's prompt and not the Windows prompt, you can change this code:

> nsresult
> LaunchHelper(nsAutoString& aPath)
> {
>   STARTUPINFOW si = {sizeof(si), 0};
>   PROCESS_INFORMATION pi = {0};
> 
>   if (!CreateProcessW(nullptr, (LPWSTR)aPath.get(), nullptr, nullptr, FALSE,
>                       0, nullptr, nullptr, &si, &pi)) {
>     return NS_ERROR_FAILURE;
>   }
> 
>   CloseHandle(pi.hProcess);
>   CloseHandle(pi.hThread);
>   return NS_OK;
> }

To instead be launched in another thread and have it wait for helper.exe to finish before launching the defaults http flyout.

I think a better fix would be to reproduce this problem via going directly to control panel's http default prompt. Then once you can reproduce consistently after an install check the registry around StartMenuInternet keys and see what's missing. 

Unfortunately I can't reproduce it though.

Comment 6

[Jim Mathies [:jimm]]

The particular case here with my screen shot doesn't involve the installer. The install location is T on my surface pro, so it's either a local build or zip build I've unpacked. Sounds like your guess might be right.

Comment 7

[Brian R. Bondy [:bbondy]]

oh! if you weren't using an installer then there is no bug with the installer and we should go ahead with the mentioned fixed in Comment 5.

Comment 8

[Brian R. Bondy [:bbondy]]

Note that this shouldn't be critical if it wasn't from an installer too because the installer itself sets the keys correctly. So once you go into Firefox the keys will already be set and you can run helper.exe and not wait for the result without a problem.

If you are sure it wasn't from an installer originally I'd boot this into v2.