Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create iframe extension #2369

Closed
ellisonbg opened this issue Jun 6, 2017 · 22 comments · Fixed by #5855
Closed

Create iframe extension #2369

ellisonbg opened this issue Jun 6, 2017 · 22 comments · Fixed by #5855

Comments

@ellisonbg
Copy link
Contributor

@ellisonbg ellisonbg commented Jun 6, 2017

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
Copy link
Contributor

@bollwyvl bollwyvl commented Jun 6, 2017

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
Copy link
Member

@mrocklin mrocklin commented Aug 30, 2017

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
Copy link
Member

@dhirschfeld dhirschfeld commented Aug 30, 2017

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
Copy link
Contributor Author

@ellisonbg ellisonbg commented Sep 8, 2017

@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
Copy link
Contributor

@fperez fperez commented Jan 26, 2018

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:

image

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

image

or display(IFrame(...)):

image

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
Copy link

@canavandl canavandl commented Jan 26, 2018

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
Copy link

@bicycle1885 bicycle1885 commented Feb 21, 2018

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

@fehiepsi
Copy link

@fehiepsi fehiepsi commented Mar 1, 2018

@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
Copy link
Contributor

@mflevine mflevine commented Mar 13, 2018

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
Copy link
Member

@timkpaine timkpaine commented Mar 13, 2018

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

@timkpaine
Copy link
Member

@timkpaine timkpaine commented Mar 13, 2018

screen shot 2018-03-13 at 7 25 53 pm

@ellisonbg @mrocklin this was my use case as well

@mflevine
Copy link
Contributor

@mflevine mflevine commented Mar 27, 2018

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

@dhirschfeld
Copy link
Member

@dhirschfeld dhirschfeld commented Apr 13, 2018

Currently, users have 3 options for iframe support:

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
Copy link
Contributor

@jasongrout jasongrout commented Apr 13, 2018

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
Copy link
Contributor

@jasongrout jasongrout commented Apr 13, 2018

(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
Copy link
Member

@dhirschfeld dhirschfeld commented Apr 13, 2018

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
Copy link
Contributor

@mflevine mflevine commented Apr 13, 2018

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
Copy link
Member

@timkpaine timkpaine commented Apr 13, 2018

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
Copy link

@pavelvasev pavelvasev commented May 3, 2018

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 jasongrout removed this from the 1.0 milestone Sep 5, 2018
@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Sep 6, 2018

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 jasongrout added this to the 1.0 milestone Sep 6, 2018
@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Sep 6, 2018

Setting as 1.0 for triage discussion next week.

@ian-r-rose
Copy link
Member

@ian-r-rose ian-r-rose commented Jan 26, 2019

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

@lock lock bot locked as resolved and limited conversation to collaborators Aug 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.