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:
parent
0db6789210
commit
f6a29707b6
4 changed files with 86 additions and 9 deletions
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue