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.

Sign up for GitHub

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

Jump to bottom

consider how clients.claim() should work with srcdoc iframes #1093

Open
wanderview opened this issue Mar 26, 2017 · 7 comments
Open

consider how clients.claim() should work with srcdoc iframes #1093

wanderview opened this issue Mar 26, 2017 · 7 comments
Labels
apr-2017-f2f-v1

Comments

@wanderview
Copy link
Member

Currently the spec says that srcdoc iframes should inherit their parent's controlling service worker. When a window client is controlled via clients.claim(), should we also claim any immediate child srcdoc iframes?
@jakearchibald
Copy link
Contributor

I think so. Does the srcdoc client inherit the client url from the parent? If so, it should just work.

@wanderview
Copy link
Member Author

I think so. Does the srcdoc client inherit the client url from the parent? If so, it should just work.

No. I think the srcdoc client.url should be 'about:blank'.

@jakearchibald jakearchibald mentioned this issue Mar 31, 2017
Closed
@jungkees
Copy link
Collaborator

jungkees commented Apr 2, 2017

I think it's 'about:srcdoc'. I agree 'clients.claim()' should also claim the child iframes that inherited the parent's controller.

@wanderview
Copy link
Member Author

Oh, so it is. A dynamically created iframe with no src or srcdoc has a URL of about:blank. In any case, the explicit inheritance needs to be spec'd here since the URL matching won't work.

@wanderview
Copy link
Member Author

Blob URL iframes may be an issue as well. And blob URL dedicated workers.

@jakearchibald
Copy link
Contributor

jakearchibald commented Apr 3, 2017 •
edited
Loading

@humphd
Copy link

humphd commented Apr 16, 2017

I wonder if I'm hitting this. I'm trying to rewrite https://thimble.mozilla.org to use SW for serving all user generated content. I currently do it with Blob URLs and rewriting of relative path URLs to Blob URLs, but it can't handle things like JS dynamically doing things.

Given a page running on http://localhost:8000/dist/hosted.html, and a SW running at http://localhost:8000/dist/sw.js. I've got various request/response pairs already placed in CacheStorage, for example http://localhost:8000/dist/vfs/image.png. I then create an HTML page, and a Blob URL for it:

<html>
    <head>
        <title>This will load in the iframe</title>
        <base href="http://localhost:8000/dist/vfs">
    </head>
    <body>
        <img src="http://localhost:8000/dist/vfs/image.png">
    </body>
</html>

I then add <iframe src="blob:http://localhost:8000/e843c3b9-5da7-4cbf-b782-ba3c6fafdbd9"> in the page running at http://localhost:8000/dist/hosted.html. My SW is set up to return anything it matches in the caches, and I can see that there is a cache entry for http://localhost:8000/dist/vfs/image.png.

When the iframe loads, I get 404s for http://localhost:8000/dist/vfs/image.png. However, if I just try to load that same URL in my address bar, it loads no problem.

At first I assumed it was something else I was doing, but I now suspect the fact that it's running in a page via the Blob URL. I had hoped that by it being a child iframe, and setting the <base> I might be able to inherit the parent's controller, too. Or perhaps there is some CORS issue I don't know about, and need in my cached headers?

I'm thinking I should abandon the Blob URL for the iframe as well, and also load that from cache; it was just surprising to me that this didn't work, and I wanted to investigate.

Thanks for any thoughts, even if only to tell me that I'm wrong.

@humphd humphd mentioned this issue Apr 16, 2017
Closed
@wanderview wanderview mentioned this issue Apr 26, 2017
Closed
@jakearchibald jakearchibald mentioned this issue Nov 3, 2017
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
apr-2017-f2f-v1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jakearchibald @humphd @wanderview @jungkees