03:23
<Hixie>
nessy1: yt?
03:38
<abarth>
Hixie: does the html spec define what happens if you point an iframe at a SWF?
03:39
<abarth>
Hixie: I couldn't find it in the navigation algorithm
03:39
<abarth>
http://www.whatwg.org/specs/web-apps/current-work/#navigate step 23 seems to be close
03:40
<abarth>
but doesn't saw what to do if you get a mime type that should be handled by a plugin
03:42
<Hixie>
yeah, should do...
03:43
<Hixie>
step 23 "A type that will use an external application to render the content in the browsing context"
03:43
<Hixie>
"Follow the steps given in the plugin section, and abort these steps"
03:43
<Hixie>
http://www.whatwg.org/specs/web-apps/current-work/#read-plugin
03:43
<abarth>
ah
03:43
<abarth>
thanks
03:44
<abarth>
so, in CSP
03:44
<abarth>
we want the document created there to inherit the plugin-types directive from the parent browsing context's CSP policy
03:45
<Hixie>
wouldn't you always want that?
03:45
<abarth>
I can write that in the CSP spec
03:45
<abarth>
no, in general
03:45
<abarth>
CSP is a per-document policy
03:45
<abarth>
the policy doesn't spam over child iframes
03:45
<Hixie>
http://www.whatwg.org/specs/web-apps/current-work/#implement-the-sandboxing
03:45
<Hixie>
says it does
03:46
<abarth>
yeah, sandbox spams over children
03:46
<Hixie>
oh that's the sandboxing flags
03:46
<Hixie>
not CSP
03:46
<abarth>
right
03:46
<Hixie>
right
03:46
<Hixie>
ok
03:46
<abarth>
the question is whether we should spec this kind of thing in CSP or in HTML
03:46
<Hixie>
i don't normatively reference CSP at all so far
03:46
<abarth>
ok, i can spec it in CSP
03:46
<Hixie>
so, i'm happy to do it, but it's probably best for HTML to provide a hook for you
03:47
<abarth>
yeah, can you just give these sorts of documents a name?
03:47
<Hixie>
yeah, one sec
03:47
<abarth>
e.g., "a plugin document" ?
03:47
<abarth>
thanks
03:48
<Hixie>
"plugin document" it is
03:49
<Hixie>
what is the name of the thing you're using this for? to ensure iframes can't be used to evade... what?
03:49
<Hixie>
plugin policies?
03:49
<Hixie>
plugin directives?
03:49
<abarth>
yeah, plugin-types let you say which plugin times are allowed
03:49
<abarth>
so, plugin-types application/pdf
03:50
<abarth>
would mean that you can only have PDF plugins
03:50
<abarth>
not SWF or silverlight or whatever
03:50
<abarth>
that works fine, except that you could bypass it with <iframe>
03:50
<abarth>
since <iframe> creates a new document
03:50
<abarth>
which wouldn't have the restriction
03:50
<abarth>
<iframe src="foo.swf">
03:55
<Hixie>
abarth: but what is plugin-types called?
03:55
<Hixie>
a directive?
04:02
<abarth>
yes
04:02
<Hixie>
k
04:02
<Hixie>
is there a typographic convention for these?
04:02
<Hixie>
"<code>plugin-types</code> directive"?
04:03
<Hixie>
(e.g. CSS properties use "the 'foo' property")
04:03
<abarth>
Yeah <code>plugin-types</code>
04:03
<abarth>
the verb is "enforce"
04:03
<abarth>
so, you'd say something like "enforce the <code>plugin-types
04:03
<abarth>
</code> directive
04:03
<abarth>
"
04:04
<Hixie>
i'm using "evade"
04:04
<Hixie>
cos it's the negative
04:04
<abarth>
:)
04:05
<Hixie>
ok, spec is building and change should be committed momentarily
04:06
<abarth>
thanks
08:30
<annevk>
fyi, I might have missed some memos
08:39
<annevk>
So I could have sworn I filed a bug on Web IDL to move DOM exceptions there. I guess I didn't...
08:40
<heycam>
sounds familiar
08:40
<heycam>
http://lists.w3.org/Archives/Public/public-script-coord/2013JanMar/0049.html
08:41
<heycam>
seems reasonable at this point, too, now that SVGException is gone
08:42
<Ms2ger>
Working on webidl again? :)
08:42
<heycam>
next week
08:42
<heycam>
will be at a web dev conference thurs/fri, so preparing my presentation for then atm
08:42
<annevk>
W3C mailing list search did not find that for my email combined with the keyword "exception" :/
08:43
<annevk>
heycam: do I need to file a bug or will you handle it?
08:43
<heycam>
I'll handle it
08:43
<heycam>
I've kept a track of what things I've addressed on the list
09:33
<annevk>
Wow, that W3C survey is the worst. I give up.
09:35
<SimonSapin>
annevk: the one to win an ipad?
09:35
<annevk>
Yes
09:35
<SimonSapin>
It looks so much like spam that I didn’t even try
09:36
<jgraham>
?
09:36
<annevk>
I didn't see the iPad bit initially. I thought it was about improving the W3C, but it's a load of bullocks. They've really no idea what they're doing I think...
09:36
<SimonSapin>
https://twitter.com/w3c/status/328946308146688001
09:36
<annevk>
Bunch of members, some money, some plans on how to get more money, and that's it...
09:37
<annevk>
Which is not really what you'd expect from an organization behind the standards of the web.
09:39
<jgraham>
Yeah, so after all the first questions were about money, and there were about 30 different boxes to tick for senion management job titles and about 10 for the other 99%, I think I am not the target audience for this survey
09:40
<jgraham>
(sorry, 39/9)
09:44
<annevk>
The job title one was already ridiculous. And field your organization is involved in did not list "web".
09:48
<Workshiva>
I wonder what the mimimum money made is to finish the survey
09:59
<svl>
I got to page 37 on that survey, and then: "Server Error in '/W3CT' Application."
10:03
<jgraham>
svl: Oh, so it's modern art. Makes sesne I guess.
10:04
<svl>
I managed to get further by hitting back, and then the previous button
10:04
<svl>
so yes, I'd say that's an accurate description. :)
10:04
<jgraham>
I think karlcow will approve
10:11
<hallvors>
annevk: any further thoughts on the XHR pull request?
10:11
<annevk>
hallvors: I don't get email from GitHub so I didn't know you replied yet :)
10:12
<hallvors>
GitHub spams way too much ;-)
10:13
<annevk>
That's probably why I disabled it. I do get some OS notifications now and then, if I happen to be online.
10:13
<jgraham>
Yeah, it relly does
10:13
<jgraham>
*really
10:13
<annevk>
hallvors: so I think the main question is why browsers feel the need to terminate the request in that case.
10:14
<annevk>
hallvors: because the whole point of checking this in open() is so that the Document can go away. If the document can never go away...
10:14
<hallvors>
it's probably just simpler to avoid zombie requests associated with no longer existing windows..
10:16
<hallvors>
you mean - open() needs a document (to resolve URLs and such) but the rest of the algorithm doesn't?
10:17
<hallvors>
- and that's the point of making open() throw but not interrupt anything else
10:18
<hallvors>
I think we should go ask a couple of implementors at this point :)
10:18
<annevk>
Yes and agreed
10:18
<hallvors>
(though I note that they seem to have collectively voted for "terminate the request" already)
10:18
<annevk>
smaug____: ^^
10:19
<hallvors>
-Gecko, Presto and Chromium, that is -
10:19
<hallvors>
don't have IE 10 and the test framework doesn't really work in IE8
10:20
<annevk>
I have IE10, do you have a URL?
10:21
<smaug____>
annevk: not sure I understand the question ..
10:21
<smaug____>
something about XHR
10:21
<wilhelm>
hallvors: browserstack.com is your friend.
10:22
<annevk>
smaug____: window1 does something like new window2.XMLHttpRequest; then does .open(); then at some point window2 is navigated
10:22
<annevk>
smaug____: given that all the information for the request is known, why is it terminated?
10:23
<hallvors>
(window2 might also be removed: IFRAME removed, popup closed etc)
10:23
<smaug____>
I'd expect XHR is terminated
10:23
<hallvors>
http://w3c-test.org/web-platform-tests/submissions/103/XMLHttpRequest/ look at the tests with -multi-window in name
10:23
<annevk>
smaug____: correct, but why?
10:23
<smaug____>
annevk: because all the network connections related to window2 are cancelled
10:23
<smaug____>
there is a load group
10:24
<smaug____>
and all the loads (network connections) in that group are terminated
10:25
<annevk>
hallvors: looks like IE follows the spec, assuming the tests match what you think should happen
10:25
<hallvors>
wilhelm: I suppose browserstack.com doesn't let me attach a debugger and step through some random stuff in IE ;-)
10:25
<hallvors>
annevk: what exactly do the tests say in IE?
10:26
<annevk>
for 4 I get 'assert_equals: responseText is empty on inactive document error condition expected "" but got "bottom\n"'
10:26
<annevk>
for 2 I get 'assert_throws: open() when associated document's IFRAME is removed function "function() { client.open("GET", "folder.txt"..." did not throw'
10:26
<hallvors>
smaug____: is that implementation hard to change if the spec says something else?
10:26
<annevk>
for 3 I get 'assert_throws: send() when associated document's IFRAME is removed function "function() { client.send(null) }" did not throw'
10:26
<smaug____>
I don't see reason to change it ;)
10:27
<annevk>
for 5 I get 'assert_throws: function "function() { client.open("GET", "...") }" threw object "TypeError: Permission denied" that is not a DOMException INVALID_STATE_ERR: property "code" is equal to undefined, expected 11'
10:27
<smaug____>
but yes, it would be somewhat hard to change
10:27
<hallvors>
smaug____: me neither but the spec currently dictates something else :)
10:27
<hallvors>
so you'll have to convince Anne if you don't want to change it ;-)
10:27
<smaug____>
and it would be odd to change
10:27
<annevk>
I suspect I reverse engineered IE as I remember at some point bz asking questions about the multi-window stuff and saying there were compatibility issues there.
10:28
<smaug____>
then the behavior of var img = new window2.Image(); img.src = "foo.gif"; should be changed too
10:28
<hallvors>
(or vote for accepting https://github.com/whatwg/xhr/pull/3 ;))
10:28
<annevk>
If those are gone.... Then we can do something else.
10:28
<smaug____>
and Audio and whatelse
10:28
<annevk>
smaug____: I think those are different. They use the entry script's document.
10:29
<smaug____>
so?
10:29
<annevk>
smaug____: so window2 is not very relevant there.
10:29
<smaug____>
well, if you just pass such Img object from window2's context
10:30
<annevk>
smaug____: whereas for XMLHttpRequest it is
10:31
<annevk>
Might still be some oddities with the prototype chain I suppose... Meh
10:31
<wilhelm>
hallvors: Yes, it only has the built-in devtools.
10:34
<annevk>
Sooo anyway. If we go with that kind of fetch management. We should probably document that in some way centrally. So a global scope can just say that it terminates all ongoing fetch requests and they report to their callers in an appropriate fashion.
10:35
<annevk>
E.g. I doubt you'd get a network error if some part of the response has already been retrieved. It would probably just terminate earlier, although maybe we should signal that kind of error still if we can trust Content-Length somehow?
10:37
<annevk>
Awesome, http://info.cern.ch/hypertext/WWW/TheProject.html uses <header> to mean <head>.
10:38
<hallvors>
for XHR I think firing an error event makes sense
10:38
<annevk>
And uses identifiers that start with a digit. That should never have been disallowed.
10:39
<annevk>
hallvors: that's too simple. What if data is already being processed?
10:45
<hallvors>
well, what happens if there is some network error while data is being processed but the request is not completed?
10:48
<annevk>
I think you cannot distinguish that from Content-Length being wrong at the moment.
10:48
<hallvors>
is there no error event?
10:48
<annevk>
The "network error" bit is really only distinguishing up until all header data has been processed. I think after that you'd just get load.
10:50
<annevk>
Fetch will define most of that and XMLHttpRequest will simply reference it at that point, hopefully obsoleting most of the text around the subject.
10:54
<hallvors>
But spec does say under "infrastructure for send()": If there is a network error -> In case of DNS errors, TLS negotiation failure, or other type of network errors, this is a network error.
10:55
<annevk>
Yeah I'm not sure that's accurate
10:56
<annevk>
Well, most of it is of course. It's not clear if it's a network error if the server just stops transmitting at some point. Or you close the receiving end.
10:58
<hallvors>
So if the server just closes down the connection and you haven't received "Content-Length" amount of data, you think the script should not be informed with an error event that something odd happened?
11:00
<hallvors>
BTW Anne - I wanted to ask you about this: https://github.com/hallvors/web-platform-tests/commit/890a45686adceb8be18c3fa832ab54ad1fd5b7b5
11:00
<annevk>
I'm saying is not informed, because browsers have to deal with faulty Content-Length. Reporting it in some fashion might still make sense though.
11:01
<hallvors>
As the spec is written one still gets the readystatechange event with readyState 4, then an error event.
11:01
<annevk>
Right, I'm saying that I think the specification is wrong there.
11:01
<hallvors>
Yes. This is actually a bit awkward.
11:02
<hallvors>
scripts that see readystatechange and readyState == 4 shouldn't have to wait for a potential error event to be certain that the request finished OK
11:02
<annevk>
Regarding the test, yeah, credential throwing was removed.
11:03
<hallvors>
OK, test will be aligned shortly :)
11:03
<hallvors>
I guess we could spec a request.errorState property .. or something.
11:04
<hallvors>
request.errorState = 0 means no problem, 1 means network error..
11:04
<annevk>
We already that with .status being 0
11:04
<annevk>
And non-zero meaning no network error. But there's other classes of errors such as mismatched Content-Length...
12:34
<SteveF>
hober: you awake?
12:51
<djc>
so I can't create an account on www.w3.org/Bugs, is that something I can complain about here?
12:51
<djc>
keeps saying I have an invalid token, even when I say I want to commit anyway
12:59
<annevk>
djc: best to ask in #sysreq on the W3C IRC server
13:20
<djc>
annevk: thanks, that worked
13:21
<annevk>
yw
13:32
<annevk>
Grmbl. HTTP authentication fffffffffuuuuuuuu. Man, have to actually hit a key multiple times these days to repeat it.
13:59
<matjas>
annevk: which OS?
14:05
<annevk>
matjas: OS X
14:05
<matjas>
annevk: then check this out: https://github.com/mathiasbynens/dotfiles/blob/f21a29cd78d65300e6853338864b5c9507f0e1ca/.osx#L148-L152
14:05
<annevk>
matjas: haha, madness
14:06
<matjas>
run those two commands, reboot, and you’ll be able to comfortably type ffffffffuuuuuuu again
15:19
<gsnedders>
What kind of security question is "What is your mother's first name?". That's a matter of public record!
15:34
<Ms2ger>
gsnedders, what's her maiden name? :)
15:34
<gsnedders>
Ms2ger: That's also a matter of public record. ;P
15:38
marcosc
notes nerds making mom jokes.
15:40
<Ms2ger>
Yo momma's maiden name's so fat, it isn't accepted as an answer to the security question?
16:21
<dglazkov>
good morning, Whatwg!
16:52
<annevk>
Is someone working on making specification annotations work better across specifications?
16:52
<annevk>
I'd like to annotate some bits in "Fetch" with "needs review and tests" or some such
16:53
Ms2ger
assumes tantek is the troll :)
17:00
<annevk>
http://html-differences.whatwg.org/
17:19
<Redface>
hi
19:44
<cabanier>
Hixie: ping
19:45
<annevk>
Hixie: with respect to strategy, I'd rather do the minimum possible I suppose
19:45
<annevk>
Hixie: I hope at some point we can figure out a sane way to define all the event stuff
19:45
<annevk>
Hixie: event loop stuff*
19:51
<cabanier>
Hixie: do you remember why measureText requires the font to be local. Why not enforce CORS?