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

Expose environment ids? #643

Open
annevk opened this issue Mar 2, 2015 · 9 comments
Open

Expose environment ids? #643

annevk opened this issue Mar 2, 2015 · 9 comments
Milestone

Comments

@annevk
Copy link
Member

annevk commented Mar 2, 2015

Now that we have IDs to identify environments, perhaps environments should have access to them too? E.g. might be useful for sites that allow different session per open document.

Also, we should probably say that environment ids should be unique per origin, but should not be globally unique or something like that, so they can not really be used as additional entropy to identify the user.

@jakearchibald
Copy link
Contributor

Is this satisfied by client.id?

@annevk
Copy link
Member Author

annevk commented Nov 1, 2015

That doesn't give a client access to its own ID, does it?

@jakearchibald
Copy link
Contributor

I think we're going to try moving the clients API into all client types. Would clients.thisId or something similar solve this?

@annevk
Copy link
Member Author

annevk commented Mar 31, 2017

Each global has .clients I guess? Seems a little weird to put it there.

@wanderview
Copy link
Member

wanderview commented Mar 31, 2017

It would be nice we could provide an API to snapshot the current window as a full Client snapshot object.

What about something like:

let selfClient = new Client(window);

let frame = document.createElement(iframe);
document.body.appendChild(frame);

let FrameClient = new Client(frame.contentWindow);

Seems if you have synchronous access to a window global we could simply mint the full Client object immediately.

Edit: Worker could could do let workerClient = new Client(self);

@annevk
Copy link
Member Author

annevk commented Mar 31, 2017

No need to pass in the global then. You could just use the constructor from the correct global. Anyway, that seems reasonable.

@annevk
Copy link
Member Author

annevk commented Mar 31, 2017

Although, shouldn't it be asynchronous? Or is synchronous for the current global okay?

@wanderview
Copy link
Member

No need to pass in the global then. You could just use the constructor from the correct global.

I thought it might be nice to be able to specify a same-origin iframe global, etc. But sure. We could also have a snapshot method or something that returns a Client.

Although, shouldn't it be asynchronous? Or is synchronous for the current global okay?

I think synchronous from the current global should be ok. AFAIK all the values on client are available synchronously in other places. For example, document.visibilityState and document.hasFocus().

@annevk
Copy link
Member Author

annevk commented Mar 31, 2017

Yes, for the iframe case you can just do new self[0].Client().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants