| 00:48 | <MikeSmith> | SimonSapin: try again now |
| 00:49 | <SimonSapin> | I haz access now |
| 00:49 | <MikeSmith> | super |
| 00:53 | <SimonSapin> | https://github.com/w3c/test-results looks nice |
| 01:08 | <MikeSmith> | SimonSapin: yeah, that’s another product of Robin Berjon Labs |
| 01:08 | <MikeSmith> | the tools behind that |
| 06:33 | <cvrebert> | So what magic causes events to propagate to the Window object despite document.parentNode==null ? |
| 06:36 | <annevk> | cvrebert: https://html.spec.whatwg.org/multipage/webappapis.html#events-and-the-window-object |
| 06:37 | <annevk> | cvrebert: we should probably integrate that section directly into DOM, in some kind of event path computation algorithm which Shadow DOM will modify |
| 06:37 | <cvrebert> | Yes, that monkeypatch is not easy to locate |
| 06:38 | <cvrebert> | annevk: Thanks |
| 07:19 | <annevk> | cvrebert: filed https://github.com/whatwg/dom/issues/165 |
| 07:19 | <cvrebert> | annevk: Erm, I filed https://github.com/whatwg/dom/issues/164 |
| 07:26 | <annevk> | cvrebert: oh, I guess I should have checked |
| 07:26 | <annevk> | cvrebert: your issue seems like a subset so I guess it's fine |
| 07:46 | <cvrebert> | Assuming the webpage just loaded, given <body><input type=text></body> and a script that does input.focus(), would the old-focus-chain be [<body>, document] and the new-focus-chain be [<input>, document] ? https://html.spec.whatwg.org/#focus-chain |
| 07:51 | annevk | isn't sure, still needs to learn focus |
| 08:47 | <cvrebert> | Anyone see a flaw in my reading/logic/testcase?: https://gist.github.com/cvrebert/441d88975c39662a2bd2 |
| 09:05 | <annevk> | cvrebert: I think the confusing thing with your testcase is that you are capturing events |
| 09:05 | <annevk> | cvrebert: it should show up on window due to the capturing listener, but maybe I'm missing something |
| 09:06 | <cvrebert> | annevk: I'm listening at the window level, but I'm recording the targets. Capture shouldn't change the targets. |
| 09:13 | <cvrebert> | annevk: Same result if capturing isn't used: http://jsbin.com/qoyitu/edit?html,js,output |
| 09:24 | <annevk> | cvrebert: hmm, I guess I should actually study what's going on then, almost done with a PR, will look then |
| 09:29 | <cvrebert> | Hmm. |
| 09:29 | <cvrebert> | Apparently viewing it outside of the editor changes the result. Fun. |
| 09:36 | <cvrebert> | In Chrome/Safari anyway; then they'e just [input], per spec. Firefox doesn't change. |
| 09:48 | <annevk> | cvrebert: sounds like a bug in Firefox then |
| 09:48 | <annevk> | cvrebert: are you writing tests or work on implementing this somewhere? |
| 09:51 | <cvrebert> | annevk: Just opened https://github.com/w3c/web-platform-tests/pull/2571 |
| 09:52 | <annevk> | \o/ |
| 09:52 | <cvrebert> | annevk: Results are less weird with revised testcase: https://gist.github.com/cvrebert/441d88975c39662a2bd2 |
| 12:10 | <ritsyy> | where this error is "Parse Error: (120773,9) unexpected body end tag" , i mean the line number, other than this build script didn't showed anything and there is no line at 120773 |
| 13:02 | <annevk> | ritsyy: yeah, there's a bug |
| 13:02 | <annevk> | ritsyy: https://github.com/whatwg/html-build/issues/83 |
| 13:03 | <annevk> | ritsyy: the way I fixed this for myself was by changing the build script |
| 13:03 | <annevk> | ritsyy: by removing "if [ "$WATTSI_RESULT" == "65" ]; then" and the corresponding "fi" statement and leaving the lines inbetween alone |
| 13:04 | <annevk> | Hopefully MikeSmith and Domenic can look into this |
| 13:06 | <ritsyy> | annevk: oh okay, i will also try to fix like this, thanks |
| 13:09 | <annevk> | It's not great, but it does the job until someone sorts this out |
| 13:21 | <ritsyy> | annevk: i had to do some changes in the PR and then when i ran the script it parsed so i didn't get to correct the script, but for future will keep in mind |
| 15:38 | <miketaylr> | annevk: oops. do you think it's better to also set event type back to the original here https://github.com/whatwg/dom/pull/158#discussion-diff-52565536R1217 (in addition to the last step in the invoke algo), or go for the fancy column flipping? |
| 15:40 | <annevk> | miketaylr: only there is not enough |
| 15:40 | <annevk> | miketaylr: if you look at https://dom.spec.whatwg.org/#concept-event-listener-invoke everywhere it says "terminate these substeps" is affected |
| 15:41 | <miketaylr> | ahh |
| 15:41 | annevk | tries to think it through again |
| 15:42 | <miketaylr> | i guess it seems goofy to add "and set the event type back, etc." to each of those steps |
| 15:43 | <annevk> | we could and we could abstract that further, but then we'll always have to think about it |
| 15:43 | <annevk> | ideally there's something a little nicer |
| 15:44 | <annevk> | miketaylr: I guess the flip thing doesn't really work since we want to test for the non-prefixed version first, always, right? |
| 15:44 | <miketaylr> | yeah |
| 15:44 | <miketaylr> | we'd have to flip back too |
| 15:44 | <miketaylr> | is it too magical to define "terminate the invoke substeps" which always resets type? |
| 15:45 | <annevk> | and if you're actually dispatching a synthetic webkitXXX event, then we shouldn't flip? |
| 15:46 | <annevk> | this is such a hack |
| 15:46 | <miketaylr> | haha |
| 15:46 | <miketaylr> | actually, let me go look at gecko and blink again |
| 15:46 | <miketaylr> | i dont know if listeners on a node are "sorted" |
| 15:47 | <miketaylr> | or if it's possible to have "unprefixed, prefixed, unprefixed" |
| 15:47 | <miketaylr> | (maybe that's already defined...) |
| 15:47 | <miketaylr> | because if they're sorted, once you got to webkitFoo you wouldn't need to flip back |
| 15:47 | <miketaylr> | (right?) |
| 15:48 | <annevk> | What about the next node though? |
| 15:48 | <miketaylr> | addEventListener as defined just appends tho |
| 15:49 | <miketaylr> | i guess you would have to match again for the next node, so yeah |
| 15:50 | <annevk> | miketaylr: is there a flag on the event so we know whether it participates in this hack |
| 15:51 | <miketaylr> | annevk: isnt invoke just concerned with a single node though? |
| 15:51 | <miketaylr> | dispatch traverses nodes and calls invoke on them? |
| 15:51 | <annevk> | miketaylr: or is it basically any event that starts out with a name in the left most column of the table? |
| 15:51 | <miketaylr> | looking |
| 15:51 | <annevk> | miketaylr: yes, but you mutate the event object so it affects everything |
| 15:51 | <miketaylr> | ah |
| 15:53 | <annevk> | miketaylr: we could maybe create an "previous type" slot on the event object itself and store the other value there |
| 15:53 | <miketaylr> | looks like gecko uses a usingLegacyMessage flag: https://mxr.mozilla.org/mozilla-central/source/dom/events/EventListenerManager.cpp#1286 (in EventListenerManager::HandleEventInternal) |
| 15:54 | <annevk> | miketaylr: and then at the beginning of invoke, if that slot is non-empty, set event's type to previous type and clear previous type |
| 15:54 | <annevk> | so that you always start invoke with the normal name |
| 15:55 | <annevk> | and then once you get to the table, you can always look in the leftmost column |
| 15:55 | <Ms2ger> | I wonder if anyone tried just not changing .type |
| 15:55 | <annevk> | which also means that a synthetic webkitAnimationevent never hits the table |
| 15:59 | <wanderview> | JakeA: do you know what chrome does if you have an old entry in Cache API, then match it for a recent request, but the cert associated with the response has expired between caching it and responding with it in the service worker? |
| 16:00 | <wanderview> | JakeA: does chrome fail the request for an out-of-date cert? |
| 16:00 | <annevk> | miketaylr: another bug seems to be is that Gecko first loops through all listeners and only afterwards goes through them again with a new type |
| 16:00 | <annevk> | miketaylr: so you want to structure this differently basically |
| 16:01 | <annevk> | miketaylr: basically "For each listener in listeners," needs to run twice in case the first time around nothing got called, is my impression from reading that code |
| 16:01 | <annevk> | miketaylr: the second time with the new event type |
| 16:01 | <annevk> | legacy event type* |
| 16:01 | <miketaylr> | ok, looking at what blink does now |
| 16:01 | <miketaylr> | (https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/events/EventTarget.cpp&sq=package:chromium&l=351&dr=C&rcl=1452688339) |
| 16:04 | <miketaylr> | seems like it does: find all the unprefixed listeners, and if there are any, fire those. if there weren't any, see if the prefixed legacyListenersVector is non-empty and fire those |
| 16:08 | <miketaylr> | ok, thanks for helping me think through this annevk |
| 16:09 | <miketaylr> | will work on revisions later today or tomorrow, time to "work" |
| 16:09 | <annevk> | miketaylr: I also realized that "If event’s stop immediate propagation flag is set, terminate the invoke algorithm." should be step 1 in invoke, I'll fix that now |
| 16:09 | <miketaylr> | kk |
| 16:11 | <Ms2ger> | miketaylr, if you wanna "work", writing tests is work ;) |
| 16:12 | <miketaylr> | Ms2ger: yeah, it's on my TODO list tooooo |
| 16:12 | miketaylr | burning conscience |
| 16:13 | <Ms2ger> | miketaylr, best way to make sure your research doesn't go to waste in five uninteroperable implementations :) |
| 16:14 | <miketaylr> | ^_^ |
| 16:47 | <JakeA> | wanderview: I *think* so, but don't know for sure. We certainly fail self-signed cert responses |
| 16:56 | <wanderview> | JakeA: doesn't that create a problem where the main page index.html starts perma-failing after a certain date? |
| 16:57 | <wanderview> | JakeA: until a new service worker script is published to trigger an update |
| 17:10 | <JakeA> | wanderview: ohhhhhh, I understand the question now |
| 17:11 | <JakeA> | wanderview: yeah, it should only fail at fetch() time, not at cache.match time |
| 17:11 | <wanderview> | JakeA: well, I'm more concerned about if failing in the evt.respondWith() processing |
| 17:13 | <JakeA> | wanderview: agreed, trying to find where certs are handled in the fetch spec |
| 17:13 | <wanderview> | JakeA: I don't think they are really... in some ways they are handled at the TLS transport layer |
| 17:14 | <JakeA> | wanderview: if that only happens during network interaction, the spec is fine as it is |
| 17:14 | <wanderview> | JakeA: sure... I guess I was more asking about chrome impl.. for example some people are surprised we don't re-validate cert coming out of http cache |
| 21:39 | <smaug____> | hmm, which uri is used for referrer |
| 21:39 | <smaug____> | per spec |
| 21:42 | <smaug____> | oh, if does take pushState into account |
| 21:42 | <smaug____> | surprising |
| 21:42 | <smaug____> | or not |