| 08:46 | <foolip> | annevk: back from vacation? |
| 08:46 | <annevk> | foolip: yeah, trying to catch up with stuff I didn't get done on vacation |
| 08:46 | <foolip> | welcome back! |
| 08:47 | <annevk> | ta |
| 08:49 | <annevk> | foolip: reading some xkcd, will do Fullscreen next |
| 08:49 | <foolip> | annevk knows his priorities |
| 09:05 | <annevk> | foolip: basically, move step 7.1 to 4.0 in http://fullscreen.spec.whatwg.org/#dom-document-exitfullscreen plus some rewording so it still makes sense |
| 09:05 | <annevk> | foolip: to fix https://www.w3.org/Bugs/Public/show_bug.cgi?id=26379 |
| 09:08 | <foolip> | annevk: maybe, also have a look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 to see how you think that'll change things |
| 09:13 | <annevk> | foolip: that bug makes a lot of sense, added some people that can hopefully sort out how we ought to define it |
| 09:17 | <foolip> | annevk: great, let's do it! |
| 10:00 | <annevk> | foolip: you didn't tweet about your fullscreen post |
| 10:00 | annevk | wanted to RT from @WHATWG |
| 10:01 | annevk | finds https://twitter.com/KrisBytes/status/491989665772474368 and https://twitter.com/KrisBytes/status/492268405240909824 |
| 10:02 | <jgraham> | You can't please some of the people any of the time |
| 10:19 | <annevk> | mounir_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 is relevant for screen orientation as well |
| 10:19 | <annevk> | mounir_: all needs to be synchronized somehow |
| 10:23 | <mounir_> | annevk: how is it relevant? |
| 10:23 | <mounir_> | annevk: for the part where screen orientation is using fs? |
| 10:23 | <annevk> | mounir_: the relevant bit is that changes to orientation need to be synchronized with whenever animate frames happen |
| 10:24 | <annevk> | mounir_: and ordered somehow relative to all the other things that happen at that point |
| 10:26 | <jgraham> | annevk: Unrelatedly, what's the status of https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976 ? I might implement base URL support in servo at some point when it's clear what that should be |
| 10:27 | <annevk> | jgraham: comment 6 is still the plan of action |
| 10:27 | <annevk> | jgraham: there's no proposals that I know of that will make base URLs more complicated for now |
| 10:28 | <jgraham> | annevk: So compared to the spec what's different? Ignore <xml:base> and otherwise it's the same? |
| 10:30 | <annevk> | jgraham: HTML ties the base URL to nodes at the moment, so the difference would be that it would be tied to documents |
| 10:30 | <annevk> | jgraham: also yes, I guess, if you don't care about the difference in model it implies |
| 10:31 | <jgraham> | Well I guess I care to the extent that I want the implementation to follow the spec without being unnecessarily complex |
| 10:34 | <annevk> | So yeah, comment 6 |
| 10:34 | <annevk> | I'm waiting for implementations to remove xml:base support to align all the things |
| 10:36 | <annevk> | I actually kind of hate this background updating feature of apps on my phone. I open the app, I see something interesting. And within a second it's replaced by new content and I can no longer find it. |
| 11:08 | <foolip> | annevk: yeah, I didn't have the password handy when I wrote it and then I forgot :/ |
| 11:08 | <foolip> | let me fix that |
| 11:12 | <foolip> | annevk: https://twitter.com/foolip/status/493715626821955584 |
| 11:13 | <annevk> | foolip: thanks for cleaning it up |
| 11:14 | <foolip> | annevk: I hope the unprefixing works out :/ |
| 11:14 | <annevk> | me too |
| 11:14 | <foolip> | I think the biggest risk of breakage is the event target |
| 11:15 | <annevk> | yeah, we can change that back I guess including the bubbling stuff, bit weird, but would not be the end of the world |
| 11:15 | <annevk> | and just falling back to document if the fullscreen stack is empty |
| 11:16 | <foolip> | yeah, it would be tolerable, but a bit weird, so I'll try per spec first |
| 11:16 | <annevk> | the spec was written shortly after things started shipping, but nobody ever updated :/ |
| 11:16 | <foolip> | yeah |
| 11:16 | <foolip> | the biggest surprise to me was that WebKit's "Mozilla version" doesn't actually match anything that ever shipped in Firefox |
| 11:17 | <annevk> | anyway, along with some CSS stuff this is basically one of the last major pieces that went out with the broken prefix policy |
| 11:17 | <annevk> | which is the positive bit of this whole thing |
| 11:17 | <annevk> | hah |
| 11:17 | annevk | -> shopping |
| 11:17 | <foolip> | have fun! |
| 12:20 | <annevk> | foolip: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26366 |
| 12:20 | <annevk> | foolip: if requestFullscreen unsets the pending element from its task |
| 12:20 | <annevk> | foolip: and the task does the animation |
| 12:21 | <annevk> | foolip: and exitFullscreen simply unsets it and otherwise does its own task thing, that should work, no? |
| 13:31 | <foolip> | annevk: just replied |
| 13:32 | <foolip> | but other than that it seems sound that both functions should set some state and then queue a task (or await a stable state?) to check what to do |
| 13:32 | <foolip> | I'm honestly not sure how animation is supposed to work |
| 13:32 | <foolip> | is the assumption that implementations can animate *before* scripts have had a change to paint a fullscreen frame? |
| 13:33 | <foolip> | if so one can't blend between the two or anything like that |
| 13:33 | <annevk> | I think the idea was that the events would fire after the animation happened |
| 13:34 | <foolip> | does any implementation actually animate the transition? |
| 13:34 | <annevk> | Well, maybe not, what matters is that the moment we change various observable things and dispatch the event, the state exposed to script is "fullscreen" |
| 13:35 | <annevk> | I guess it doesn't actually have to be fullscreen at that point... |
| 13:35 | <foolip> | right |
| 13:35 | <foolip> | It seems to me that the spec saying "you can animate here" doesn't help much |
| 13:35 | <foolip> | if one wants to animate it ought to be possible without being observable to scripts |
| 13:36 | <foolip> | ... I think |
| 13:36 | <annevk> | I removed a redundant animate bit https://github.com/whatwg/fullscreen/commit/a567c6c723797cbc5116d558af39af42a59ea9e1 |
| 13:37 | <foolip> | ok, the one in exitFullscreen() isn't redundant then? |
| 13:37 | <annevk> | Well, the resizing mentioned in the tasks is important |
| 13:37 | annevk | looks |
| 13:38 | <annevk> | foolip: yeah, that should go as well |
| 13:38 | <foolip> | I think that the basic model could be something like this: |
| 13:39 | <foolip> | requestFullscreen() sets some script-invisible state, queues a (micro?)task and immediately returns |
| 13:39 | <foolip> | when that task runs, all the checks are run on that invisible state, and if they pass, resizing begins |
| 13:40 | <foolip> | once resize is complete, a task is made to run before the next animation frame, which sets the script-visible state and dispatches all the events |
| 13:40 | <foolip> | similar for exitFullscreen(), I haven't been able to understand why that currently cues multiple tasks TBH |
| 13:41 | <annevk> | The reason we have a task per document is that documents can be cross-origin and we don't want to create synchronous access hazards |
| 13:41 | <foolip> | ah yes |
| 13:42 | <foolip> | so I guess each document could await the next frame independently |
| 13:42 | <foolip> | the hazard then is that the order is not dependable and yet observable for same-origin frames |
| 13:43 | <annevk> | We could define those to be in the same task I suppose... I wonder what happens for a nesting of origins A -> O -> A |
| 13:43 | <foolip> | I've tried to understand how animation frames are work across frames but failed |
| 13:44 | <foolip> | another problem that'll come up is the scheduling of the fullscreenerror event |
| 13:45 | <foolip> | it ought to also be synchronized with animation frames since otherwise the order of events could change I think |
| 13:46 | <annevk> | I don't quite get the purpose of the script-invisible state above |
| 13:46 | <foolip> | it's the pending element |
| 13:46 | <annevk> | Okay |
| 13:47 | <annevk> | So you propose two tasks, but inbetween those tasks anything could still happen |
| 13:48 | <foolip> | hmm, between the task that does the checking + starts resize and the task that fires the events after resize? |
| 13:48 | <annevk> | Yes |
| 13:49 | <foolip> | So what Blink actually does is to request the resize synchronously in requestFullscreen() |
| 13:49 | <foolip> | but it also updates the fullscreen element stack there, which is how I noticed all of this |
| 13:49 | <foolip> | that's observable immediately by scripts :/ |
| 13:50 | <foolip> | if something could be made to work where the resize is initiated synchronously and there's only a single task once the resize is done, that'd be pretty close to what's implemented |
| 13:51 | <foolip> | it's possibly a smaller change to the spec as well, since some checks are currently sync |
| 13:51 | <annevk> | Why can't the task that does the resizing not also manipulate the stack? That was a bit unclear to me |
| 13:51 | <foolip> | there is no such task, not in the same sense at least |
| 13:52 | <foolip> | Blink just tells Chromium to go fullscreen, some things happen out-of-process and then Blink is told that it's been resized |
| 13:52 | <foolip> | there's no task that runs and waits for the resize to complete or anything like that |
| 13:53 | <annevk> | Okay, so you want to go fullscreen asynchronously, and then queue a task once that is done? |
| 13:54 | <annevk> | Perhaps the specification should separate putting the top-level browsing context fullscreen from the rest? |
| 13:54 | <foolip> | queue a task that runs immediately before the next animation frame, yes |
| 13:54 | <foolip> | it already has the top-level document flag, do you mean something additional? |
| 13:55 | <annevk> | Yeah, it seems perhaps that bit should happen earlier in an asynchronous algorithm |
| 13:56 | <annevk> | The resizing of the viewport |
| 13:56 | <annevk> | Then the per document/element resizing happen can happen afterwards |
| 13:57 | <foolip> | yeah, a "wait for the viewport to match the dimensions of the screen" step seems like it should be somewhere after "Return, and run the remaining steps asynchronously." and followed by the queuing of a task that's synchronized with animation frames |
| 13:57 | <foolip> | in the case of nested fullscreen, that condition would already be true without any waiting, so maybe not much special casing is needed |
| 13:58 | <annevk> | Yeah, this is only for the top-level browsing context, same for exitFullscreen() |
| 13:59 | <annevk> | Given we do that, does my model then make sense? |
| 14:00 | <foolip> | It sounds like we're on the same page, but can you outline again the steps of requestFullscreen() and exitFullscreen() in your model? |
| 14:00 | <foolip> | or just make the spec change and I can read that |
| 14:01 | <annevk> | foolip: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26366#c6 |
| 14:02 | <annevk> | so 1) sets pending element and does some checks sync) 2) resizes async 3) queues a task once resize is complete to do various bits |
| 14:02 | <foolip> | yes, that sounds right |
| 14:03 | <foolip> | and some of the checks that now involve the fullscreen element stack would also have to look at the pending element, unless there's always an early return for that case |
| 14:04 | <foolip> | I believe you'll have the choice of either making the first or the last requested element be the one that wins, not sure if it matters which it is |
| 14:05 | <annevk> | Ah yeah, we could either terminate early or just overwrite and not queue new tasks |
| 14:05 | <foolip> | right |
| 14:05 | <foolip> | I think I don't have an opinion, and there's likely no compat situation for that to care about |
| 14:06 | <annevk> | I guess it would be nicer to overwrite in case there's various buttons and the user changes his mind... Not sure if that'd go fast enough though |
| 14:06 | <foolip> | the more likely scenario is that there are multiple frameworks competing I think |
| 14:07 | <foolip> | in which case success is not a possible outcome |
| 14:07 | <annevk> | Early fail might be better than, plus encouraging a message to the console |
| 14:08 | <foolip> | so what about requestFullscreen() and exitFullscreen() in the same script? |
| 14:09 | <foolip> | does exitFullscreen() clear the pending element, so that when the resize is done, one exits immediately? |
| 14:09 | <foolip> | the only way to not have to deal with this is to have two tasks I think |
| 14:09 | <foolip> | but that's less nice in other ways |
| 14:09 | <foolip> | or is the exitFullscreen() just ignored? that'd be easy to implement at least... |
| 14:10 | <annevk> | Ignoring exitFullscreen() as long as there's an async operation ongoing? |
| 14:10 | <annevk> | I don't think that works as that would be bad for navigation |
| 14:10 | <foolip> | oh, yeah |
| 14:11 | <annevk> | I think exitFullscreen() should detect if an asynchronous operation is ongoing, and if so, reverse it |
| 14:11 | <foolip> | and have no events fired at all? |
| 14:11 | <annevk> | Yeah I guess |
| 14:12 | <annevk> | Nothing really happened except perhaps some flickering depending on timing of the UA |
| 14:12 | <foolip> | hmm... I don't know if it's possible to guarantee that scripts won't see the intermediate state |
| 14:12 | <foolip> | it'd be pretty easy to allow the request to finish and then immediately exit, though |
| 14:12 | <annevk> | Okay, perhaps exit should always dispatch events |
| 14:13 | <annevk> | But early exit cancels the requestFullscreen events |
| 14:13 | <foolip> | are you thinking about an "exit fullscreen pending" flag to do this? |
| 14:14 | <annevk> | request sets pending, exit simply unsets pending |
| 14:14 | <annevk> | then once the task from request runs, pending is unset which terminates the task |
| 14:15 | <foolip> | yes, ok, I think this could work |
| 14:16 | <foolip> | will have to look closely at the spec text to know for sure |
| 14:17 | <annevk> | we could also make exitFullscreen a no-op while pending is set but have the navigate variant always exit, not sure what is nicer |
| 14:17 | <annevk> | yeah, might require another day of iterating and some more review |
| 14:17 | <annevk> | not easy |
| 14:17 | <foolip> | not entirely, no |
| 14:18 | <foolip> | some feedback from roc and cpearce would be nice too, Gecko might have completely different issues around resizing |
| 14:18 | <foolip> | it's about time implementations and the spec started to agreeing on the details here :) |
| 14:43 | <annevk> | On something like Firefox OS you might not have these constraints of having to do some OS-level resize |
| 14:46 | <SimonSapin> | annevk: Having the IPv4-in-URLs discussion in two places is not great. (Even though it’s my fault for filing both.) Let’s switch to just one, which do you prefer? |
| 14:46 | <annevk> | SimonSapin: Bugzilla |
| 15:00 | <annevk> | foolip: the synchronous checks from requestFullscreen are broken as they potentially cross origin boundaries |
| 15:00 | annevk | cries a little bit |
| 15:03 | <foolip> | annevk: oops, I guess you'll need to fix that :) |
| 15:03 | <annevk> | foolip: what does Chrome do at the moment? Just go fullscreen? |
| 15:04 | <foolip> | if the checks need to enter a cross-origin iframe? |
| 15:04 | <annevk> | yeah |
| 15:05 | <foolip> | it just uses does the checks as per spec, with a cute little assert that I think will break without out-of-process iframes |
| 15:05 | <foolip> | so this looks like something that needs to be resolved sooner or later |
| 15:05 | <foolip> | s/without/with/ |
| 15:47 | <annevk> | foolip: to prevent race conditions you need a global request fullscreen in process flag |
| 15:47 | <annevk> | not even sure if that works :-( |
| 15:48 | <annevk> | not the easiest day after vacation |
| 16:03 | <annevk> | foolip: I posted this thing as a question to the WHATWG list for now |
| 16:05 | <gsnedders> | Hixie: gimme your parser and tell me what I need to build it and how to run it |
| 16:42 | <gsnedders> | jgraham: parser.log is both pretty useless and includes what phase we're in twice |
| 16:42 | <gsnedders> | jgraham: also totally untested |
| 16:47 | <gsnedders> | jgraham: in other news, why does it take two months to be able to push a typo fix in a string to master? code review requirement utterly fails if nothing ever reaches master… |
| 16:50 | <Ms2ger> | gsnedders, feel free to r? me for things that simple :) |
| 16:50 | <jgraham> | gsnedders: It's not that useless since I wrote it to find a bug that I then fixed. It's not intended to be public-facing code so I don't see why you care about test coverage |
| 16:50 | <jgraham> | I agree that the review situation isn't working out |
| 16:51 | <gsnedders> | jgraham: it also has a very significant effect on perf under PyPy |
| 16:51 | <jgraham> | gsnedders: Even when not in use? |
| 16:51 | <gsnedders> | jgraham: It's all the metaclass magic and indirection that's the cost, so yes |
| 16:52 | <gsnedders> | jgraham: i.e., any change of parsing phase is a hash table lookup when it could be a direct reference |
| 16:53 | <jgraham> | gsnedders: It isn't clear to my where the cost comes from since it sets the metaclass to "type" |
| 16:54 | <gsnedders> | jgraham: it's the fact we're doing self.phases["text"] everywhere instead of TextPhase |
| 16:54 | <jgraham> | Oh |
| 16:55 | <jgraham> | It strikes me that PyPy should be able to optimise constant dicts |
| 16:55 | <jgraham> | Can it optimise named tuples? |
| 16:56 | <gsnedders> | PyPy's view is that dicts are hashtables and should be treated as hashtables. You don't expect magic from C++ hashtables, so don't expect magic there. classes on the other hand are quicker. |
| 16:56 | <jgraham> | If you took that view writing a js engine you would have one slow js engine |
| 16:56 | <gsnedders> | but JS doesn't have any separate object type |
| 16:56 | <gsnedders> | or class type |
| 16:56 | <gsnedders> | or what have you |
| 16:57 | <gsnedders> | attribute accesses are fast in PyPy |
| 16:57 | <jgraham> | Saying "we aren't going to optimise a very common case that we could optimise" still doesn't seem like a reasonable way to end up with a fast implementation |
| 16:58 | <gsnedders> | Are you sure parser.log is private? It's exposed in parse.py, which I thought in theory just used public APIs… |
| 16:58 | <gsnedders> | jgraham: go argue in #pypy if you care |
| 16:59 | <jgraham> | What gave to the idea that parse.py is only public apis? |
| 16:59 | <gsnedders> | well it seems like an example application to me |
| 16:59 | <jgraham> | It's only useful to debug the implementation, it's not aimed at end users at all |
| 16:59 | <jgraham> | No, it's a debugging tool |
| 17:00 | <gsnedders> | that's not at all clear |
| 17:01 | <jgraham> | It's certainly not "clear" it's an example application |
| 17:01 | <jgraham> | It's not in the documentation or an examples/ directory |
| 17:05 | <gsnedders> | jgraham: then why do we ship it with releases? |
| 17:08 | <gsnedders> | jgraham: I'd assume anything bundled with the release at the top level is there for example reasons |
| 17:11 | <jgraham> | That seems like a properly strange assumption. It doesn't get installed anywhere other than the library directory |
| 17:11 | <jgraham> | Anyway, this conversation is not going to get us anywhere |
| 17:11 | <jgraham> | What are you trying to achieve? |
| 17:15 | <gsnedders> | I was planning on adding tests and totally refactoring how HTMLParser.__init__(debug=True/False) works. |
| 17:16 | <jgraham> | I think adding tests is harmful |
| 17:17 | <jgraham> | For small values of "harm" |
| 17:17 | <gsnedders> | so you want me to totally redesign how it works without testing it? ;P |
| 17:17 | <jgraham> | Sure |
| 17:18 | <jgraham> | I mean I'm happy for you to totally redesign how it works and produce any output you like that has a broadly comparable feature set |
| 17:18 | <jgraham> | If you want to do something more dramatic e.g. remove it entirely, we should talk more |
| 17:19 | <jgraham> | I don't think that adding yet more code in the form of tests is worthwhile; I think it will add to the maintainace burden rather than reduce it |
| 17:19 | <gsnedders> | I think it's useful. I think it should be there. I'm not entirely convinced it should be private. |
| 17:19 | <gsnedders> | Having a private argument on a function seems… dubious API design, though. |
| 17:22 | <jgraham> | It could be a global variable |
| 17:22 | <gsnedders> | I'd like at least one test for it. If we're having it in parse.py, I'd rather it be tested. AFAIK. |
| 17:22 | <gsnedders> | https://launchpad.net/ubuntu/+source/html5lib/0.9-2 makes it look like I'm not the only person believing it an example. |
| 17:26 | <jgraham> | Well I'm not exactly going to stop you writing a test for it. But I still don't think the tradeoffs are likely to make sense |
| 17:26 | <gsnedders> | I've already written one. It's not exactly hard to do. |
| 17:27 | <jgraham> | And if you want to move parse.py to a debug directory or something, feel free to do so |
| 17:32 | <gsnedders> | Ms2ger: but you're a reviewer on html5lib-tests and haven't even reviewed all my open PRs there! |
| 17:33 | <Ms2ger> | gsnedders, there's too much on my critic dashboard to make it useful for me, so I only review things I'm pinged about :) |
| 17:35 | jgraham | seems to have > 200 things on his critic dashboard :( |
| 20:38 | <caitp> | I still think it's terrible that you can't cause a form control to suffer from bad input by programmatically changing its value, this really sucks for testability =( |
| 20:40 | <Hixie> | isn't there a testing api |
| 20:40 | <Hixie> | web driver or some such |
| 20:40 | <caitp> | webdriver has a huge suite of problems along with it |
| 20:46 | <caitp> | when the choices are "enable special privileges in the browser" or "use the flake-maker", things are pretty unfortunate |
| 22:15 | <TabAtkins> | zcorpan: The other thread was titled "[cssom-view] Allowing scrollIntoView() to only scroll the nearest scroll container" |
| 23:50 | <Hixie> | how are we doing in terms of dropping mutation events? |
| 23:57 | <jgraham> | Heh |
| 23:57 | <roc> | where are proposals for new input-related DOM events specced these days? |
| 23:59 | <Hixie> | roc: the premise of your question is flawed, sadly |
| 23:59 | <Hixie> | oh wait, you mean new ones |
| 23:59 | <Hixie> | not the implemented ones |
| 23:59 | <roc> | elucidate? |
| 23:59 | <roc> | yes |