Visualization editor doesn't provide any way to save when embedded

[jportner]

Kibana version: 8.2 (unreleased), but I think this behavior has been around for a long time

Describe the bug:

When you are viewing an iframe-embedded dashboard with Top Menu enabled, you can edit the dashboard. If you do this and you go to create a new visualization, there's no way to save that visualization or navigate back to the dashboard.

Steps to reproduce:

1. Configure Kibana to allow anonymous authentication and relax cookie restrictions:

   xpack.security.authc.providers:
     basic.basic1:
       order: 0
     anonymous.anonymous1:
       order: 1
       credentials:
         username: "elastic"
         password: "changeme"
   xpack.security.sameSiteCookies: "None"

2. Start Kibana, log in, and add the Ecommerce Sample Data
3. View the dashboard and generate embed code with "Saved object", "Top menu" and "Public URL" options enabled:
   
4. Embed the sample dashboard in another website using an iframe. You can use https://jsfiddle.net/ to test this. Here's what it looks like (viewport adjusted to 1024x768):
   
5. Click the button to Edit the dashboard:
   
6. Click the button to "Create visualization":
   

Expected behavior:

There should be some way to save the visualization and/or cancel and go back to the dashboard in this scenario.
When you take the same steps in a non-iframe-embedded context, and the top header/nav bars aren't hidden, here are the controls that you see:

[elasticmachine]

Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors)

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[elasticmachine]

Pinging @elastic/kibana-gis (Team:Geo)

[flash1293]

I see how the expected behavior makes sense, it basically assumes the individual panel editors are "part" of the dashboards so they are inheriting the "embedded" state and should function in this context. @ghudgins @teresaalvarezsoler does this make sense? Or should we disallow editing from within an embedded context?

The feature of even showing the top nav menu in embeddable state was a community contribution a while ago, I don't think we made a deliberate decision at any point whether editing within an iframe should be a thing or not.

In case we decide the editors are part of the dashboard (which includes maps) and should function in this scenario, then we would need an additional property on the state transfer object to make the editor apps aware they are currently embedded, then implement the same inline menu featured on dashboards.

Otherwise it won't be too difficult to not allow the navigation, but I can see this being useful in some situations at least, so no strong opinion either way.

Would love to get input from @nreese and @ThomThomson on this as well.

[nreese]

The PR that add embed mode options in the Share UI in case anyone wants more context.

I think the option to show Top menu should be removed since none of the options make since in an iframe. iframes should be viewed as a way to consume Kibana, not author Kibana.

• "Full screen" is not needed. If you wanted an iframe with no chrome then you could just share with all options unchecked
• "Share" this is like looking into a hall of mirrors. Users should have to go back to Kibana, make edits, and then share from the original
• "Clone" and "Edit" - iframes should be consumption only and it does not makes sense to expose these from an iframe.

[ThomThomson]

For what it's worth, I very much agree with @nreese. More than anything, I see the embedding / iframe capability used as a workaround for hiding the top nav menu, and the query / filter bar to give a simpler UI to users. Some advanced use cases have buttons which inject state into the dashboard from the site around the iframe, but those are rare.

The use case that @jportner is working through here for his client is a request that I've never seen before, and I'm not sure if it's something that we want to support.

[jportner]

I think the option to show Top menu should be removed since none of the options make since in an iframe. iframes should be viewed as a way to consume Kibana, not author Kibana.

I appreciate that viewing/consuming Kibana is our most common use case for iframes, but we are seeing managed service providers (MSPs) starting to integrate Kibana into their products in novel ways. I think this particular example (allowing a user to edit a dashboard when it's in embed mode) is kind of compelling even if it isn't something any of us have seen before -- I'm not sure we should immediately rule it out.

The idea here is that there's a Kibana dashboard inside of another application, and you can customize the dashboard to your liking. Sounds pretty reasonable, and the existing UX almost perfectly facilitates that.

Perhaps it would be good to get a Product perspective to see if supporting MSPs in ways like this is something we've had demand for, and if this is a direction that we want to move in. @ghudgins do you have any opinions?

[ghudgins]

overall I think the primary use of iframing dashboards is a view use-case so probably not too critical to prioritize at this time. I'm not aware of users embedding kibana in this way but that might be because of my own focus on solution use cases. @VijayDoshi any thoughts on this as well?

[ghudgins]

@teresaalvarezsoler - we could be more explicit about this intent if we made an issue to prevent editing of dashboards that are embedded via iframe. something to 🤔...we discussed in talking about this issue during planning

[teresaalvarezsoler]

Makes sense. I'm adding this to the issues tracking.

[ThomThomson]

@ghudgins @jportner With the earlier conversation that we had, are we comfortable saying that there are two ways to use iframes:

1. A read only dashboard with embed=true in the url. In this mode the user is not expected to leave the dashboard, and is only expected to interact with view-mode actions.
2. A full Kibana experience in an iframe, where nothing is hidden or changed.

If that is the case, could we call this issue something in between that we aren't supporting quite yet and close it?

[jportner]

That's my understanding, yes. If @ghudgins agrees, then my follow-up question is: should we document this somewhere? I've had to answer several support questions about misuse of iframes in an "in between" way.

[ThomThomson]

Closing this as we are currently not supporting any in-between usage of Kibana iframes. Generally for the time being, embed codes are either used to view a dashboard in another website with none of the management or editing capabilities, or to access the entirety of Kibana from another website.