| 00:24 | <TabAtkins> | Not safe, as the origin page might be compromised. |
| 00:24 | <TabAtkins> | But if we pretend that it's not, then yeah, data is safe - browser negotiates an https connection to the destination and transports over that. |
| 00:24 | <TabAtkins> | GPHemsley: ^^^ |
| 00:25 | <GPHemsley> | yeah... I ain't putting my SSN into that form |
| 08:52 | <mkwst> | GPHemsley: Browsers are starting to explictly mark HTTP pages as non-secure when they contain password forms: https://arstechnica.com/information-technology/2017/01/firefox-chrome-start-calling-http-connections-insecure/. You can imagine that we'll get more aggressive on that front over time. |
| 08:55 | <mkwst> | tobie, et al: Is there any WebIDLish mechanism for specifying attribute setters of various types that don't do implicit conversion? |
| 08:56 | <mkwst> | Like, say I have `attribute DOMString innerHTML`. Can I have a setter for that attribute that accepts some other specific type that isn't a `DOMString`, without an implicit call to the stringifier? |
| 09:36 | <tobie> | mkwst: a union type wouldn't work in that context? |
| 09:37 | <mkwst> | tobie: Hrm. I guess a union type could work. The getter would just always return `DOMString`? |
| 09:40 | <tobie> | mkwst: yeah. :-/ |
| 09:40 | <mkwst> | I mean, that's what I want. :) I'm just trying to find the right way of expressing the kind of thing I'm trying to play around with. |
| 09:41 | <mkwst> | It didn't occur to me that something like `attribute (SpecialType or DOMString) whatever` would actually work. |
| 09:42 | <tobie> | mkwst: we have this discussion quarterly. Types are both a coercion system and a documentation for the return value of the getters… which tbh is quite confusing. |
| 09:42 | <mkwst> | Well, it is Q3. :) |
| 09:43 | <tobie> | Good. Love it when we have it so early. |
| 09:43 | <tobie> | :D |
| 09:43 | <mkwst> | Right. Getting it out of the way... ;) |
| 09:43 | <tobie> | Yeah, thanks! |
| 09:45 | <tobie> | So the fact that it always returns a DOMString will need to be specified in prose. |
| 09:46 | <mkwst> | Makes sense. :) |
| 11:45 | <GPHemsley> | jgraham: Dunno if this is you, but something is still wrong with the testrunner in Chrome |
| 11:45 | <GPHemsley> | Safari and Edge are fixed |
| 11:50 | <GPHemsley> | annevk, Domenic: It appears that Edge treats a base URL with a single-letter protocol as a Windows drive letter, and then converts it to file: |
| 11:51 | <annevk> | GPHemsley: https://github.com/whatwg/url/issues/271 |
| 11:53 | <GPHemsley> | ah, very nice |
| 12:15 | <jgraham> | GPHemsley: https://github.com/w3c/web-platform-tests/pull/6456 seems to have reasonable looking results for Chrome |
| 12:23 | <GPHemsley> | jgraham: Well, I dunno what happened here then: https://travis-ci.org/w3c/web-platform-tests/jobs/249949077 |
| 12:24 | <GPHemsley> | is it possible there's an upper limit on test output from Chrome? |
| 12:25 | <jgraham> | GPHemsley: Looks like a chromedriver bug |
| 12:25 | <jgraham> | (and yeah, travis has a log size limit) |
| 12:26 | <jgraham> | But "PID 6909 | [1.563][SEVERE]: Bad inspector message: {…" seems like something rbyers should look at |
| 12:26 | <GPHemsley> | sounds good, thanks |
| 12:27 | <jgraham> | (I think that Chrome might just have a size limit on those messages, so tests with many many subtests are a problem) |
| 12:42 | <GPHemsley> | this is the first I've seen of it, so may have just reached that with this PR |
| 13:21 | <JakeA> | annevk: Surprised that opaque responses are known as "CORS-cross-origin" given that they're usually the result of a no-cors request https://html.spec.whatwg.org/multipage/urls-and-fetching.html#cors-cross-origin |
| 13:27 | <annevk> | JakeA: Ian minted those terms a long time ago and I haven't bothered to refactor (or lift those terms into Fetch) yet |
| 13:27 | <JakeA> | fair enough |