[Context menu] The Open in new tab context menu item should always be available

[akhenry]

Currently the Open in New Tab option is not available from the elements pool in edit mode, it should be.

[TypicalFooBar]

I found out why the New Tab option is not available when in edit mode. It is a part of a blacklist here: https://github.com/nasa/openmct/blob/master/platform/commonUI/edit/bundle.js#L390

When I remove the "window" entry from the blacklist it does show up when in edit mode.

Now, the only problem is that when clicking on that button it opens up a new tab, but it doesn't open up in edit mode. So, now you've got the old tab open in edit mode and the new tab open in view mode. I have a few questions about this:

1. Is there a query parameter I can put in to make it open a page in edit mode?
   • If this isn't feasible, then it actually wouldn't save the user any clicks to have the New Tab button available in edit mode and would actually be an extra click (New Tab -> Edit Mode vs. Edit Mode -> New Tab -> Edit Mode).
2. Does it make sense to keep edit mode open on the first tab if the user has clicked the new tab button and during edit mode? If the user is expecting to edit everything in the second tab, what happens when they click save and then go back to the first tab (which is still in edit mode)?
   • Perhaps the first tab needs to be removed from edit mode before opening the new tab in edit mode. Maybe the New Tab button can first check to see if it's in edit mode and if it is, then leave edit mode and disregard all changes.
3. What if the user has made partial edits before clicking edit mode, but they haven't yet saved?
   • My thought for a good user experience is that the current changes would transfer over. Just some initial thoughts on how that could be accomplished 1) Save everything, leave edit mode, and then open the new tab in edit mode. I don't like this idea because if the user later decides not to save the changes on the new tab, then we'd have to figure out how to revert back to what was there previously. 2) Stuff all the changes into query parameters. I'm unsure if this is a good approach, but my gut feeling is that it isn't. 3) We don't transfer over any of the user's current edits and the expectation is that the New Tab button will start a fresh edit mode for whatever object the user is editing. It is certainly the easier route.

Not sure what the best approach here is, but thought I'd share what I found and my thoughts.

[VWoeltjen]

Thanks for taking a look at this issue; to answer your questions:

Is there a query parameter I can put in to make it open a page in edit mode?

Not currently; we could add one, but I'm not sure if the user expectation would actually be that they'd see the object in Edit mode. My inclination would be to have Open in New Tab open the object into Browse mode, since that's the simpler solution, and respond to user feedback if what they really wanted was something different. @charlesh88 - does that sound reasonable to you?

Does it make sense to keep edit mode open on the first tab if the user has clicked the new tab button and during edit mode? If the user is expecting to edit everything in the second tab, what happens when they click save and then go back to the first tab (which is still in edit mode)?

In a similar spirit, I'd leave the user in Edit mode in the original window. They can always X or Save their way out of Edit mode, if that's what they want to do.

What if the user has made partial edits before clicking edit mode, but they haven't yet saved?

I agree with you that it would make sense to open the object and show those partial changes. As you've pointed out, this leads to other difficulties; additionally, we don't auto-update object state in any given browser window, so if you continue editing after Open in New Tab you are likely to run into conflicts in the window where you started editing. This is another reason why I favor an "open the latest saved version in Browse mode"; it seems least likely to confuse a user in the absence of other, broader changes.

[TypicalFooBar]

Oh, that makes sense. I think I misinterpreted the issue; I just assumed the new tab should be showing the same view in edit mode. If all that is desired is for the button to show and for the new tab to open in browse mode, then I think it's as simple as removing it from the blacklist.

I can make a pull request for that later this evening. Thanks for the info!

[larkin]

We purposely removed this from edit mode due do serious bugs that can be caused by persistence conflicts with multiple instances of the application running. At this time, fixing this bug would be a bad thing. The use cases for "open in new tab in edit mode" will be resolved by sub object editing and futher improved upon by "show me a large view of this object". We should re-tag this ticket accordingly and not implement it at this time.

[VWoeltjen]

Is it possible to arrive at a different state via "Edit then Open in New Tab" than you can via "Open in New Tab then Edit" behaviors, or is the concern here just that the workflow would set misleading expectations for the user? If I'm thinking of the same persistence conflicts, Open in New Tab (from Edit or otherwise) isn't necessary to encounter those.

[larkin]

Yes, it doesn't fully prevent the problem, but disabling it in edit mode prevents a set of misleading expectations. Considering we already blacklisted "open in new tab" I don't think we should bring it back until we fix the underlying cause.

[VWoeltjen]

Got it; I thought the blacklisting was due to #399 and similar issues, but if we have a UX problem blocking this as well than I agree with backlogging this.

[larkin]

Hrm, looking at the history this might just be a mistake. Consensus in #794 is that this should be enabled. But then there is a commit which says "added open in new tab to edit mode" despite the fact that it did not actually add the action, and then those changes were refactored to bundle.js with 06436c4.

I'm thinking this should be enabled and it is a bug that it is disabled. Sorry for the mix up, carry on.

[akhenry]

Closed by #1157

[VWoeltjen]

Verified in testathon 2016-09-19

[charlesh88]

Testathon 2016-09-19: verified.

[charlesh88]

This was verified; removing tag.