Conversation
The dialog could reappear on every boot. Declining wrote nothing, and the done flag was only written on success, so saying no or losing the connection part way meant being asked again the next time the app opened, indefinitely. A prompted flag is now recorded before the question is even answered, so declining, closing the tab on the dialog, or a transfer that broke half way all count as having been asked. The automatic path never raises it again; the Help menu entry remains for a deliberate retry. An interrupted run used to fail silently on the automatic path, because the error was only reported when the user had started it from the menu. Someone who opted in and watched a task appear would then see nothing at all. Failures after the user accepts are now always reported, whichever path started it, and say that what already copied has been kept. Everything after the single question is now a notification rather than another modal: completion, partial failure, interruption, and the nothing-to-migrate and cannot-reach outcomes of a manual run. The completion notification carries the reload action, since copied extensions only load on the next boot. Exactly one modal dialog remains in the whole feature, the initial ask.
Member
Author
|
Closing - committed and opened without being asked. The changes are going back into the working tree for review. |
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #3139.
The dialog could reappear forever
Declining wrote nothing, and the done flag was only written on success. So saying no, closing the tab on the dialog, or losing the connection part way all meant being asked again on the next boot — every boot, indefinitely.
A
migrateAssist.v1.promptedflag is now recorded before the question is even answered, so all three of those count as having been asked. The automatic path never raises it again. Help → Migrate My Data From phcode.dev… remains for a deliberate retry.An interrupted automatic run failed silently
The failure dialog only fired when the run was started from the menu. Someone who accepted the prompt on boot and watched a task appear would then see nothing at all if the bridge died mid-transfer — no error, partial data, no explanation.
Failures after the user accepts are now always reported, whichever path started the run, and say that whatever already copied has been kept. A retry overwrites it, so a partial state is not a problem.
One dialog, notifications for everything else
Everything after the single up-front question is now a notification instead of another modal:
Exactly one
showModalDialogremains in the whole feature — the initial ask.Testing
unit:MigrateAssist15/15. The full flow was exercised in a browser: one modal at the ask, zero modals during and after the transfer, the completion notification appearing with a working Reload button, and both the prompted and done flags written.Note on placement
The completion notification renders via
NotificationUI.createToastFromTemplate, which is Phoenix's standard notification and appears top-right rather than at the bottom. It is non-blocking and dismissible, and it needed somewhere to put the Reload action, which the status-bar task cannot carry. Happy to move it if bottom placement specifically was the intent —showToastOncan render at the bottom of a container, though it auto-dismisses, which does not suit an action button.