mas-cli / mas

:package: Mac App Store command line interface
MIT License
10.87k stars 274 forks source link

`open` displays a spurious error dialog after opening `App Store.app` #217

Open phatblat opened 5 years ago

phatblat commented 5 years ago

Describe the bug Using the mas open command works to open the app store app, but an error dialog always appears a few seconds later.

To Reproduce Steps to reproduce the behavior:

  1. Run mas open with no appID
  2. Observe the app store app open
  3. Observe "Loading" spinner in center of
  4. See error dialog saying "

Expected behavior The app store app opens to the "★ Discover" tab.

Actual behavior An error dialog appears after a few seconds with the following message:

Cannot Connect to App Store [Retry] [OK]

Screenshots This is the dialog that appears after a few seconds. screen shot 2019-02-04 at 2 11 10 pm

Desktop (please complete the following information):

Additional context Using the mas open appstore command behaves the same.

Note that clicking a link such as macappstore:// (or running the open macappstore:// command in Terminal) does the same thing. This seems to be the current behavior of the MAS GUI app on Mojave. Perhaps there is a specific host or path that needs to be added to the URL to indicate the desired landing page and prevent this message.

Also, the macappstore://showUpdatesPage URL (discovered on an OS X Daily post) successfully opens the MAS GUI app to the "⬇ Updates" tab without error.

rgoldberg commented 1 month ago

@mas-cli/contributors

I've found a way to open the App Store to the most recently open left sidebar tab (e.g., Discover, Arcade, Create, …) without any dialogs popping up:

NSWorkspace.shared.openApplication(
    at: NSWorkspace.shared.urlForApplication(toOpen: URL(string: "macappstore:")!)!,
    configuration: NSWorkspace.OpenConfiguration()
) { 

openApplication(at:configuration:), however, requires some entitlements to be set, which can only be done for an Xcode project (or maybe for an Xcode workspace). mas currently is a Swift package. From what I've seen, that's mainly necessary for either cross-platform code or for library code, but neither of those situations seems to be applicable to mas. Is there any reason why mas shouldn't change from a Swift package to an Xcode project (and/or workspace)?

We could still try to find some other way to open the App Store to the most recent main page without any spurious dialogs and without needing entitlements.

Additionally, each of the left sidebar tabs, and some other standard pages of the App Store, can be opened with URLs like:

# macappstore://?action=<lower case tab name> opens the corresponding tab from the left sidebar
macappstore://?action=discover
macappstore://?action=updates
…

# opens the 'Account Settings' floating page, which is not a tab
macappstore://?action=account

# opens the 'Redeem Gift Card' floating page, which is not a tab
macappstore://?action=redeem

# opens the list of purchased apps that you normally access from the bottom of the left sidebar from the tab labelled with your Apple ID profile avatar & name
macappstore://?action=purchased

Instead of mas open (without any arguments) opening the most recent open sidebar tab, it could open a default action (I'd prefer updates, but maybe others prefer discover or something else; we could make the default configurable via an environment variable or config file).

To specify an action on the command line, which of the following options do you prefer for the example of updates:

mas open --updates

mas open --action updates
mas open --action-updates
mas open --action:updates
…

I prefer mas open --action updates.

We could either limit the options to the known valid actions (which would require updating the list of actions whenever valid actions are changed or discovered), or we could allow any ad hoc value for action. Any value that is unrecognized just opens the App Store to the most recent tab & outputs the original spurious error dialog. If we allow ad hoc values, I would go for an option syntax that begins with --action, because maybe we might want to add other options to open that could clash with an existing or new action/tab name.

I can easily implement whatever syntax & behavior you prefer.