| 02:10 | <bholley> | Hixie_: maybe we should IRC for a bit? |
| 02:10 | <bholley> | Hixie_: (though I understand if now isn't a good time) |
| 03:15 | <Hixie_> | hopefully i'll catch him tomorrow |
| 03:34 | <TabAtkins> | annevk: Why have *|* at all in there? It doesn't add anything. |
| 03:35 | <TabAtkins> | zewt: Yeah, the lack of good templating is the sole reason I still use PHP for most of my personal projects, which are usually just dead-simple CRUD applications. |
| 03:35 | <annevk> | TabAtkins: yes it does |
| 03:35 | <zewt> | i wrote a thing that pulled off inverted-templates with python once; it worked, but it was pretty unintuivie |
| 03:35 | <zewt> | ... unintuitive |
| 03:35 | <zewt> | (much like the qwerty keyboard layout) |
| 03:35 | <TabAtkins> | annevk: What does it do? |
| 03:36 | <annevk> | TabAtkins: it selects elements outside the default namespace |
| 03:36 | <TabAtkins> | Hm, I thought that an unspecified namespace would do that too. |
| 03:36 | <TabAtkins> | Does that mean that "rect" in an HTML document won't find my SVG <rect> elements? |
| 03:37 | <annevk> | TabAtkins: the CSS declares a default namespace and therefore I use *|* to get out of that |
| 03:37 | <annevk> | TabAtkins: CSS namespaces are not related to the document |
| 03:37 | <TabAtkins> | Oh, the UA sheet does. I see. |
| 03:37 | <TabAtkins> | Yeah, nm then. |
| 03:37 | <TabAtkins> | Anyway, that means you still need it in the just-a-::backdrop case, too. |
| 03:40 | <annevk> | I'm not sure what you mean |
| 03:40 | <TabAtkins> | You said: "I could also change *|*:fullscreen::backdrop to ::backdrop..." |
| 03:40 | <TabAtkins> | You'd have to change it to *|*::backdrop to maintain that "every namespace" feature. |
| 03:40 | <annevk> | Ah right |
| 03:41 | <TabAtkins> | anyway, home now. nn |
| 03:41 | <annevk> | Since it's only :fullscreen and :dialog that need, it won't be changed for now... Maybe once CSS defines its box model and stacking context better and moves this there... |
| 03:41 | <annevk> | TabAtkins: have a good one |
| 03:44 | <Hixie_> | do we have a blog.whatwg.org admin (that is, someone who can update the actual software, not just someone who has admin rights on the blog itself) around? |
| 03:45 | <Hixie_> | do we even know who that is? |
| 03:45 | <annevk> | Hixie_: I think that's Lachy, not sure |
| 03:45 | <Hixie_> | yeah, you might be right |
| 03:46 | <Hixie_> | anyone know what's up with him? |
| 03:46 | <annevk> | Hixie_: and maybe Ben Millard? I remember him doing some work on the markup |
| 03:47 | <annevk> | Hixie_: I think he's doing less standards these days and more coding, somewhere in Oslo |
| 03:48 | <Hixie_> | well if anyone wants to volunteer to take over blog admin work from lachy, let me know |
| 03:48 | <Hixie_> | probably need someone to do the wiki too, since aryeh has been gone for a while |
| 03:49 | <Hixie_> | it's not much ongoing work, just the occasional software upgrade so we don't get owned |
| 03:49 | <Hixie_> | oh wait, GPHemsley took over the wiki, didn't he |
| 03:49 | <Hixie_> | zcorpan: are you doing the forums? |
| 05:27 | <TabAtkins> | Oh man, caught the "but preventing people from *choosing* to use DRM is anti-Open Web" in one. |
| 07:11 | <zcorpan> | Hixie_: Xdega updated the forums last time. it's not up to date now it seems. i'll ask if he can update it again |
| 08:20 | <ondras> | Domenic_: hi, you around? |
| 09:45 | <zcorpan> | MikeSmith: yt? csswg hg is timing out |
| 10:09 | <MikeSmith> | zcorpan: working on it |
| 10:10 | <MikeSmith> | but it seems the systems team may have cut me off from root on that hosta |
| 10:10 | <MikeSmith> | the fix for the hg problem is just for the apache server on that host to be restarted |
| 10:11 | <MikeSmith> | actually the fix for it is really for the CSS WG to pull its head out of its ass and move everything to github instead |
| 10:12 | <Ms2ger> | Ehehehehe |
| 11:46 | <GPHemsley> | Hixie_: Yes. Yes, I did. :P |
| 11:49 | GPHemsley | seconds hallvors1's praise for PHP's docs |
| 11:49 | GPHemsley | wishes Python's docs were as good |
| 11:51 | <MikeSmith> | zcorpan: csswg hg should be working again |
| 11:52 | <zcorpan> | MikeSmith: thanks! |
| 11:52 | <MikeSmith> | thanks for the heads-up |
| 11:55 | <zcorpan> | MikeSmith: new problem: hg push gives abort: HTTP Error 500: Internal Server Error |
| 11:55 | <zcorpan> | should i just try again? |
| 11:56 | <zcorpan> | hmm, but my changes seem to have gone through. https://dvcs.w3.org/hg/csswg |
| 11:57 | <zcorpan> | so i guess it's fine |
| 12:03 | <MikeSmith> | zcorpan: I just now re-restarted apache there. Not sure if it had actually be restarted when the previous problem was fixed. But it should be 100% back to normal now. |
| 12:03 | <zcorpan> | ok |
| 12:14 | <MikeSmith> | zcorpan: btw about the 00N.isvalid.html and 00N.novalid.html naming conventions, I've figured it was worth trying out as a way to use the filename to easily store the metadata about the core way the test document are distinguished from each other |
| 12:14 | <MikeSmith> | and to tell a test runner what to expect when checking the document |
| 12:15 | <MikeSmith> | I've also added some documents with 00N.haswarn.html names to indicate they should only generate warnings |
| 12:16 | <MikeSmith> | which is another case that's useful to distinguish separately for errors -- at least as far as testing validator.nu goes |
| 12:16 | <MikeSmith> | I don't expect that the names are going to change very often |
| 12:17 | <MikeSmith> | oh and of course it means the cases can be distinguished without needing to have a manifest |
| 12:18 | <MikeSmith> | but anyway I have since implemented support in the validator.nu test runner for checking what specific message the validator is expected to report when it checks the document |
| 12:18 | <MikeSmith> | if any |
| 12:18 | <MikeSmith> | and that kind of obviates the need for the naming convention a bit |
| 12:19 | <MikeSmith> | but I'd still like to keep that naming convention for now, because I think it could be useful to anybody else who might be making another conformance checker and wanting to test it |
| 12:20 | <zcorpan> | ok |
| 12:55 | <ondras> | Domenic_: you around? |
| 13:07 | <jgraham> | annevk: So, there are unclear things in URL |
| 13:08 | <annevk> | jgraham: no doubt |
| 13:08 | <jgraham> | When you are parsing a URL, in several places it says "terminate this algorithm". But it's not really clear if that means the overall algorithm and, if so, whether anything is returned |
| 13:08 | <jgraham> | And if not, what you are supposed to do next |
| 13:09 | <jgraham> | Also, it talks about a pointer into input that can't go past the end of input, but then also talks about a nominal EOF character |
| 13:09 | <jgraham> | It's not really clear if the EOF concept is needed |
| 13:11 | <annevk> | jgraham: the parser doesn't have to return anything when state override is given |
| 13:12 | <jgraham> | So it can return Nothing | Error | ParsedURL ? |
| 13:13 | <annevk> | jgraham: yeah, it either attempts to modify a URL or attempts to construct a new one |
| 13:14 | <jgraham> | So I think it would be easier to follow if that was explicit |
| 13:14 | <annevk> | The EOF-handling might be buggy... |
| 13:16 | <jgraham> | So I think at the moment, if the pointer reaches the end of the input you break out of the loop. |
| 13:16 | <jgraham> | So the EOF case can only happen if the pointer is incremented somewhere other than at the end of the loop |
| 13:17 | <annevk> | Yeah that seems wrong... |
| 13:18 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23351 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23352 |
| 13:18 | <jgraham> | Thanks |
| 13:21 | jgraham | ended up in a testharness.js-in-servo rabbithole that bottomed out with implementing URL |
| 13:41 | <MikeSmith> | jgraham: should I use the "Prepare Rebase" button in Critic, or should I just manually rebase onto master from my fork |
| 13:41 | <MikeSmith> | or how do I rebase onto master in Critic? |
| 13:41 | <jgraham> | MikeSmith: "Prepare Rebase" doesn't really work for tracked branches and should probably be hidden |
| 13:42 | <jgraham> | MikeSmith: You want to do the rebase and then use "Rebase Review" |
| 13:42 | <jgraham> | (near the top) |
| 13:43 | <jgraham> | MikeSmith: Which review, so I can help you out if there's a problem? |
| 13:43 | <MikeSmith> | jgraham: https://critic.hoppipolla.co.uk/r/310 |
| 13:43 | <jgraham> | OK, so rebase onto master locally |
| 13:44 | <jgraham> | Push the rebase to github |
| 13:44 | <jgraham> | and click "rebase review" in critic |
| 13:44 | <jgraham> | One day I will get around to automating this |
| 13:44 | <jgraham> | Since I *think* GH sends enough information to work out that a rebase occurred |
| 14:00 | <annevk> | jgraham: yay for implementing URL |
| 14:01 | <Domenic_> | ondras: what's up |
| 14:05 | <jgraham> | annevk: Well let's see hoe far I get |
| 14:06 | <jgraham> | I need to read the borrowed pointer tutorial so that I don't always end up with the compiler saying "error: cannot move out of dereference of & pointer" |
| 14:10 | <Ms2ger> | jgraham, heh, that's a nice rabbithole |
| 14:14 | <MikeSmith> | jgraham: so does https://critic.hoppipolla.co.uk/r/310 look OK now for me to do Rebase Review? |
| 14:14 | <MikeSmith> | what does Update Now do? |
| 14:17 | <jgraham> | Update Now just tries to pull the latest code |
| 14:17 | <jgraham> | So yeah, just try Rebase Review |
| 14:20 | <MikeSmith> | ok done |
| 14:21 | <MikeSmith> | So I can do Close Review? and will that actually push the change? |
| 14:21 | <Ms2ger> | MikeSmith, no |
| 14:22 | <Ms2ger> | MikeSmith, you manually merge, then close |
| 14:22 | <MikeSmith> | ah OK |
| 14:22 | <jgraham> | Closing should happen automatically if you merge |
| 14:22 | <jgraham> | But I agree we need a "Merge PR" button on critic |
| 14:23 | <Ms2ger> | jgraham, should as in "is expected to" or as in "feature request"? |
| 14:23 | <MikeSmith> | hmm I got an e-mail message saying "The automatic update of the branch... failed and has been disabled. Manual intervention is required to resume the automatic updating." |
| 14:23 | <MikeSmith> | so I musta muffed up something |
| 14:24 | <MikeSmith> | "Rejecting non-fast-forward update of review branch." |
| 14:24 | <jgraham> | MikeSmith: In this case I wouldn't worry much about it |
| 14:24 | <jgraham> | Since you are about to merge anyway |
| 14:25 | <MikeSmith> | ok |
| 14:25 | <jgraham> | Ms2ger: "should" as in "is expected to" in this case |
| 14:25 | <jgraham> | I fixed it yesterday, I think |
| 14:26 | <Ms2ger> | Ah |
| 14:26 | <Ms2ger> | Review one of my patches so I can test? :) |
| 14:26 | <jgraham> | Heh |
| 14:26 | <jgraham> | Well MikeSmith's review got closed |
| 14:27 | <jgraham> | (also the rebase worked for me) |
| 14:27 | <MikeSmith> | I just closed it manually |
| 14:27 | <jgraham> | Oh |
| 14:27 | <jgraham> | Well that's no fun |
| 14:27 | <MikeSmith> | heh |
| 14:28 | <MikeSmith> | should I have kept it open for some reason? |
| 14:28 | <jgraham> | MikeSmith: No, but it should close itself |
| 14:28 | <jgraham> | Ms2ger: From the logs |
| 14:28 | <jgraham> | [Tue Sep 24 16:17:59 2013] [error] Review <dbutils.review.Review object at 0xa8a565ec>, user User(2, 'Ms2ger', 'Ms2ger⊙gc', 'Ms2ger') |
| 14:28 | <jgraham> | [Tue Sep 24 16:17:59 2013] [error] Review accepted, closing |
| 14:28 | <jgraham> | [Tue Sep 24 16:17:59 2013] [error] Disabling tracking |
| 14:29 | <jgraham> | (ignore the [error] part) |
| 14:29 | <Ms2ger> | [err... Ah |
| 14:29 | <jgraham> | So it looks like it worked for one of your reviews at least |
| 14:35 | Ms2ger | wonders if anyone is fixing comments on https://critic.hoppipolla.co.uk/r/74 |
| 14:47 | <gsnedders> | Ms2ger: Did you see what I said in logs to you? |
| 14:48 | <Ms2ger> | Yeah, I'll look at that docs thing |
| 14:49 | <gsnedders> | It is like literally the same as the wiki page. :P |
| 16:15 | <ondras> | Domenic_: so, I am here now. You too? :-) |
| 16:34 | Ms2ger | finds "SUCCESS: did not release a single REC or PR between '98 and '08" |
| 16:40 | <jgraham> | CSS? |
| 16:40 | <Ms2ger> | Yep |
| 16:45 | <Domenic_> | ondras: well, now i am |
| 16:46 | <ondras> | Domenic_: cool. first of all, thanks for your nice talk at jsconf.eu! |
| 16:46 | <Domenic_> | :) |
| 16:47 | <ondras> | Domenic_: second, I wanted to ask another question about Promises - specifically, about the value Promise is resolved with |
| 16:47 | <ondras> | Domenic_: is there some reason Promises are designed with only *one* fulfillment/rejection value? When compared to a callback function that can typically accept multiple arguments... |
| 16:48 | <ondras> | (which is, of course, domain-specific) |
| 16:48 | <Domenic_> | ondras: because they parallel synchronous functions, which can only return one return value or throw one exception. |
| 16:48 | <ondras> | yeah, I thought so. |
| 16:48 | <Domenic_> | this allows powerful things like task.js http://taskjs.org/ |
| 16:49 | <ondras> | well, I am in a process of rewriting a callback-based code into a promise-based impl of XHR |
| 16:49 | <ondras> | not sure what the fullfillment value shall be |
| 16:49 | <ondras> | originally, the signature was callback(data, status, headers) or so |
| 16:49 | <ondras> | I guess the common approach is to wrap it into an object, right? |
| 16:50 | <ondras> | because non-200 http status shall not imply promise rejection? |
| 16:50 | <ondras> | *fulfillment, probably. please excuse my poor english. |
| 16:52 | <Domenic_> | yeah, object seems reasonable. it depends on the API IMO whether non-2xx/3xx status implies rejection |
| 16:52 | <Domenic_> | just think how you would write the function if you were in a language where I/O was normally synchronous :) |
| 16:57 | <ondras> | Domenic_: okay, thanks |
| 18:09 | <joelcox> | I wrote a use case for allowing HTML documents to bind to multimedia buttons a week ago. Annevk recommended me to send to www-dom⊙wo, but I've yet to see any response. |
| 18:09 | <joelcox> | Are there other ways I should pursue to get more eyeballs on this, or assume people are not interested? |
| 18:10 | <Ms2ger> | Patience :) |
| 18:10 | <Domenic_> | the problem is getting implementers interested... |
| 18:11 | <joelcox> | Ms2ger: thanks, I'm just curious about the w3 way of doing things, WHATWG has a nice set by step process |
| 18:12 | <Domenic_> | Oh, I don't think the w3.org means W3C... it's just where the mailing list is hosted. |
| 18:13 | <Ms2ger> | Well, multimedia buttons sounds like D3E |
| 18:13 | <joelcox> | Domenic_: oh, my bad.. |
| 18:13 | <joelcox> | Ms2ger: that's how I tagged it in the subject :) |
| 18:13 | <joelcox> | Ms2ger: if that's an abbreviation for Dom Level 3 events |
| 18:14 | <Ms2ger> | yep |
| 18:14 | <Domenic_> | most of the people doing actual work are in whatwg, but they just use the w3c mailing lists because they don't want to host their own mail servers... |
| 18:15 | <joelcox> | thanks for the clarification Domenic_ |
| 18:19 | <Domenic_> | fwiw i think your email lays out a great missing feature of the web and agree it should be addressed... the problem is now finding more people with real power, i.e. implementers or maybe certain spec writers, that also care. |
| 18:21 | <joelcox> | Domenic_: Cool, I guess I'll start knocking on some doors |
| 18:28 | <joelcox> | Hmm, maybe I should look into how FirefoxOS handles this |
| 18:30 | <Hixie_> | Domenic_: if we need mailing lists, we can add some easily enough, but generally i'd recommend we stick to just whatwg⊙wo |
| 18:30 | <Hixie_> | the way the w3c has a zillion lists causes nothing but troubles |
| 18:31 | <Hixie_> | bholley: here now |
| 18:48 | <joelcox> | Hixie_: I scrolled through their list of mailing lists the other day, trying to find www-dom. Never doing that again :) |
| 19:20 | <Hixie_> | joelcox: you are aware of "find in page", right? :-) |
| 19:22 | <joelcox> | Hixie_: of course, I was just curious about the lists they had and how long the list of lists was |
| 19:22 | <Hixie_> | hehe |
| 19:22 | <joelcox> | spoiler alert: long |
| 19:22 | <Hixie_> | most of those lists are dead |
| 19:22 | <Hixie_> | but there's no real way to know |
| 19:22 | <Hixie_> | also, there's three lists |
| 19:23 | <Hixie_> | that's just one of them |
| 19:23 | <joelcox> | yeah, and some are prefixed with public-, some are not |
| 19:23 | <Hixie_> | at some point, for reasons i don't understand, they changed from "www-" and "w3c-" and "w3t-" prefixes to "public-", "member-", and "team-" prefixes. |
| 19:23 | <joelcox> | (btw, thanks for your work on the web!) |
| 19:24 | <joelcox> | Didn't they write a spec for that? |
| 19:24 | <joelcox> | Sorry, couldn't resist :) |
| 19:28 | <Hixie_> | oh, bummer. |
| 19:28 | <Hixie_> | the following statement is now a lie: "Since all these browsing contexts by definition share an event loop, there is always a well-defined sequential order in which their session histories had their entries added." |
| 19:28 | <Ms2ger> | Eh, well-defined |
| 19:29 | <Hixie_> | they don't share an event loop. |
| 19:31 | <Hixie_> | i wonder how we fix this |
| 19:31 | <Hixie_> | i guess we post a message to a master event loop |
| 19:34 | <Hixie_> | abarth: help |
| 19:35 | <Hixie_> | abarth: window.history.length in a multi-process world |
| 19:35 | <Hixie_> | abarth: do we just return our best guess? |
| 20:50 | <bholley> | Hixie_: I've got an hour before my flight boards if you want to talk |
| 20:50 | <Hixie_> | sure |
| 20:51 | <bholley> | \o/ |
| 20:51 | <bholley> | Hixie_: so, let's start with prototypes |
| 20:51 | <bholley> | Hixie_: everyone agrees that each origin should get its own view of xowin.location |
| 20:51 | <bholley> | Hixie_: so that part's settled |
| 20:52 | <Hixie_> | "view"? |
| 20:52 | <bholley> | Hixie_: I'm just trying to be general |
| 20:52 | <Hixie_> | k |
| 20:52 | <bholley> | Hixie_: in webkit, you get a separate object |
| 20:52 | <bholley> | Hixie_: in Gecko, you get an Xray wrapper |
| 20:52 | <bholley> | Hixie_: but it's indistinguishable from script |
| 20:53 | <bholley> | Hixie_: you and I both agree that a single origin should see a consistent value for Object.getPrototype(xowin.location), even if scripts from two same-origin globals are inspecting the same location |
| 20:53 | <bholley> | Hixie_: the above rules out (2) |
| 20:53 | <bholley> | Hixie_: and IIUC neither of us wants it to depend on whichever script touches the object first |
| 20:53 | <bholley> | Hixie_: which rules out (1) |
| 20:54 | <Hixie_> | yeah that wouldn't make sense at all |
| 20:54 | <bholley> | Hixie_: right. So we're left with (3) and (4) |
| 20:54 | <bholley> | Hixie_: (3) being a unique prototype to go along with the unique location object |
| 20:54 | <bholley> | Hixie_: (4) being null or undefined or throw or somesuch |
| 20:55 | <bholley> | Hixie_: (3) is roughly what Gecko does, (4) is what everyone else does |
| 20:55 | <Hixie_> | 4 would be fine by me |
| 20:55 | <Hixie_> | i think if we don't do 4 then we want something like: |
| 20:56 | <Hixie_> | (5) each origin-Location pair gets a unique prototype object for that Location object |
| 20:56 | <Hixie_> | just like each origin-Location pair gets a unique Location object for that Location object, essentially |
| 20:56 | <bholley> | Hixie_: isn't that (3)? |
| 20:57 | <Hixie_> | if it is, then that sounds fine to me too. your description of (3) confused me a bit. |
| 20:57 | <Hixie_> | (5) is what i think the spec says today, though apparently not clearly enough |
| 20:57 | <bholley> | Hixie_: ok, that's fine with me. The only issue is whether the prototype does security checks, and what that all looks like |
| 20:57 | <Hixie_> | what security checks would it do? |
| 20:58 | <bholley> | Hixie_: any range of things. In Gecko today, for example, the prototype is an opaque object that throws if you try to do anything to it |
| 20:58 | <bholley> | Hixie_: though I consider that a bug |
| 20:58 | <Hixie_> | seems to me like it should just be a regular prototype object as defined in WebIDL? |
| 20:59 | <bholley> | Hixie_: that's the direction I'd like to move (or rather, making our Xray Wrappers behave that way) |
| 20:59 | <bholley> | Hixie_: what about polyfill methods on the prototype? |
| 20:59 | <bholley> | Hixie_: should those have any effect? |
| 21:00 | <bholley> | Hixie_: I'm assuming so, just checking |
| 21:00 | <Hixie_> | cross-origin? you can't add any, and you don't see the original origin's. |
| 21:01 | <bholley> | Hixie_: so the Location object isn't a totally normal WebIDL prototype then |
| 21:01 | <bholley> | Hixie_: er, the prototype of xo location objects |
| 21:01 | <bholley> | Hixie_: because you're suggesting that we perform some sort of security check when I try to monkeypatch Object.getPrototypeOf(xowin.location) |
| 21:02 | <Hixie_> | true. that's what the part of the spec says currently says "the user agent must act as if any changes to that Location object's properties, getters, setters, etc, were not present, and as if all the properties of that Location object had their [[Enumerable]] attribute set to false" is trying to say |
| 21:02 | <Hixie_> | i think that was added for bz |
| 21:03 | <Hixie_> | personally i like being able to monkey-patch them, if it's only visible same-origin |
| 21:03 | <Hixie_> | (then again, personally i think we shouldn't expose this cross-origin at all, but that ship has sailed.) |
| 21:03 | <bholley> | Hixie_: monkey-patching them introduces a fair amount of implementation complexity. I'm open to it because it's a feature I want in our platform anyway, but we should tread carefully here |
| 21:04 | <Hixie_> | at the point where you have origin-unique prototypes, isn't it easier to do monkey-patching than not? |
| 21:04 | <Hixie_> | (the other thing to consider is what happens when your effective origin changes but you already have a reference to the cross-origin Location object.) |
| 21:05 | <bholley> | Hixie_: not in Gecko, no. Because the our origin-unique prototypes are actually XrayWrappers. Currently those XrayWrappers forward directly to the underlying DOM object, so we'd need some sort of mechanism to say "check the Xray prototype chain" |
| 21:05 | <Hixie_> | right, but that's because they're not "real" prototypes |
| 21:06 | <bholley> | Hixie_: sure. And they never will be |
| 21:06 | <Hixie_> | oh |
| 21:06 | <Hixie_> | why? |
| 21:06 | <Hixie_> | if that's what we're trying to fake, why not just do it? |
| 21:06 | <bholley> | Hixie_: because it would require re-designing our engine to do what webkit does |
| 21:07 | <Hixie_> | you'd rather they redesigned their engine to do what you do? :-) |
| 21:07 | <bholley> | Hixie_: no. I'm saying that we should spec something that we can both implement easily |
| 21:07 | <bholley> | Hixie_: which is why I want the spec to be implementable with either XrayWrappers or Webkit-style separate worlds |
| 21:08 | <bholley> | Hixie_: I'm just saying that's why we're not going to "just do it" |
| 21:09 | <Hixie_> | ah, ok, if the additional constraint is "implementable with either XrayWrappers or Webkit-style separate worlds", then what would be best for authors kinda goes out of the window |
| 21:09 | <Hixie_> | what is implementable by both? |
| 21:10 | <bholley> | Hixie_: I mean, authors are a consideration too. But it doesn't serve authors to spec something Gecko-like that webkit won't implement and vice-versa |
| 21:11 | <bholley> | Hixie_: especially when it comes to edge cases like this that nobody (currently) relies on anyway |
| 21:11 | <Hixie_> | sure |
| 21:11 | <Hixie_> | i just wasn't considering that constraint before |
| 21:12 | <Hixie_> | i don't know what options we have, with that constraint (i don't mean i don't think we have any, i mean literally, i don't know what they are) |
| 21:12 | <bholley> | Hixie_: so, in terms of prototypes, we could implement either (3) or (4) |
| 21:12 | <bholley> | Hixie_: so the first step is to check with abarth and see if he's willing to do something other than (4) |
| 21:12 | <bholley> | Hixie_: if we decide to do something along the lines of (3) |
| 21:12 | <Hixie_> | where (3) is (5) with teh additional restriction that you can't touch it, right? |
| 21:13 | <Hixie_> | as in, can't mutate it. unless you're the "original" owner |
| 21:13 | <bholley> | Hixie_: no. I'm considering (3) and (5) the same at this point |
| 21:13 | <Hixie_> | the one whose origin matches the document for which Location was created |
| 21:13 | <bholley> | Hixie_: _if_ we go that option, then we need to figure out the details |
| 21:13 | <bholley> | Hixie_: the details including "whether you can monkeypatch" |
| 21:14 | <bholley> | Hixie_: what works best for that depends largely on how each implementation implements its security checks on |location| |
| 21:14 | <Hixie_> | let's assume we pick 3, for the sake of this conversation: you'd rather we didn't allow the object or its prototype(s) to be mutatable at all by origins that aren't the origin of the Document for which the Location exists, right? |
| 21:15 | <bholley> | Hixie_: correct |
| 21:15 | <bholley> | Hixie_: but I'm open to doing it differently |
| 21:15 | <bholley> | Hixie_: just note that it adds complexity, and there might be snakes in the grass that make it harder than I'm predicting |
| 21:16 | <Hixie_> | the less complexity we add, the happier i am |
| 21:16 | <Hixie_> | so, as far as i can tell, the spec right now describes exactly what we're saying here. just not very well. |
| 21:17 | <bholley> | Hixie_: ok, great |
| 21:17 | <bholley> | Hixie_: so if that's settled, we can get back to the original issue of security checks on location. Are you ready to discuss that? |
| 21:17 | <Hixie_> | as ready as i'll ever be |
| 21:18 | <bholley> | Hixie_: ok, so |
| 21:19 | <bholley> | Hixie_: my reasoning was in comment 34 and comment 36, until comment 37 took us on the prototype chain digression |
| 21:20 | <bholley> | Hixie_: I can resummarize here if you want - not sure if you prefer depth or brevity |
| 21:21 | <Hixie_> | bholley: i'm agnostic on depth vs brevity, it's just an area i find incredibly hard to wrap my head around. |
| 21:21 | <Hixie_> | bholley: (so, sorry if i'm being so slow in general with this) |
| 21:22 | <bholley> | Hixie_: don't worry about it - I spend all day on this, and you have to deal with the whole web :-) |
| 21:23 | <Hixie_> | ok, just reread 34 and 36 |
| 21:23 | <bholley> | Hixie_: so, we've got 2 origins of interest (bc origin and doc origin), and 2 places security checks can be performed (ES-level property access, and method invocation) |
| 21:23 | <Hixie_> | my response now, as then, was 35 and 37. ;-) |
| 21:23 | <bholley> | Hixie_: lol |
| 21:23 | <Hixie_> | we have at least 2 origins of interest, maybe more |
| 21:24 | <Hixie_> | we have several places security checks can be performed, i agree those are two of them |
| 21:26 | <Hixie_> | (on a side note, if anyone has a recent IE, can you tell me what it does with http://www.hixie.ch/tests/adhoc/dom/level0/history/cross-origin/001.html ? thanks) |
| 21:27 | <Hixie_> | bholley: (i have to bail in about 15 minutes) |
| 21:27 | <bholley> | Hixie_: great, me too |
| 21:27 | <bholley> | Hixie_: so, do we agree about the method-call checks against bc origin? |
| 21:28 | <bholley> | (that they are necessary) |
| 21:29 | <Hixie_> | hmm |
| 21:30 | <Hixie_> | yes, because we don't want to be able to use our location object's methods on thir location object and thus bypass the property get check |
| 21:30 | <Hixie_> | (that's bug 22346) |
| 21:31 | <Hixie_> | (except for location.replace(), which we always want to allow) |
| 21:31 | <bholley> | Hixie_: right |
| 21:31 | <Hixie_> | (well, except in the additional case we want to disallow, bullet 4 in comment 32) |
| 21:32 | <bholley> | Hixie_: ok, great |
| 21:32 | <Hixie_> | (the fact that this discussion involves terms like "the Location object's associated Document's browsing context's active document's effective script origin" is not helping my sanity score) |
| 21:33 | <bholley> | Hixie_: hey, you designed this stuff :-) |
| 21:33 | <Hixie_> | "designed" |
| 21:33 | <bholley> | Hixie_: so. I argue that we need an additional mechanism to prevent multiple third-party origins from seeing each others expandos on a given location object |
| 21:33 | <Hixie_> | (this job has far more in common with my physics background than it has any right to have) |
| 21:34 | <Hixie_> | bholley: right, but if we just disallow "expandos", that is, setting properties, that's a non-issue, right? |
| 21:34 | <Hixie_> | setting properties cross-origin |
| 21:34 | <bholley> | Hixie_: but we can't disallow expandos. The web depends on it |
| 21:34 | <ebollens> | (but physics teaches entropy only increases) |
| 21:34 | <bholley> | Hixie_: the web depends on script being able to set expandos on the Location object associated with its Document |
| 21:34 | <Hixie_> | bholley: it doesn't depend on it for cross-origin Location object access, does it? |
| 21:34 | <Hixie_> | sure, on your own is fine |
| 21:34 | <bholley> | Hixie_: it depends how we define "cross-origin" |
| 21:34 | <bholley> | Hixie_: that's the whole issue here |
| 21:35 | <Hixie_> | (by "expando" you just mean a non-IDL-defined property, right?) |
| 21:35 | <bholley> | Hixie_: yes |
| 21:35 | <bholley> | Hixie_: sorry for the Geckoism |
| 21:35 | <Hixie_> | i think it's actually an IEism originally :-) |
| 21:35 | <Hixie_> | just making sure |
| 21:35 | <bholley> | Hixie_: so, I totally agree with what you're saying, assuming "cross-origin" in this case is defined in terms of the Document origin, not the BC origin |
| 21:36 | <bholley> | Hixie_: which is what I'm advocating for in this bug |
| 21:36 | <Hixie_> | browsing contexts don't have origins |
| 21:36 | <bholley> | Hixie_: I know. But I'm using the shorthand I proposed |
| 21:36 | <bholley> | Hixie_: BC origin = "the origin associated with the document whose window is the active window in the browsing context" |
| 21:36 | <Hixie_> | by "cross-origin" i mean that a script whose effective origin is different than the Location object's associated Document's effective script origin |
| 21:37 | <bholley> | Hixie_: great |
| 21:37 | <bholley> | Hixie_: that's how I think of it too |
| 21:37 | <bholley> | Hixie_: which is what I'm pushing for here |
| 21:37 | <Hixie_> | wait. i don't think the origin of the active document of the browsing context of the Document of the Location object is relevant here. |
| 21:37 | <Hixie_> | what i said was different than what you said. |
| 21:37 | <bholley> | :-) |
| 21:38 | <bholley> | Hixie_: so, 10 minutes ago, we agreed that we need to do a security check against bc origin at method call time |
| 21:38 | <bholley> | Hixie_: right? |
| 21:38 | <bholley> | Hixie_: that's how I'm defining bc origin |
| 21:39 | <Ms2ger> | r? https://critic.hoppipolla.co.uk/r/208 |
| 21:39 | <Hixie_> | oh i assumed you mean the origin of the calling script |
| 21:39 | <Hixie_> | the Location object's "native origin" is the origin of the Document with which it's associated, right? |
| 21:40 | <Hixie_> | that's the one that should be allowed to extend the Location object |
| 21:40 | <bholley> | Hixie_: sure. "native origin" is a good term |
| 21:40 | <bholley> | Hixie_: yes |
| 21:40 | <Hixie_> | if that document's browsing context's active document happens to get hold of the Location object of an earlier document, it shouldn't see those extensions, and shouldn't be able to add any itself. |
| 21:40 | <Hixie_> | it has its own Location object to mess with. |
| 21:41 | <bholley> | Hixie_: righto |
| 21:41 | <Hixie_> | (it has its own family of Location objects) |
| 21:41 | <Hixie_> | (one for each origin) |
| 21:41 | <Hixie_> | (but we'll pretend they're one for now) |
| 21:41 | <Hixie_> | (or i guess, it has one Location object with a family of prototypes) |
| 21:41 | <Hixie_> | (or some crazy thing. what we discussed before.) |
| 21:42 | <bholley> | (I think there was only one prototype in what we discussed before. but whatever. let's finish this thing here) |
| 21:42 | <bholley> | Hixie_: hence, my proposal is that property-access checks use the "native origin" |
| 21:43 | <Hixie_> | ok, i agree with that. it's not the "bc origin", though. |
| 21:43 | <bholley> | Hixie_: agreed. I didn't mean to imply otherwise |
| 21:43 | <Hixie_> | (that is, it might not be the origin of any of the active documents) |
| 21:43 | <bholley> | Hixie_: sure |
| 21:43 | <Hixie_> | ok so i'm confusd by "we need to do a security check against bc origin" then |
| 21:44 | <Hixie_> | during method calls |
| 21:44 | <Hixie_> | why would method call checks use something different than the property checks? |
| 21:44 | <bholley> | Hixie_: because of what you said: "Hixie_: yes, because we don't want to be able to use our location object's methods on thir location object and thus bypass the property get check" |
| 21:44 | <bholley> | Hixie_: or maybe I didn't fully understand you |
| 21:45 | <bholley> | Hixie_: but let's step back |
| 21:45 | <bholley> | Hixie_: the reason for the bc method-call checks |
| 21:45 | <Hixie_> | we don't want a script in origin B to call a method on a Location object whose native origin is A using the method from one of B's Location objects |
| 21:46 | <bholley> | Hixie_: ok, that's a different issue. Sorry |
| 21:46 | <bholley> | Hixie_: the reason for the bc method-calls checks |
| 21:46 | <bholley> | Hixie_: is that, per-spec, the Location object describes the URL of the active document in the BC |
| 21:47 | <bholley> | Hixie_: which means that, if evil.com navigates itself to bank.com, evil.com's window.location describes the URL of bank.com's document |
| 21:48 | <Hixie_> | sure, so the _properties_ need to do a check against the active document |
| 21:48 | <Hixie_> | but you said the methods |
| 21:48 | <bholley> | Hixie_: are you making a distinction between .toString() and .href? |
| 21:48 | <bholley> | Hixie_: I'm using 'method' to refer to 'methods, getters, and setters' |
| 21:49 | <Hixie_> | oh, well, that's confusing :-) |
| 21:49 | <Hixie_> | i'd actually forgotten about toString() |
| 21:49 | <Hixie_> | but in any case, looks like comment 32 agrees with you |
| 21:49 | <bholley> | Hixie_: I'm trying to distinguish between ES-level property access - Object.getOwnPropertyDescriptor() |
| 21:50 | <bholley> | Hixie_: and DOM-level code, which is what happens when you invoke methods or getters or setters |
| 21:51 | <Hixie_> | oh, ok. that wasn't clear. |
| 21:51 | <bholley> | Hixie_: my apologies |
| 21:51 | <Hixie_> | why do we need to do any checks at the property descriptor level? |
| 21:51 | <bholley> | Hixie_: because of the expando thing |
| 21:51 | <Hixie_> | if all Location objects pretend to be virgin objects cross-origin, you can't get anthing interesting that way |
| 21:52 | <Hixie_> | i have to bail again, sorry. let me know when you're back on the ground and we can continue this? |
| 21:52 | <bholley> | Hixie_: yeah, sounds good. Note that I'll be in France |
| 21:52 | <Hixie_> | k |
| 21:52 | <bholley> | Hixie_: but some evening-for-me-morning-for-you we can get back to this |
| 21:52 | <bholley> | Hixie_: and thanks for taking the time here |
| 21:52 | <Hixie_> | keep pinging me, my schedule is all out of wack these days |
| 21:53 | <Hixie_> | thank _you_ for putting up with my difficultis :-) |
| 21:53 | <Hixie_> | we'll figure it out |
| 21:53 | <Hixie_> | bbl |
| 21:53 | <Hixie_> | have a good flight |
| 21:53 | <bholley> | Hixie_: thanks |
| 22:01 | <annevk> | So from what I read on http://asciiwwdc.com/2013/sessions/614 it seems like "Safari push notifications" are wildly different from http://www.w3.org/TR/push-api/ |
| 22:01 | <annevk> | The former actually creates an end-user notification and the latter uses a service worker to decide what to do next... |
| 22:02 | <zewt> | probably modelled around iOS push notifications |
| 22:03 | <zewt> | i think there are two different things that get called "push notifications": for pushing a message to a user (like SMS popups), and for pushing a message to a running app... |
| 22:04 | <zewt> | (which is to say, they may be targetting different things and not be at odds, other than using the same name) |
| 22:35 | <Hixie_> | can someone tell me what IE does on http://www.hixie.ch/tests/adhoc/dom/level0/history/cross-origin/001.html ? |
| 22:53 | <Hixie_> | or http://www.hixie.ch/tests/adhoc/dom/level0/history/cross-origin/000.html for that matter |
| 22:53 | <zewt> | the heck? firefox's download page won't tell me what version of Firefox it's about to send me--I have to actually start the download and look at the filename |
| 22:53 | <Hixie_> | shouldn't you always just get the latest version? |
| 22:54 | <Hixie_> | "versions" are so last decade |
| 22:54 | <zewt> | ... the whole reason I'm at the page is to find out if I'm on the latest version or not |
| 22:54 | <annevk> | Hixie_: says "Ok, calling back() on our old History object..." |
| 22:55 | <annevk> | Hixie_: in both |
| 22:55 | <Hixie_> | annevk: thanks |
| 22:55 | <annevk> | Hixie_: 001 has damowmow and 000 has www.hixie.ch in colors |
| 22:55 | <Hixie_> | cool ok |
| 22:55 | <Hixie_> | thanks |
| 22:56 | <Hixie_> | so basically History objects from inactive Documents don't do anything |
| 22:56 | <Hixie_> | and throw |
| 22:56 | <Hixie_> | which makes sense |
| 22:56 | <Hixie_> | maybe we should define this at the WebIDL level though |
| 22:57 | <Hixie_> | heycam|away: would it make sense to have some sort of WebIDL attribute I can put on interfaces that says "anything on this that gets called should throw if it is not [magic hook]" |
| 22:58 | <Hixie_> | heycam|away: so i can put this on History (and maybe others), where [magic hook] in this case would be "it's Document is the active document of its Document's browsing context" |
| 22:58 | <Hixie_> | s/it's/its/ |
| 23:00 | <Hixie_> | i guess i'll file a bug |
| 23:08 | Hixie_ | wonders wtf @@unscopable is |
| 23:14 | <zewt> | that's pretty incredible: IE10's network console lies about response headers |
| 23:14 | <zewt> | (it's getting a response with Content-Encoding: gzip, and it's not listed at all) |
| 23:14 | <zewt> | <- trusts ngrep more than IE10 |
| 23:15 | <Hixie_> | tcpdump is the only reliable source |
| 23:15 | <Hixie_> | :-P |
| 23:15 | <zewt> | easier to get raw data with ngrep |
| 23:15 | <zewt> | tcpdump is better for squinting at packet headers |
| 23:16 | <Hixie_> | (though tcpdump lies about what it does right in its name, so i guess it starts from a poor position in the race to "not lying") |
| 23:16 | <zewt> | i rarely grep with ngrep, I guess |
| 23:17 | <Hixie_> | ngrep and tcpdump both use pcap, so they're basically the same thing, anyway |
| 23:18 | <zewt> | i don't know though, i know i shouldn't be surprised by stupid crap IE does, but missing headers in the network tab in the developer console? seriously? |
| 23:18 | <zewt> | that's just mean |
| 23:19 | <Hixie_> | probably a side-effect of their network library trying to transparently support gzip |
| 23:19 | <Hixie_> | i mean, mozilla's view source lied about the source for a long time |
| 23:19 | <Hixie_> | it's not unheard of |
| 23:20 | <zewt> | lies, damn lies and debuggers |
| 23:23 | <Hixie_> | (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23358 for the above) |
| 23:44 | <vitalia> | Hi. Before update to html-lib 0.99 I do sanitize in such way: "def sanitize(value): |