| 07:29 | <jochen__> | domfarolino: then I don't get why you're looking at the initiator for same-origin checks? |
| 07:30 | <domfarolino> | jochen__: A request's referrer string and initiator (origin) can be cross-origin. And the definition of same-origin compares a request's URL with the initiator origin |
| 07:31 | <domfarolino> | jochen__: (But chrome's impl compares a request's URL with the referrer string origin) |
| 07:32 | <jochen__> | but why would we care about the initiator? |
| 07:32 | <jochen__> | maybe the same-origin definition is not fitting the intend ? |
| 07:34 | <domfarolino> | jochen__: I was just trying to align chrome's impl with the definition of same-origin (found in referrer-policy spec). It compares a request's origin with the current URL, and in implementation-land, I believe that is the same as comparing initiator (origin) and URL |
| 07:36 | <domfarolino> | I think we can either change chrome's implementation to match the spec, or change the spec's definition of same-origin to compare <url, referrrer string> instead of <url, origin> |
| 07:38 | <jochen__> | we should do the latter |
| 07:39 | <domfarolino> | OK; feel free to mention that on the thread too. Just want to make sure there isn't any harm in doing that (privacy-wise maybe) |
| 07:39 | <domfarolino> | cc yhirano |
| 07:42 | <domfarolino> | does feel a little inconsistent that one spec's definition of a same-origin request is kinda different from others though. Maybe that's ok |
| 07:47 | <MikeSmith> | Domenic: FYI https://github.com/mdn/browser-compat-data/issues/5214 is about updating BCD to distinguish between legacy Edge and Blink-based Edge |
| 07:49 | <MikeSmith> | as I commented there, I think it would make the most sense to just create a new top-level "Edge (Blink-based)" browser in BCD, and add the new data under that (which is relatively simple because it can basically just all be copied from the existing Chrome data) |
| 07:58 | <yhirano> | domfarolino, jochen__: commented at https://github.com/w3c/webappsec-referrer-policy/issues/123 |
| 13:11 | <PiersW> | jgraham, gsnedders: you're welcome to come up whenever. We're an easy 15 minute walk from the station. I'd try to avoid a Wednesday as some people tend to work from home that day, but that could change if necessary. Probably best to DM? |
| 13:17 | <gsnedders> | PiersW: what's your email, and I'll drop you a line later? |
| 13:20 | <PiersW> | piers⊙ec |
| 14:32 | <botie> | zcorpan, at 2019-05-31 11:29 UTC, MikeSmith said: when you have some time, I wanted to ask you about <picture> test cases |
| 14:32 | <zcorpan> | MikeSmith: here now |
| 14:34 | <zcorpan> | I noticed another html parser interop difference :-| |
| 14:34 | <Ms2ger> | :/ |
| 14:36 | <zcorpan> | "If the parser was created as part of the HTML fragment parsing algorithm, then act as described in the "any other start tag" entry below. (fragment case)" |
| 16:02 | <bradleymeck> | Domenic: any concerns exposing MIMEParams as a ctor in https://bmeck.github.io/node-proposal-mime-api/ , seems like it should accept a round-trip able string is all? |
| 16:04 | <bradleymeck> | also unclear on how to handle URL percent encoding staring at the parser it doesn't have any flags so would decoding prior to piping through it be the right place? that would mean encoded `=` acts a bit odd though |
| 17:29 | <Domenic> | bradleymeck: I'm not sure that it's great to add the concept of "parameter string" separate from "serialized MIME type" |
| 17:30 | <Domenic> | Like right now there is no concept for what `foo=bar;baz=qux` is separate from `x/y;foo=bar;baz=qux`. And introducing a new concept with its own parser, serializer, etc. seems potentially problematic. |
| 17:30 | <bradleymeck> | it makes the API slightly more convenient since non-callable classes are not really a thing in, and URL params also exposes a string ctor |
| 17:31 | <bradleymeck> | part of the reason here is there appears to be a problem with URL percent encoding and MIME param parsing as well |
| 17:31 | <Domenic> | I think a constructor can exist without being overloaded to also take a string |
| 17:31 | <bradleymeck> | you likely want to flag decoding the params as it shouldn't happen before parsing the params due to encoding the = |
| 17:31 | <Domenic> | It should just behave like the Map() constructor. |
| 17:31 | <Domenic> | I don't think URL encoding should be involved here at all |
| 17:31 | <Domenic> | Just prohibit characters not in the list |
| 17:32 | <bradleymeck> | I'm a bit confused as URL encoding is quite intertwined with MIME params when you deal with data: |
| 17:32 | <Domenic> | i.e. parameter names must be HTTP token code points and parameter values must be HTTP quoted-string code points |
| 17:32 | <bradleymeck> | the list of prohibited characters doesn't really work |
| 17:32 | <Domenic> | data: is separate |
| 17:32 | <Domenic> | If you don't agree with the spec's prohibitions then you have more fundamental problems |
| 17:32 | <bradleymeck> | it is not as parsing URL percent encoding is involed in data MIME parsing |
| 17:33 | <bradleymeck> | its part of data, it isn't really about agreement |
| 17:33 | <bradleymeck> | the parser seems fine but gets all wonky and doesn't make sense when put inside a URL |
| 17:33 | <Domenic> | That isn't how the data: URL parser works. First it URL parses. Then it MIME type parses pieces of it. Only the first part involves URL encoding. |
| 17:34 | <bradleymeck> | so you are saying `text/plain;foo${encodeURIComponent('=')}bar${encodeURIComponent(',')}baz,` should have a body of `baz,` not ``? |
| 17:35 | <Domenic> | Is that a MIME type or a data URL? |
| 17:35 | <bradleymeck> | ah, prepend `data:` to that, so `data:text/plain;foo${encodeURIComponent('=')}bar${encodeURIComponent(',')}baz,` |
| 17:35 | <Domenic> | The answers are different in each case |
| 17:36 | <Domenic> | Well, I guess they are not, in both cases the URLs are not decoded |
| 17:36 | <Domenic> | https://jsdom.github.io/whatwg-url/#url=ZGF0YTp0ZXh0L3BsYWluO2ZvbyUzRGJhciUyQ2Jheiw=&base=YWJvdXQ6Ymxhbms= |
| 17:37 | <bradleymeck> | i'm trying to figure out an API that is usable for both, thats all. i don't really want to propose changes anywhere but the specs seem confusing here |
| 17:38 | <Domenic> | The MIME type string is `text/plain;foo%3Dbar%2Cbaz` which parses as just `text/plain` since the parameter named `foo%3Dbar%2Cbaz` gets thrown out |
| 17:38 | <bradleymeck> | the data: RFC pointed out using percent encoding for values outside of http quoted-string ranges so it just adds to this confusion a bit for me |
| 17:38 | <Domenic> | https://runkit.com/domenicdenicola/5de54c2c2340d00019ec9b51 |
| 17:39 | <Domenic> | Ignore the RFCs |
| 17:40 | <Domenic> | Use the reference implementations, at https://jsdom.github.io/whatwg-url/ and https://npm.runkit.com/whatwg-mimetype |
| 17:40 | <Domenic> | So e.g. your example data: URL is at https://jsdom.github.io/whatwg-url/#url=ZGF0YTp0ZXh0L3BsYWluO2ZvbyUzRGJhciUyQ2Jheiw=&base=YWJvdXQ6Ymxhbms= |
| 17:40 | <Domenic> | As you can see it has a path component of `text/plain;foo%3Dbar%2Cbaz,` |
| 17:40 | <bradleymeck> | Domenic: there appears to be issues with that ref impl though |
| 17:40 | <bradleymeck> | https://runkit.com/bmeck/5de54c621ede90001abf065e |
| 17:41 | <Domenic> | What's the issue? |
| 17:41 | <bradleymeck> | i've tried going step by step through the mimesniff spec |
| 17:41 | <Domenic> | That result looks correct to me |
| 17:41 | <bradleymeck> | it doesn't seem to deal with percent encoding anywhere that i can tell |
| 17:41 | <Domenic> | Correct |
| 17:41 | <bradleymeck> | like percent encoding is ignored for that part of the url |
| 17:42 | <Domenic> | Correct |
| 17:42 | <Domenic> | That is the correct behavior |
| 17:42 | <Domenic> | You seem to have been confused by some obsoleted RFCs |
| 17:42 | <bradleymeck> | and the current mimesniff / data url processor |
| 17:42 | <bradleymeck> | not just the RFCs |
| 17:42 | <bradleymeck> | the RFCs got brought up after the issue on fetch opened |
| 17:42 | <Domenic> | OK. Then where are you getting the idea that URL encoding should be involved? |
| 17:44 | <bradleymeck> | https://fetch.spec.whatwg.org/#data-urls , it takes a URL and serializes it , the URL would have already decoded stuff to my understanding, and re-encoding gets funky/wrong with some stuff |
| 17:45 | <bradleymeck> | bbiab |
| 17:45 | <Domenic> | The URL does not "already have decoded stuff" |
| 17:45 | <Domenic> | As seen from https://jsdom.github.io/whatwg-url/#url=ZGF0YTp0ZXh0L3BsYWluO2ZvbyUzRGJhciUyQ2Jheixmb28lM0RiYXIlMkNiYXo=&base=YWJvdXQ6Ymxhbms= |
| 17:46 | <Domenic> | I'll be back later too, getting lunch |
| 18:02 | <bradleymeck> | Domenic: then i'm just more confused as to how a URL is there if it isn't parsed/decoded already |
| 18:04 | <annevk> | The URL parser does very little percent decoding itself (only for hosts and dots in paths really, iirc) |
| 18:05 | <annevk> | A processor for a particular scheme could do more decoding, and the data: one does, but not for the MIME type |
| 18:09 | <bradleymeck> | i'm fine with either direction but feel some uneasiness with the tone of ignoring other places (e.g. the RFCs) that i often see here |
| 18:11 | <annevk> | So the problem with some RFCs is that they aren't maintained and nobody wants to align with them. That's mainly why there's alternatives now, that are maintained (mostly). |
| 18:12 | <annevk> | (Well, "nobody" is something like "nobody big enough that they need to interoperate with web content in the wild".) |
| 18:14 | <annevk> | bradleymeck: as for your API sketch, if a MIME's mime is a MIME type, that'll also hold the parameters |
| 18:14 | <annevk> | bradleymeck: also, I'd call the main class MIMEType |
| 18:15 | <annevk> | bradleymeck: and there should be an essence getter on it |
| 18:15 | <bradleymeck> | annevk: yes, but if you expose an API for the params like URLSearchParams does it causes a separate object API |
| 18:17 | <annevk> | This might lead to all kinds of issues though depending on how folks use these |
| 18:19 | <bradleymeck> | annevk: can you clarify/has this been discussed regarding URLSearchParams somewhere that I can read? |
| 20:51 | <MikeSmith> | annevk: Domenic: https://domspec.herokuapp.com/ has MDN annotations added to the DOM spec |
| 20:52 | <MikeSmith> | I’m still working on the patch for Bikeshed, but as far as the output goes, that’s what the patch will generate |
| 20:52 | <MikeSmith> | e.g., look around https://domspec.herokuapp.com/#dom-event-stoppropagation |
| 20:52 | <Domenic> | That's pretty sweet!! |
| 20:55 | <MikeSmith> | :) |
| 20:57 | <MikeSmith> | I’ll try to get Bikeshed PR raised for it this morning (I’ll otherwise be out all day from 10am to the evening my time) |
| 21:15 | <TabAtkins> | Oh dang, thanks MikeSmith! I wanted to get to it but between vacation and some higher-prio thing I haven't been able to! |
| 21:15 | <MikeSmith> | Hey TabAtkins! |
| 21:15 | <MikeSmith> | no worries — I had meant to get to it long before now |
| 21:17 | <MikeSmith> | TabAtkins: anyway, after I get the PR raised, you can make lots of time to review it :) |
| 21:17 | <TabAtkins> | yeah def |
| 21:18 | <MikeSmith> | if you have a good setup for doing profiling of Bikeshed, among the things I hope you can look at is the performance |
| 21:19 | <MikeSmith> | on my machine it increases the build time for the DOM spec from 15 seconds to 30 seconds.. |
| 21:20 | <MikeSmith> | I guess there is probably some costly thing I’m naively doing, or else maybe just general slowness of lxml, I dunno |
| 21:20 | <MikeSmith> | anyway, it will be nice if it’ll be possible to get that time reduced |
| 21:23 | <Krinkle> | I wonder if anyone here happens to know current state of Safari's disagreement about how Page Visibility API works? – https://bugs.webkit.org/show_bug.cgi?id=116769 |
| 21:24 | <Krinkle> | ( https://bugs.webkit.org/show_bug.cgi?id=151234 ) |
| 21:40 | <TabAtkins> | Yeah, I've got some good profiling scripts set up that I can run over the stuff. |
| 21:41 | <TabAtkins> | (The `bikeshed profile` command, tho it depends on some things installed that aren't immediately obvious.) |
| 21:41 | <TabAtkins> | More than likely it's something like you running selectors inside a loop or something. |
| 21:44 | <MikeSmith> | TabAtkins: yeah there are couple places that I suspect but I haven’t had time to look at yet |