Attention is currently required from: Joe Downing.
Patch set 6:Commit-Queue +1
2 comments:
Patchset:
PTAL thanks!
File remoting/host/remote_open_url_client_delegate_win.cc:
Patch Set #6, Line 128: CURRENT_MODULE()
Looks like we sometimes use `GetModuleHandle(L"remoting_core.dll")`. Not sure if there is any difference?
To view, visit change 3088354. To unsubscribe, or for help writing mail filters, visit settings.
Attention is currently required from: Joe Downing.
Patch set 11:Commit-Queue +1
1 comment:
Patchset:
Ping!
To view, visit change 3088354. To unsubscribe, or for help writing mail filters, visit settings.
Attention is currently required from: Yuwei Huang.
1 comment:
Patchset:
I have a question before reviewing this. The CL description says that this is needed because external users might enable this feature by choosing the CRD forwarder manually when setting their default browser (since we aren't exposing the UI in the website).
Is that the only scenario you need this? IIRC our plan was to enable this feature externally as well so at that point, we would expect a fallback browser to be populated. In that case, maybe we should just pop the Windows default browser chooser if no default has been selected. That would require less code and I think would work reasonably well.
To view, visit change 3088354. To unsubscribe, or for help writing mail filters, visit settings.
Attention is currently required from: Joe Downing.
1 comment:
Patchset:
Is that the only scenario you need this?
I guess it will be needed until we enable the UI for external users. It will also be needed if the user changes the default browser manually without using the checkbox.
maybe we should just pop the Windows default browser chooser if no default has been selected.
By "Windows default browser chooser", do you mean the default browser settings app, or something similar to the GTK app chooser dialog[1]? I haven't found any Windows equivalent API for the latter. If you are talking about the former, then an alternative could be:
1. show a prompt that asks the user to set the default browser to the fallback browser they prefer
2. then show another prompt that asks them to change it back to the URL forwarder
This is a bit jarring as the user would need to change the default browser 3 times to get it working properly. I guess it's less of a problem if the UI later becomes available to external users. It would still be jarring if we later decide to implement some advanced option for the user to change the fallback browser.
I'm just reading these Microsoft blogs[2][3]. It appears that we may be able to enumerate installed browsers using some win32 APIs, which is presumably more deterministic and easier to implement than walking through the registry. WDYT?
[1]: https://lazka.github.io/pgi-docs/Gtk-3.0/classes/AppChooserDialog.html
[2]: https://devblogs.microsoft.com/oldnewthing/20151207-00/?p=92341
[3]: https://devblogs.microsoft.com/oldnewthing/20151130-00/?p=92191
To view, visit change 3088354. To unsubscribe, or for help writing mail filters, visit settings.
Attention is currently required from: Yuwei Huang.
1 comment:
Patchset:
> Is that the only scenario you need this? […]
I'm suggesting that if the user doesn't configure the URL forwarder via the website (meaning no fallback is registered) then just show the Windows browser chooser to allow them to pick a different default browser.
When we enable the feature for external users, then they can go through the proper flow to configure everything and a default browser will be configured as part of that process.
To view, visit change 3088354. To unsubscribe, or for help writing mail filters, visit settings.
Attention is currently required from: Joe Downing.
1 comment:
Patchset:
I'm suggesting that if the user doesn't configure the URL forwarder via the website (meaning no fallback is registered) then just show the Windows browser chooser to allow them to pick a different default browser.
Do you mean if we can't determine the fallback browser, then we just force the user to use a different browser, and maybe show a dialog like this:
```
Chrome Remote Desktop cannot determine the browser to open URLs locally. Please change the default browser to the browser you want to open URLs locally, then check the checkbox on the client website to reconfigure the URL forwarder.
```
When we enable the feature for external users, then they can go through the proper flow to configure everything and a default browser will be configured as part of that process.
Yes, but there are still a few edge cases:
1. User uninstalls the fallback browser
2. User insists on changing the default browser using the Windows settings app
3. The "change fallback browser" option, if we later decide to implement it
We could probably still go with the approach above though given these cases seem to be rare.
To view, visit change 3088354. To unsubscribe, or for help writing mail filters, visit settings.
Patchset:
> I'm suggesting that if the user doesn't configure the URL forwarder via the website (meaning no fa […]
Hmm.. It appears that I can also run ShellExecuteEx() with an `openas` verb to open a URL with the "open with" dialog (which is mentioned in a Microsoft blog but isn't documented in the API reference..) However, we won't be able to get back the ProgID of the browser that the user chose. It's also quite confusing since the "Chrome Remote Desktop URL Forwarder" would be the default option in the dialog. If you choose it then (a new instance of) the URL forwarder will pop up the "open with" dialog again.
To view, visit change 3088354. To unsubscribe, or for help writing mail filters, visit settings.
Patchset:
Abandoned in favor of crrev.com/c/3139553.
To view, visit change 3088354. To unsubscribe, or for help writing mail filters, visit settings.
Yuwei Huang abandoned this change.
To view, visit change 3088354. To unsubscribe, or for help writing mail filters, visit settings.