| 16:29 | <annevk> | JakeA: btw, I finally figured out <embed> / <object> |
| 16:29 | <annevk> | JakeA: the way they work is that they have an internal fetch algorithm, which is sometimes used, and then sometimes they pass the response resulting from that to navigate |
| 16:29 | <annevk> | JakeA: apparently app cache had some weird model where that required loading it again rather than just using that response |
| 16:30 | <annevk> | JakeA: we should not copy that model |
| 16:30 | <JakeA> | annevk: we deliberately didnt |
| 16:30 | <annevk> | JakeA: right |
| 16:30 | <JakeA> | annevk: that's why we excluded embed/object |
| 16:30 | <annevk> | JakeA: but we can expose "onnavigate" perhaps at some point and hand that the response/request |
| 16:30 | <JakeA> | I think we can bring it back with typemustmatch btw |
| 16:31 | <annevk> | JakeA: even without I don't think there's a big problem |
| 16:31 | <annevk> | JakeA: as long as we acknowledge that if it uses a nested browsing context, it works like <iframe> |
| 16:31 | <JakeA> | annevk: but object isn't always a nested context is it? |
| 16:32 | <annevk> | JakeA: correct |
| 16:32 | <JakeA> | I thought that was why appcache jumped through hoops |
| 16:32 | <JakeA> | annevk: oh so you're saying we should always treat it as a client if SW is there? |
| 16:32 | <annevk> | JakeA: as I said, the <object data> algorithm might result in creation of a browsing context and navigation to a response (rather than a request) |
| 16:32 | <annevk> | JakeA: no, I'm saying we shouldn't try to work around the way it works |
| 16:33 | <annevk> | JakeA: there's already several others ways in which navigate can be invoked with a response rather than a request |
| 16:33 | <annevk> | JakeA: so not all navigations go through fetch, which is fine |
| 16:34 | <annevk> | JakeA: but AppCache didn't consider that to be fine I guess, which is why it had the hack |
| 16:34 | <JakeA> | annevk: interesting. We'll need to ensure a cross-origin object that becomes a navigation can't receive a response from a url other than its request url |
| 16:35 | <JakeA> | Maybe even a cached resource could be a security issue |
| 16:35 | <annevk> | JakeA: yeah, the main problem is where the response originates I guess |
| 16:36 | <annevk> | JakeA: kinda wish we had sorted out navigation before service workers, but I guess we can retrofit it all somehow |
| 16:45 | <annevk> | Saying that because I think it might be hard to add this now due to the concern you mention. Though maybe there's a way... Probably best to figure out first exactly how things work |