Create iframe extension

[ellisonbg]

Right now the help-extension has the ability to open a URL in the dock panel. We should abstract this into a separate extension that offers:

• A command that allows any part of the app to have a URL opened in an iframed dockpanel widget.
• Register an alternate file handler for local .html files. This would provide a nice way for simple web development.

[bollwyvl]

Iframes are pretty awesome for making quick-and-dirty extensions where it may not be possible or worth it to try to make everything work together.

Indeed, having the "Open with Notebook Classic" be able to open an dockpanel iframe would be great, maybe even with some cross-talk between the two frames to notify on changes, command palette, etc.

In a couple toy extensions that wrap heavy-duty, opinionated applications, I have found that it's nice to have a toolbar/🍔 with stuff that, while usually available in the browser context menu, can still be hidden/destroyed/require developer knowledge:

• open in new tab
• reload
• poll and reload (with a cache breaker)
  • ...though watching all the contents is even better, but needs server 😝

Additionally, wrapping up the sandbox attribute is probably a good idea, with a sensible set of defaults:

export interface ISandbox {
  'allow-forms'?: boolean;
  'allow-modals'?: boolean;
  'orientation-lock'?: boolean;
  'allow-pointer-lock'?: boolean;
  'allow-popups'?: boolean;
  'allow-popups-to-escape-sandbox'?: boolean;
  'allow-presentation'?:  boolean;
  'allow-same-origin'?:  boolean;
  'allow-scripts'?:  boolean;
  'allow-top-navigation'?:  boolean;
}

export const DEFAULT_SANDBOX: ISandboxOptions = {
  'allow-forms': true,
  'allow-presentation': true,
  'allow-same-origin': true,
  'allow-scripts': true,
};

(though for the file:// case, allow-same-origin is a little freaky, but most stuff breaks without it)

Instrumenting the href is nice as well. It would be great if one could reliably grab favicons, but that doesn't seem to work reliably.

Also speaking of attributes, supporting srcdoc is nice, as some kinds of output just aren't going to play nice with lab/phosphor/other things.

I've ended up noticing some postMessage/addEventListener("message", ...) patterns that might be interesting to be able to tie into other things (command palette), though usually you've lost focus.

In addition, handling the dockpanel drag drop, even with the nasty CSS hack, is still pretty clutch.

Finally, mixed http/https stuff can create a headache... not sure the right way to handle that... in 2017, making your own cert, adding it to the system/browser chain, etc. is still a pain.

[mrocklin]

I'm somewhat interested in this, I think. I have a JLab server running within an HPC environment. I've ssh-tunneled a single port to get access to JLab and would like to piggy-back on this if possible to also look at other web servers visible within that HPC environment. In particular I'm interested in looking at Dask's diagnostic dashboard page (as a temporary fill in to making a proper extension of course :)).

I'm not sure where I should go to ask about this. This issue seemed like possibly the best place, but I'm quite happy to be redirected if this question is in the wrong place or generally foolish :)

[dhirschfeld]

Maybe this would also be useful for a docrepr extension?
i.e. generate the rich HTML output and serve in an iframe.

IIRC last time I tried it I had some issues with the formatting that an iframe might fix

[ellisonbg]

@mrocklin this is the right issue. Once we build an iframe extension, there would be a JupyterLab command to open an iframe pointing to a URL. However, that would assume that the other HTTP server was reachable by the frontend. In some HPC environments that isn't a given.

[fperez]

Just came here b/c I think this discussion is the right place also for my use case: I'm finding myself having to look at local HTML files in a remote server quite often. Interestingly, with classic, I can just click on them (as I just discovered a second ago), so that's a good fallback for now:

But in Lab, my options are either display(HTML(...)):

or display(IFrame(...)):

Neither is super-satisfying... Is there a (security?) reason why in Lab we don't want to display/view HTML directly as classic does?

cc @ian-r-rose @mpacer as per today's chat.

[canavandl]

I've created a rough Sandbox-ed IFrame extension here (canavandl/jupyterlab_sandbox#1) could probably be extended to minimally serve and load local HTML files.

I'm also not 100% clear of the security implications of such an extension either.

[bicycle1885]

What is blocking this issue? I really want this feature because we often view compiled HTML files of notebooks.

[fehiepsi]

@bicycle1885 I find a trick: from Help -> Launch classic notebook -> open your html file -> replace the link http://localhost:.../edit/....html by http://localhost:.../files/....html (replace edit by files). :)

[mflevine]

I made a lab extension for viewing HTML files in an IFrame in a new JupyterLab Tab (https://github.com/mflevine/jupyterlab_html). There are a couple bugs such as internal href links with open another JupyterLab in the IFrame instead of moving to the position in the file. Also the IFrame Tabs resist being dragged over and resized. But I am able to view the HTML files in the HPC environment I work on. If anyone has any ideas, they would be greatly appreciated.

[timkpaine]

@ellisonbg whoops, probably should've checked this issue first. I'm doing this, can probably easily combine with @mflevine's stuff as well

[timkpaine]

@ellisonbg @mrocklin this was my use case as well

[mflevine]

I have fixed the bugs I was experiencing and the extension now works as expected.

[dhirschfeld]

Currently, users have 3 options for iframe support:

• jupyterlab_iframe
• jupyterlab_html
• jupyterlab_sandbox

Since it seems to be a generally useful feature perhaps one of these could be officially blessed and moved to the jupyterlab org? In that way no-one is reinventing the wheel and development of new features and bug-fixes can be concentrated in the one repo.

[jasongrout]

Don't forget the very simple iframe widget that comes with jupyterlab itself! https://github.com/jupyterlab/jupyterlab/blob/e4e05e2a0969238baf8db4296436628e5cf783fd/packages/apputils/src/iframe.ts

Would you (or someone) compare these options and list what the differences, strengths and weaknesses are? Are they all addressing exactly the same problem?

[jasongrout]

(and I'm +1 on having an iframe widget in core jlab that lets you open arbitrary web pages or double-click on an html file)

[dhirschfeld]

I certainly don't have the js/ts chops to comment on the implementations but perhaps the authors themselves could pitch the relative strengths of their implementation?

[mflevine]

The extension I wrote (jupyterlab_html), is a mimerenderer for .html files. It does not open arbitrary web pages but allows double-clicking of the files in the file browser. As far as I know, the other two extension allow opening of web pages through the commands panel, but do not open files. I am very happy to have my extension merged with others to be included in the core!

[timkpaine]

Mine does no mimerendering, it just opens a page as a widget. Mine also has some python side stuff for "quick links". No problem with merging, but beware opening iframes is rife with annoyances (sites that won't allow it, http/s cross opening not allowed, etc)

[pavelvasev]

Hi everybody! Could you please give me an advice?

• I need to create my own command which may be typed in code input cell.
• The result of the command should be an iframe opened in output cell.
• That iframe should load some html page (from local or remote web server).
• The user should be able to interact with that webpage, and also open it in fullscreen.
• At the moment it is not considered to be run in separate docked panel.
• I need to interact with that page in terms of code interaction. It means, send some message from notebook to js in that page, and/or respond to requests from page js code to notebook.
• In particular I need to send a list of notebook variables names to that webpage, and send some variables values requested by webpage.

How may I do this?

[jasongrout]

General update: you can right-click on a file in the file manager and choose "Open in new browser tab" to get an html file to open in a new browser tab. This is like what happens in the classic notebook.

[jasongrout]

Setting as 1.0 for triage discussion next week.

[ian-r-rose]

#5855 adds live editing for local HTML files. For opening of arbitrary URLs in iframes I recommend checking out @timkpaine's jupyterlab_iframe.