feat: app.moveToApplicationsFolder conflict handling (#18916)

Resolves #18805.

We want to keep default move conflict handling behavior in that it's still what most users would expect, but there exist edge cases in which users may not want to be forced into that behavior.

This thus introduces an optional conflict handler that allows developers access to more granular move actions. They could now allow the user to choose whether to delete an existing app in favor of the current one being moved, or whether to quit the current app and focus on the existing one should it both exist and be running. I added a fair amount of new documentation outlining this behavior, but if there are things users may benefit from seeing examples of or nuances that should be added please leave feedback!
This commit is contained in:
Shelley Vohr 2019-07-15 09:34:20 -07:00 committed by GitHub
parent 0db6789210
commit f6a29707b6
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 86 additions and 9 deletions

View file

@ -1430,7 +1430,6 @@ void App::BuildPrototype(v8::Isolate* isolate,
base::BindRepeating(&Browser::ResignCurrentActivity, browser))
.SetMethod("updateCurrentActivity",
base::BindRepeating(&Browser::UpdateCurrentActivity, browser))
// TODO(juturu): Remove in 2.0, deprecate before then with warnings
.SetMethod("moveToApplicationsFolder", &App::MoveToApplicationsFolder)
.SetMethod("isInApplicationsFolder", &App::IsInApplicationsFolder)
#endif