The first proposal is going to regress what Fischer is doing, which is finishing up the remaining "move perferences to in-content" work that has been lengering for YEARS. I would prefer not to do that unless that really cuts efforts significantly.
Fischer is going to hit the same problem that we are so if he's fixing the CA trust dialog then we would be able to use the same solution and wouldn't need to worry about this causing more work for us.
I personally don't think it's worth anyone's time to fix that CA trust dialog since it's buried and I also don't think using a real dialog for the 2nd level is the end of the world as we're talking about the case where we're two levels deep. We can declare that dialogs are acceptable on top of another dialog if we want. I was suggesting that it's more of a UX decision to figure out the long term approach. Approach 1 is the easiest to adapt into future approaches as it keeps the markup for the two dialogs separate..
I don't have strong opinion between the second and the third. We could pick one of them that takes the less effort (seems to be the 2nd one from your description but I am not sure.)
Luke and I are starting to implement the autofill profile list and edit dialog in preference panel, but we faced a problem while discussing about the nested dialog. There's no existing mechanism for dealing nested dialog behavior, so we just discussed with MattN for the possible solutions:
- The fastest way is implementing the first list dialog as in-content dialog and displaying the second window-dialog on top of the first one(See the attached images). But the window-dialog will be removed and depreciated in long term.
- Implement another dialog(or other type) component for handling 1st dialog, and using original subDialog module for the 2nd dialog.
e.g. like the panel subviews (see the menu panel and identity panel)
- Refactor the original subDialog module to support nested dialog case.
We prefer the first solution since we could spend less efforts for it, and we might still need to refactor the subDialog module once the preference panel refresh is ready(but the schedule is unconfirmed). Could you help us to coordinate and finalize the decision about dialog implementation in MVP?
I think we should find out from UX what the ideal behaviour is and build towards that but not necessarily exactly that for M1. https://mozilla.invisionapp.com/share/AP8TFZ22G#/screens/185446458 implies that the list dialog isn't visible behind the the add/edit dialog so maybe we can do the other option that Luke or Steve mentioned yesterday which is to simulate nested dialogs by switching the contents of the dialog wrapper. My concern is that there will be a flicker navigating from the list view to the add/edit view and that this approach would require the inner list view page being able to call gSubDialog.open which is in the top-level scope.
I think regardless of what the final UX is, it will be safest to implement the dialogs as standalone documents for now since they will be usable in all four solutions that way. We can do automated tests on the dialogs as if they're standalone with window.open (like I planned anyways) and figure out how to tie them together properly later. i.e. I don't think any of the four proposals significantly affect the implementation for M1, only what happens when clicking add/edit from the list view or ok/cancel/close from the add/edit view.