| 08:56 | <smaug____> | jgraham: do wpt merges happen more often these days? |
| 08:57 | <smaug____> | or perhaps I just notice them because of the bugmail ;) |
| 08:57 | <annevk> | smaug____: they should be automatic |
| 08:57 | <annevk> | smaug____: but I think there was a hickup the other day |
| 08:57 | <smaug____> | annevk: so they happen normally once a day or so? |
| 08:58 | <jgraham> | smaug____: So, the situation is… complicated |
| 08:58 | <annevk> | smaug____: looking at the bugs that get filed by the bot I think it's just per PR, as they happen roughly |
| 08:58 | <smaug____> | ahaa |
| 08:58 | <jgraham> | At the moment we upstream stuff when it lands and merge it when it hits inbound |
| 08:58 | <jgraham> | We downstream each PR as it's created and do try pushes |
| 08:59 | <jgraham> | But actually pushing the syncs is somewhat behind; I've done a lot of bugfixing on the code and we are now in a better place, but need to catch up |
| 08:59 | <jgraham> | I'm currently trying ot push like 350 PRs worth of changes and it's going… badly |
| 09:00 | <jgraham> | (inbound just doesn't stay stable enough to do this because a rebase+push seems to take like an hour) |
| 09:00 | <jgraham> | Once we are caught up the idea is that we will be able to start the next landing once the previous one merges to central |
| 09:00 | <jgraham> | So in the ideal case we will get two updates a day |
| 09:01 | <smaug____> | I see |
| 09:01 | <jgraham> | But there may be some difficulties getting there; ensuring that we always get the metadata updates just so and don't e.g. add the wrong result for an intermittent test is tricky |
| 09:03 | <jgraham> | I was hoping we'd be a bit further along by now :( |
| 09:05 | <smaug____> | well, in general wpt is great. I just wish we had started all that stuff like 25 years ago. |
| 09:06 | <smaug____> | jgraham: another question related to wpt. I think I asked this recently-ish. Are there plans to add hooks to be able to send native events to web pages |
| 09:07 | <smaug____> | or will that require webdriver or so |
| 09:07 | <jgraham> | smaug____: Yes and yesish |
| 09:08 | <jgraham> | smaug____: So we have testdriver, which provides an API for tests to use to send native events. The default implementation is webdriver-backed (or marionette, for gecko) but it's designed so that vendors can provide their own implementation so we could replace a marionette click with a priviledged js method if we wanted |
| 09:09 | <jgraham> | smaug____: So far click() works and there's a PR for sending a string of characters for keyboard events (basically WebDriver Send Keys) |
| 09:09 | <smaug____> | I have very little experience in marionette |
| 09:10 | <jgraham> | smaug____: From your point of view it's just a js API |
| 09:10 | <smaug____> | I see |
| 09:11 | <jgraham> | smaug____: https://github.com/w3c/web-platform-tests/blob/master/infrastructure/testdriver/click.html for example |
| 09:14 | <jgraham> | smaug____: Generally this stuff is a priority both for us and Google (I believe) so if there are more features you want now is a good time to say |
| 09:26 | <smaug____> | jgraham: I wonder if the API allows one to test key event handling properly |
| 09:26 | <smaug____> | masayuki has been adding quite a complicated stuff in order to test key and composition events |
| 09:28 | <smaug____> | (https://searchfox.org/mozilla-central/source/dom/interfaces/base/nsITextInputProcessor.idl) |
| 09:29 | <smaug____> | mochitest has helper functions for that |
| 09:29 | <jgraham> | smaug____: IMEs are really tricky |
| 09:29 | <smaug____> | they are |
| 09:30 | <jgraham> | smaug____: If the WebDriver actions stuff isn't enough we should probably start a conversation about standardising something for testing these things |
| 09:30 | <jgraham> | (I suspect actions aren't enough for IMEs but are for normal text input) |
| 09:32 | <jgraham> | WebDriver basically allows you to send a sequence of keyUp and keyDown events so you can do things like depress multiple keys simultaneously |
| 09:32 | <jgraham> | s/events/actions/ |
| 09:32 | <jgraham> | But of course there's some complexity in how that input corresponds to an actual keyboard |
| 10:08 | <surma> | annevk: Re https://github.com/w3c/web-platform-tests/pull/9218 |
| 10:09 | <surma> | annevk: Should I start moving ahead or wait for some more input on whether I am overengineering things? |
| 10:11 | <annevk> | surma: I think you should be able to move ahead |
| 10:11 | <surma> | \o/ cool, thanks |
| 10:12 | <annevk> | surma: we can always do dead code elimination later on, if it really comes to that; but as you say, some setups are rather complex here |
| 10:45 | <annevk> | If you invoke document.open() in an event listener callback of a node connected to the document, do any remaining listeners have their callback run? |
| 12:33 | <Domenic> | jgraham: it'd be really nice to test sequential focus navigation, especially for some shadow DOM stuff. Can we send tab key events? |
| 15:00 | <chrisf_> | Hello. Is there any reason XMLHttpRequest doesn't mandate that an error should be set when an error event is published? |
| 15:02 | <chrisf_> | Moreover, I'm curious if anyone is aware of how one could go about debugging network error events from XMLHttpRequest. It's a bit curious to me that no error is provided, unless I've missed something. |
| 15:02 | <chrisf_> | Thank you |
| 15:05 | <chrisf_> | For example, if I make a CORS request and the server doesn't provide correct headers in the response, I get an error event, but nothing indicating that the error is related to CORS. |
| 15:11 | <annevk> | chrisf_: that’s for security reasons |
| 15:11 | <annevk> | chrisf_: browser dev consoles might provide more detail |
| 15:17 | <chrisf_> | annevk: Thanks. Yes the console provides info but I was hoping there was something I could use programmatically, which could be reported to an error service. |
| 17:40 | <domfarolino> | annevk: how does individual participant verification work, just an owner ends up verifying the information or something? |
| 17:41 | <annevk> | domfarolino: yeah, just a quick profile check really |
| 17:43 | <domfarolino> | annevk: gotcha. A real simple console PR is blocking on verification for @hiroppy, no rush but whenever you get a chance that would be great :) |
| 17:44 | <annevk> | Can do tomorrow, feel free to ping me in such a PR next time |
| 18:07 | <domfarolino> | 👍 |
| 18:26 | <jgraham> | Domenic: I believe the actions stuff is powerful enough to handle that |
| 18:27 | <jgraham> | kereliuk is working on that I believe |
| 18:37 | <kereliuk> | Domenic jgraham: Would you be able to do that by just sending tab key events to elements? |
| 18:50 | <jgraham> | kereliuk: I would expect so |
| 18:50 | <jgraham> | kereliuk: But it's a testable question with a webdriver script |
| 18:51 | <jgraham> | Shadow dom might require a little more effort because the current setup depends on the ability to serialize an element as a CSS selector |
| 22:36 | <TabAtkins> | Domenic or annevk: Is there something I should hook into in DOM or HTML if my spec-thing needs to respond to an element being removed from or inserted into a document? |
| 22:36 | <TabAtkins> | (Context: while an element is removed from a document it needs to throw instead of vending a computed style map object; when it gets inserted into a new one it needs to refresh its cache for that object so it can start returning a new one.) |