Powertoys: [MSIX][Settings] Starts up when setting isn't enabled

[crutkas]

This could be my system due to development. It could also be due to #1161

From a local dev version:

[yuyoyuppe]

The cause for this is the same as for #1161. It's possible to keep the option in sync with the actual system state via StartupTask API, however, if a user disables PT startup task manually from the task manager, or if she has a certain admin policy in place, it becomes impossible to enable it via API again. It's also possible to detect those cases via the API.
After internal discussion, it was decided to hide the option for MSIX, since we cannot provide 100% working functionality for it.

[enricogior]

For now we remove the "Run at Startup" option when installed as an MSIX package. We can later add information of the current Windows 10 Startup settings status and provide a description for the users if we decide that it's useful to have that information there.

[crutkas]

Wait wait wait

[yuyoyuppe]

@crutkas Hi Clint, what do you suggest? :)

[Felix-Dev]

I'm not sure I'm following here....why do you guys want to remove this option? It works perfectly fine for MSIX packaged desktop apps. In case the option cannot be enabled in the app it means the user has already disallowed automatic start at log-in for this app in the Windows settings at some point. That means the user already is aware of this setting exposed in Windows. In this case, you can simply show a dialog with a question whether the user wants to open the Windows Settings app now to re-enable automatic start. If the user agrees, open the Windows Settings Startup page.

Once re-enabled by the user, the app can always programmatically set this setting to enabled/disabled until the user decides to disable it in Windows settings/TaskManager again.

Given this behavior I'm not sure what the problem here is?

[crutkas]

1. before removing a key piece of functionality, we need to have a much larger conversation.
2. If i'm reading this correctly, i don't agree with removing this. I don't clearly understand the why this was removed. based on what you're stating above, it seems like your focusing on edge cases (still important) at the cost of the majority user base.

[crutkas]

Even based on #1161, it is unclear the end to end reason.

I read it as the following.

• MSI implemented start up one way
• MSIX does it another

The claim then is we have 2? I strongly believe that we have the MSIX. That is the way moving forward and should be in the mental model for that.

If the toggle is to represent 'startup', it should be in sync then with the the startup tab in task manager. If the two are in conflict, startup in task manager is the source of truth.

[enricogior]

OK, so the desired behavior is:

• by default show the option in the PT Settings page
• if the startup status is disabled in the Task Manager/Windows 10 settings, gray out the option in the PT Settings and show a text explaining why the option is grayed out (and possibly add a link to open the Windows 10 Settings->Apps->Startup page).

[Felix-Dev]

Yep, that's the way how I am handling it in my MSIX (secret tip: M6, that style is trending a bit right now in a certain Windows-focused community) desktop app and it works great. A description with a link to the Windows settings in case of permission denied via Windows Settings/Task Manager is useful.

[yuyoyuppe]

Alright you folks, I've implemented the setting's graying out in a new PR.

@crutkas I've tried placing a link to Startup page, but clicking it didn't produce any effect, it might be an issue for WebView team to look into.

That link works from my browser:

<a href="ms-settings:startupapps">the link</a>

And that link doesn't work from WebView:

<Link href="ms-settings:startupapps" target='_blank'>the link</Link>

secret tip: M6

I see what you did there!

[crutkas]

From inside a pure UWP tester app with a webview, this worked
<a href="ms-settings:startupapps">settings</a>

can we create a small repo i can send to the team?

[yuyoyuppe]

@crutkas oh, it might be related to fabric Link control then? I'll try a href directly, thanks.

[yuyoyuppe]

@crutkas
The smallest repro possible is just to replace whole render function in GeneralSettings.tsx as follows:

public render(): JSX.Element {
  return (
    <Link target='_blank' href='ms-settings:startupapps' >google</Link>
    <a href="ms-settings:startupapps">settings</a>
    );
}

I haven't tried with pure UWP tester app though, since it does work for you.

We don't seem to do anything very special with WebViewControl, though I've used NewWindowRequested callback as a workaround for this in #1181.

[enricogior]

Could it be a problem with the way we implement g_webview.NewWindowRequested?

[yuyoyuppe]

@enricogior not very likely - it doesn't get called at all for non-https links. I'll need to verify if the sheer existence of this handler makes any difference though.

[crutkas]

@yuyoyuppe both links won't work in this instance? Does the href link work?

public render(): JSX.Element {
  return (
    <Link target='_blank' href='ms-settings:startupapps' >google</Link>
    <a href="ms-settings:startupapps">settings</a>
    );
}

[yuyoyuppe]

@crutkas both links do nothing for me

[crutkas]

Here is an idea / hack. can we maybe do something like we do for the editors where we launch a different process?

[yuyoyuppe]

@crutkas this is probably meant for #1131? :)

[crutkas]

@yuyoyuppe, did we ever solve the setting link issue? My comment was the link calls code behind that starts the process "ms-settings:startupapps"

[yuyoyuppe]

@crutkas oh yes, we did solve this by that PR. That PR basically modified our open-link-in-new-window handler to translate "https://ms_settings_startupapps" to "ms-settings:startupapps".

[crutkas]

awesome! missed that

[enricogior]

Fix available in 0.15.0 https://github.com/microsoft/PowerToys/releases