| 00:00 | <robman> | cool...thnx |
| 00:00 | robman | goes off to do some performance tests |
| 02:54 | <ttepasse> | Hixie: The example in section 10.1.2.2 still uses the Web SQL Database as an example for Web Workers. Maybe that should change to IndexedDB or clientside DB du jour. |
| 03:29 | <annevk> | cpearce, so it sounds like the "fullscreen flag" really ought to be on top-level browsing context instead of Document if all Documents need to have it set |
| 03:30 | <annevk> | cpearce, also, thanks for the great comments |
| 03:39 | <annevk> | oh wait |
| 03:39 | <annevk> | you are saying something else |
| 03:39 | <annevk> | maky |
| 03:39 | <annevk> | mkay* |
| 03:40 | <cpearce> | annevk: heh, comments are all the edge cases I've bumped into so far. ;) hmm... without the Document.fullscreen attribute we can't represent that a document remains in fullscreen state if its fullscreen element is inserted into another document. Unless we cause that to exit fullscreen mode... not sure we want to do that. |
| 03:41 | <annevk> | I guess my idea was that all Documents would be fullscreen if their top-level browsing context is fullscreen |
| 03:42 | <annevk> | and then the documents which are highlighted is determined by the "fullscreen element" |
| 03:43 | <annevk> | are there use cases to make the moving around of elements not do the simplest thing? |
| 03:44 | <annevk> | it seems to me that removing an element that is the fullscreen element should simply clear the fullscreen element for that document and the fullscreen element of any descendant browsing context documents (if any) |
| 03:44 | <annevk> | (and a move in the DOM is a remove followed by an insert so that would behave the same) |
| 03:45 | <cpearce> | that makes sense. I think that's implied by the gecko spec, it's how I've implemented it so far. |
| 03:46 | <annevk> | then for the scenario where a new element becomes the fullscreen element I think nicest would be to find the nearest common ancestor fullscreen element of old and new, remove all old and dispatch events and then set new and dispatch mutation events |
| 03:46 | <annevk> | s/mutation/fullscreenchanged/ |
| 03:47 | <cpearce> | Yup. :) |
| 03:47 | <annevk> | the alternative would be to clear "fullscreen element" everywhere, set it anew, and dispatch fullscreenchanged on all documents |
| 03:48 | <cpearce> | right, but then you'd see fullscreenchange twice on docs that toggle off and back on again. |
| 03:48 | <cpearce> | which could confuse script. |
| 03:48 | <annevk> | good point |
| 03:48 | <annevk> | okay I'll take a look at fixing this |
| 03:49 | <annevk> | time for lunch here |
| 03:49 | <annevk> | thanks! |
| 03:49 | <cpearce> | np. |
| 04:41 | <Hixie> | ttepasse: if you have an example to replace it with, that'd be awesome. send me mail to ian⊙hc if you can help with that. |
| 05:29 | <annevk> | ah, cpearce left |
| 05:33 | <annevk> | so when removing a "fullscreen element" the order of fullscreenchange, fullscreenElement, and mutation listeners, may be somewhat tricky |
| 05:34 | <Hixie> | btw anne i noticed when glancing at your draft that there's a step that says something like "do animations" in what looks like a synchronous algorithm |
| 05:34 | <Hixie> | but animations need to spin the event loop to be done |
| 05:35 | <annevk> | I guess fullscreenchange cannot be synchronous, because then it would be synchronous mutation event of sorts, but then is fullscreenElement changed by the time the mutation listener is there? |
| 05:35 | <annevk> | hmm |
| 05:35 | <annevk> | Hixie, so while doing the animation it needs to spin the event loop? |
| 05:43 | <annevk> | Also, I guess we should name the event fullscreenchange and not fullscreenchanged |
| 06:02 | <Hixie> | annevk: well more likely the algorithm just needs to be async while the event loop continues normally |
| 06:02 | <Hixie> | annevk: but you need to handle what happens if fullscreen mode is exited while that's going on |
| 06:04 | <annevk> | :( |
| 06:48 | <myakura> | MIkeSmith: ping |
| 06:48 | <MikeSmith> | myakura: hey man |
| 06:48 | <MikeSmith> | we are downstairs in front of the Square Tower |
| 06:48 | <myakura> | hiya |
| 06:48 | <myakura> | we? |
| 06:49 | myakura | noticed that he typed MIke and wonder if MIke is TM'd or not. |
| 06:50 | <MikeSmith> | myakura: me & secret visitor |
| 06:53 | <myakura> | hm. I have a meeting at 3pm and will back in an hour. Do you think you two'll still be there? |
| 06:54 | <MikeSmith> | yeah, probably |
| 06:54 | <MikeSmith> | if our battery power holds up |
| 06:54 | <MikeSmith> | but if you don't find us, just ping me |
| 06:54 | <myakura> | alright. |
| 06:55 | <myakura> | MikeSmith: so, I'm writing about the Testing Activity for my next Web Designing article. |
| 06:55 | <MikeSmith> | aha |
| 06:55 | <MikeSmith> | cool |
| 06:55 | <MikeSmith> | I'm happy to talk with you about it |
| 06:56 | <Hixie> | annevk: probably not that big a deal. If anything happens during that step to cancel the fullscreening, just reverse the animation and don't fire anything. |
| 06:56 | <myakura> | MikeSmith: and http://www.w3.org/testing/browser/ says like that it hasn't been chartered yet. |
| 06:56 | <MikeSmith> | myakura: oh, lemme change that now |
| 06:56 | <myakura> | MikeSmith: thanks! |
| 06:57 | <myakura> | okay, bbl. |
| 06:57 | <MikeSmith> | cheers |
| 06:58 | <annevk> | Hixie, yeah, but I guess exitFullscreen() can be invoked then too and requestFullscreen() could be invoked again on some other element |
| 06:58 | <annevk> | Hixie, so there probably needs to be some kind of state for all these edge cases |
| 06:59 | <Hixie> | annevk: ah, yeah, i forgot this was element-based |
| 06:59 | <Hixie> | annevk: btw, did you end up needing anything on the html side? |
| 06:59 | <Hixie> | attribute or anything? |
| 06:59 | <annevk> | yeah we want <iframe allowfullscreen> |
| 06:59 | <Hixie> | is there a bug on it? |
| 06:59 | <annevk> | I will file one |
| 06:59 | <Hixie> | cool |
| 06:59 | <Hixie> | mark it blocker if you need it sooner rather than later |
| 07:00 | <annevk> | and the Gecko guys want to exit fullscreen when you navigate |
| 07:00 | <Hixie> | roger |
| 07:00 | <Hixie> | i can add a hook |
| 07:00 | <annevk> | but I'm not sure how that would work yet with events yet |
| 07:00 | <annevk> | and what happens when you navigate when of the child browsing contexts instead of the top-level |
| 07:01 | <annevk> | sounds good btw |
| 07:26 | <annevk> | man if you want to be explicit about how to deal with moving the fullscreen element around it gets hairy |
| 07:27 | <annevk> | the fullscreen elements can be in the same document, one can be an ancestor document of the other, and they can share a common ancestor |
| 07:33 | <annevk> | in the ancestor case the fullscreen element in the ancestor might also need to be changed depending on what it is |
| 07:34 | <annevk> | i guess it's kind of equivalent to the common ancestor case in that way, except there are no descendant documents to notify |
| 07:48 | <annevk> | hmm |
| 07:48 | <annevk> | "first inclusive ancestor" can probably work |
| 08:03 | <annevk> | * A is the old fullscreen element |
| 08:03 | <annevk> | * DA is A's node document |
| 08:03 | <annevk> | * B is the new fullscreen element |
| 08:03 | <annevk> | * DB is B's node document |
| 08:03 | <annevk> | * X is the first inclusive ancestor common to A and B |
| 08:03 | <annevk> | * Notify changes for descendant documents of X with a non-null fullscreen element |
| 08:03 | <annevk> | * Let Z be all descendants of X that are inclusive ancestors of DB |
| 08:03 | <annevk> | * Does X's fullscreen element change; if so change/notify |
| 08:03 | <annevk> | * Change/notify Z |
| 08:03 | <annevk> | that's a whole lot of complexity for a "simple" feature |
| 08:05 | <annevk> | open question is when the events are best dispatched |
| 08:05 | <annevk> | like do you update all the flags first and then dispatch all the events? |
| 08:06 | <annevk> | or do you do that kind of thing on a per document basis? change flag, dispatch event, change flag in next document, dispatch event in next document, etc. |
| 08:40 | <annevk> | whether X's fullscreen element changes is also fun... |
| 08:41 | <annevk> | - If Z is empty and X's fullscreen element is not B |
| 08:41 | <annevk> | - X needs to change |
| 08:41 | <annevk> | - Let child be X's child document that is also in Z |
| 08:41 | <annevk> | - If child's browsing context container is not X's fullscreen element |
| 08:41 | <annevk> | - X needs to change |
| 08:42 | <annevk> | 90% of the complexity of this feature is for something people will not run into |
| 08:42 | <annevk> | then again I don't really see a good alternative |
| 11:50 | <markss> | Hey I registered for a http://www.w3techcourses.com account but the email failed to send so now I can't confirm my registration. Is there anyone I can contact to fix this? |
| 12:07 | <Lachy> | markss, this channel isn't affiliated with the W3C. Try #sysreq on the W3C's IRC server. |
| 12:29 | <markss> | Lachy: Alright thanks |
| 16:43 | <dglazkov> | good morning, Whatwg! |
| 16:59 | <Hixie> | every time i try to talk to people in the Semantic Web community i have the same troubles |
| 16:59 | <Hixie> | sigh |
| 19:37 | <timeless> | zewt: the reason phone manufacturers rarely update *anything* is because there's no financial incentive to do so, and there is a fiscal penalty for doing so: if it breaks something on an operator's network, the operator will get pissed and ask for money back |
| 19:38 | <timeless> | plus, a mobile vendor (like nokia) makes money by selling (new) units, it doesn't make money from units once they are sold |
| 19:39 | <timeless> | and in the rare case that a browser actually results in revenue (home/search kickbacks), that money is not sent back to a maintenance team for the product that generated it, instead it is treated as some sort of windfall and absorbed by the company or some future product at large team |
| 19:41 | <timeless> | smaug____: fwiw, iPhone Safari doesn't get updated often, just look at how long it took for them to fix the certificate disaster |
| 19:42 | <smaug____> | k |
| 19:42 | smaug____ | is certainly not going to buy any iPhone anyway |
| 19:43 | <smaug____> | N9 might be one option |
| 19:43 | <smaug____> | but it is a bit too expensive |
| 19:43 | <zewt> | ... but google should not have put phone manufacturers in control of updating the browser, just as they're not in control of updating google apps |
| 19:45 | <smaug____> | depends on which browser the OS has |
| 19:46 | smaug____ | hopes phone manufacturers would use some better browsers than stock browser |
| 19:47 | zewt | hopes Google will supply a sane browser (because it's their job) and phone manufacturers won't fragment things further |
| 19:47 | <smaug____> | it is bad if Google controls the whole stack |
| 20:01 | <gsnedders> | smaug____: AIUI unless you pay Google (instead of getting Android for free) you can't ship the Google Apps and any non-standard application |
| 20:02 | <gsnedders> | smaug____: So OEMs take the default apps and Android for free |
| 20:06 | <smaug____> | huh |
| 20:09 | <gsnedders> | smaug____: The Google Apps are non-free. |
| 20:09 | <gsnedders> | smaug____: (like Gmail, Market, etc.) |
| 20:12 | <gsnedders> | smaug____: So you have to get a license from Google to distribute them. They let you have it free in return for advertising revenue, or you can pay and change stuff. |
| 20:12 | <timeless> | zewt: the reason phone manufacturers rarely update *anything* is because there's no financial incentive to do so, and there is a fiscal penalty for doing so: if it breaks something on an operator's network, the operator will get pissed and ask for money back |
| 20:13 | <timeless> | plus, a mobile vendor (like nokia) makes money by selling (new) units, it doesn't make money from units once they are sold. and in the rare case that a browser actually results in revenue (home/search kickbacks), that money is not sent back to a maintenance team for the product that generated it, instead it is treated as some sort of windfall and absorbed by the company or some future product at l |
| 20:13 | <timeless> | arge team |
| 20:13 | <timeless> | hober: out of curiosity, which mobile vendors are actually good at browser updates? |
| 20:13 | <timeless> | smaug____: fwiw, iPhone Safari doesn't get updated often, just look at how long it took for them to fix the certificate disaster |
| 20:13 | <zewt> | deja vu? |
| 20:13 | <timeless> | i'm using irccloud |
| 20:13 | <zewt> | you're repeating yourself, heh |
| 20:13 | <timeless> | i thought i was offline and that things i had said weren't said |
| 20:14 | <timeless> | so i queued them in notepad and then sent them again |
| 20:14 | <timeless> | it didn't occur to me that they would have been sent |
| 20:14 | <timeless> | stuff in other places wasn't sent! |
| 20:14 | <timeless> | i believe gsnedders is correct about the Google Apps |
| 20:14 | <timeless> | which is a pretty good reason for major vendors to pay in |
| 20:14 | <timeless> | as for the n9... dunno |
| 20:15 | <timeless> | what's shocked me of late is that i've met a couple of people interested in n8s |
| 20:15 | <timeless> | s/people/women/ |
| 20:16 | <gsnedders> | timeless: AFAIK almost no vendors pay. |
| 20:27 | <smaug____> | timeless: n8? |
| 20:28 | <smaug____> | isn't that, hmm, old |
| 20:28 | <smaug____> | n9 has got lots of media time in Finland |
| 20:28 | <timeless> | the n8 is what i got nokia to buy for me right before i left |
| 20:28 | <timeless> | and yeah, it's old and sucks |
| 20:28 | <timeless> | but has a 12mp camera |
| 20:29 | <timeless> | oh, and it turns out that the "new" ui for symbian actually eventually made it out the doors! |
| 20:29 | <timeless> | so if i can find Lucy, i can let her consider replacing the old symbian ui with a worse one! |
| 20:29 | <timeless> | (but hey, it's "newer") |
| 20:34 | <Hixie> | does nobody implement body.onmessage? |
| 20:35 | <Hixie> | or does nobody implement window.postMessage()? |
| 20:36 | <timeless> | nobody⊙mo or nobody⊙se ? |
| 20:36 | <zewt> | the latter exists in Chrome, anyway |
| 20:36 | <timeless> | https://developer.mozilla.org/en/DOM/window.postMessage |
| 20:36 | <Hixie> | every browser i've tested fails http://www.hixie.ch/tests/adhoc/dom/web-apps/postMessage/002.html |
| 20:36 | <timeless> | msdn.microsoft.com/en-us/library/cc197057(v=vs.85).aspx |
| 20:36 | <Hixie> | and i can't work out if it's my fault or not :-) |
| 20:37 | <timeless> | it seems that ms has documented body.onmessage |
| 20:37 | <timeless> | FAIL (message not received) |
| 20:37 | <Hixie> | guess i should test windows |
| 20:37 | <timeless> | in IE10 on w8 |
| 20:37 | <Hixie> | IE? |
| 20:37 | <Hixie> | k |
| 20:37 | <Hixie> | so |
| 20:37 | <Hixie> | is it my fault or what |
| 20:37 | <Hixie> | i'm confused |
| 20:37 | <Hixie> | oh i guess i nuke the iframe |
| 20:37 | <Hixie> | maybe that's why |
| 20:37 | <Hixie> | let's fix that |
| 20:38 | <Hixie> | timeless: how about now? |
| 20:39 | <timeless> | FAIL (message not received); TEST FRAME |
| 20:39 | <zewt> | test() not called from anywhere? |
| 20:39 | <timeless> | i.e. there's a frame with that other text |
| 20:39 | <timeless> | but i'm still getting the fail |
| 20:39 | <Hixie> | zewt: 002a.html calls it onmessage |
| 20:39 | <Hixie> | timeless: k. thanks for the help. |
| 20:39 | <Hixie> | i'll figure this out after lunch. |
| 20:39 | <Hixie> | hopefully it's my fault... |
| 20:39 | <Hixie> | bbiab |
| 20:44 | <smaug____> | Hixie: FF9/10 have "onmessage" in document.body |
| 20:53 | <timeless> | fwiw, i get the same results in my slightly dated 32bit Nightly on w8 as i do w/ IE10 |
| 21:03 | <zcorpan> | Hixie: i guess browsers don't support <body onmessage> properly |
| 22:07 | <Hixie> | zcorpan: seems that way |
| 22:12 | <Hixie> | yup, looks like no browser implements onmessage="" right |
| 22:12 | <Hixie> | oh well |
| 22:12 | zcorpan | files a bug |
| 22:12 | <Hixie> | http://www.hixie.ch/tests/adhoc/dom/web-apps/postMessage/002.html if you need a testcase |
| 22:12 | <Hixie> | 003.html tests window.onmessage and seems to work everywhere |
| 22:15 | <jgraham> | Hixie: Convert the tests to something that can be put in the oficial testsuite, please :) |
| 22:15 | <Hixie> | is there documentation on how to do that? |
| 22:16 | <jgraham> | http://www.w3.org/html/wg/wiki/Testing/Authoring/ |
| 22:17 | <Hixie> | wait why does a test have to include a js file? |
| 22:17 | <Hixie> | i just want to report the result to the harness |
| 22:17 | <jgraham> | Because there are tradeoffs in both directions |
| 22:17 | <jgraham> | And this is the one we went with |
| 22:17 | <Hixie> | wow this is far too complicated |
| 22:18 | <Hixie> | the "basic usage" section of the documentation of the library is longer than most test harnesses i've written :-P |
| 22:18 | <jgraham> | Hixie: Having used the "just report a result" system at Opera, it turns out that often "wow this is far too simplistic" |
| 22:19 | <jgraham> | Anyway in your case there's no reason not to include the js file |
| 22:20 | <Hixie> | tests should never include anything other than what is needed to run the test |
| 22:21 | <jgraham> | I really don't see the problem here |
| 22:22 | <jgraham> | If it actually changes the results you get, that's differnet |
| 22:22 | <jgraham> | But part of the point is that there isn't a way to "just report the results to the harness" |
| 22:22 | <Hixie> | the test is 21 lines long. The script library is 1689 lines long. Reporting the result takes one line of code (if (parent.report) (parent.report(result))). |
| 22:22 | <Hixie> | that's the problem |
| 22:23 | <Hixie> | er, with one fewer parenthesis |
| 22:23 | <jgraham> | That's not a problem |
| 22:23 | <jgraham> | Also, one of the main points is that there isn't a harness |
| 22:23 | <jgraham> | everyone does something slightly different |
| 22:24 | <Hixie> | including a library that is 80 times bigger than the test is a problem, imho. it means that the bulk of what the test is really testing has nothing to do with what it is trying to test. |
| 22:24 | <jgraham> | We use some weird POST-to-localhost thing that will hopefully be replaced soon. Mozilla use moxhitests. Webkit use something that prints to stdout (I think?) |
| 22:24 | <jgraham> | The library almost entirely assumes a good ecmascript implementation |
| 22:25 | <jgraham> | That turns out to be a reasonable assumption |
| 22:26 | <jgraham> | I consider the requirement to run the test in an iframe or popup window to be much more worrying |
| 22:27 | <Hixie> | to each his own, i guess |
| 22:29 | <zewt> | when it comes to official test sets, i hope not :) |
| 22:37 | <Hixie> | i don't understand opera's behaviour in http://www.hixie.ch/tests/adhoc/dom/web-apps/postMessage/001.html |
| 22:38 | <Hixie> | webkit's behaviour is interesting. looks like it handles both postMessage(data, [], '*') and postMessage(data, '*', []) |
| 22:38 | <Hixie> | might be worth putting that in the spec |
| 22:48 | <zcorpan> | ugh. please no |
| 22:49 | <Hixie> | looks like only webkit implements it at all in a usable way, so i've changd the spec to match webkit |
| 22:49 | <Hixie> | the number of people who have gotten confused as to the correct order of those arguments is sufficiently high that i think it's worth it |
| 22:49 | <Hixie> | there doesn't seem to be a downside really |
| 22:50 | <zcorpan> | O_O |
| 22:50 | <zewt> | making code 50/50 inconsistent instead of people getting an error and learning to do it right is a very clear downside |
| 22:51 | <zcorpan> | i'm pretty sure our developers will refuse to implement that |
| 22:51 | <Hixie> | well opera's implementation of the spec so far seems quite broken anyway, so... :-) |
| 22:51 | <zcorpan> | what's broken? |
| 22:52 | <Hixie> | you fire a SYNTAX_ERR if there's three arguments |
| 22:52 | <Hixie> | regardless of what they are |
| 22:52 | <Hixie> | unless they're both '*' |
| 22:52 | <Hixie> | (or presumably any valid origin, i haven't tested other origins) |
| 22:53 | <annevk> | what did you pass as argument? |
| 22:55 | <zcorpan> | i'll have to look at that tomorrow i guess. now sleep |
| 22:55 | <annevk> | Hixie, I think we throw because you pass the arguments in the wrong order |
| 22:55 | <Hixie> | i tried both orders |
| 22:55 | <annevk> | targetOrigin comes before transfer |
| 22:55 | <Hixie> | i tried both orders |
| 23:07 | <Hixie> | hey, check it out. my test was bogus after all and opera is not buggy, and webkit doesn't support both orders |
| 23:07 | <Hixie> | <-- idiot |
| 23:08 | <Hixie> | still, opera should throw, and does not, for postMessage('', '*', '*') |
| 23:08 | <annevk> | if only you could read what you wrote the first time around |
| 23:08 | <gsnedders> | Hixie: throw TypeError? |
| 23:08 | <Hixie> | yeah |
| 23:24 | <annevk> | cpearce, if fullscreen element or its ancestor is removed from document and that document has descendant documents with non-null fullscreen elements, should we fire events on those documents? |
| 23:24 | <annevk> | cpearce, in Gecko per http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1210 that does not even seem possible |
| 23:24 | <annevk> | cpearce, also, I guess the other question is in what scenario something like that happens and whether we need to deal with it |
| 23:25 | <cpearce> | annevk: if the descendents change out of full-screen mode due to an ancestor being removed, then yes, we should fire fullscreenchanged in them. |
| 23:26 | <annevk> | cpearce, but as my test shows in e.g. Gecko you no longer have Document objects in such a scenario |
| 23:27 | <cpearce> | annevk: hmmm.... |
| 23:27 | <annevk> | I also sort of fail to see the use case for catching this case, but it's not too hard |
| 23:28 | <annevk> | The other question I had was about order of events relative to setting the "fullscreen element" |
| 23:28 | <annevk> | do you fire the event after you have set/unset "fullscreen element" for the entire chain or do you do it per document? |
| 23:29 | <cpearce> | I queue a task to fire the event as I traverse the doc tree making changes. |
| 23:30 | <cpearce> | I'm in fact firing the change events for enter before change events for exit, but that's easily changeable. |
| 23:30 | <annevk> | e.g. say the order becomes top-down when setting and bottom-up when unsetting, if I set and there's two documents, and the event dispatches on the first, the second still has a null fullscreen element? |
| 23:31 | <cpearce> | The events won't dispatch until all docs in the tree have their fullscreen element set |
| 23:31 | <annevk> | but you just said you fire them as you traverse? |
| 23:31 | <annevk> | oh, queue a task |
| 23:31 | <cpearce> | bingo. |
| 23:32 | <annevk> | but then you can observe state separately |
| 23:32 | <cpearce> | how? |
| 23:32 | <annevk> | state change* e.g. in mutation events |
| 23:33 | <annevk> | or from a timer |
| 23:33 | <annevk> | state change and event dispatch should always be coupled I think |
| 23:34 | <annevk> | and I guess it makes sense you do it on a per-document basis since they might not be all related browsing contexts |
| 23:34 | <cpearce> | I'm not sure what you mean. All the state change happens in the task which queues tasks to fire the events. |
| 23:35 | <annevk> | doesn't that mean you can have other tasks running before the event is dispatched? |
| 23:35 | <cpearce> | yep... |
| 23:35 | <annevk> | e.g. in XHR you queue a task to change readyState and dispatch an event |
| 23:36 | <annevk> | I think pretty much all APIs work that way |
| 23:36 | <cpearce> | we have the same problem with the video spec, state can change before the event runs. |
| 23:36 | <cpearce> | but fortunately you can query Document.fullscreen to tell if the target has entered or exited fullscreen... |
| 23:38 | <annevk> | I don't really know the media API |
| 23:39 | <annevk> | so why not have a single task which changes state and dispatches the event? |
| 23:43 | <cpearce> | annevk: It is simpler to implement with the events queued, since if you dispatch them synchronously in the task to change state, the world could change underneath you in the event handler. I can't really think of any reason from a user's perspective though. |
| 23:46 | <annevk> | cpearce, so is requestFullscreen and exitFullscreen fully synchronous then? |
| 23:46 | <cpearce> | annevk: at the moment they are for us. |
| 23:46 | <cpearce> | we don't have an animation for enter, if you wanted an animation I think you'd need to make them async though. |
| 23:47 | <annevk> | yeah, it seems like we would want that down the road |
| 23:47 | <cpearce> | we have a bug on file for that too. |
| 23:47 | <annevk> | I wonder what sicking thinks of changing state sync and notifying async |
| 23:49 | <annevk> | I guess you pretty much have to change state sync for :fullscreen |
| 23:51 | <annevk> | and someone needs to verify for me this doesn't fuck with "unit of related similar-origin browsing contexts" |
| 23:51 | <annevk> | because I cannot really work it out |
| 23:52 | <annevk> | I guess it might in a way |
| 23:53 | <annevk> | cpearce, what if the top-level browsing context is already busy while you call requestFullscreen, don't you get blockage? |
| 23:53 | <annevk> | I guess currently there's no multi-process going on for that in Gecko |
| 23:54 | <cpearce> | mmmm.... we have one process, and are moving to conceptually one process per tab, so that can't happen (I think...). |
| 23:55 | <cpearce> | and in multi-process firefox I dispatch an event to the chrome process to make it fullscreen, so it is technically async to make the window full-screen, but I've not focused too much on that yet. |
| 23:56 | <cpearce> | since we're a few months out from enabling multi-process by default. |
| 23:58 | <annevk> | yeah I guess the method can just wait |
| 23:58 | <annevk> | you can probably not cause deadlock so I guess it should be okay, but it would be nice if someone could verify |
| 23:59 | <annevk> | don't really want to prevent implementations that have multi-process outside per-tab |
| 23:59 | <annevk> | I think e.g. Chrome wanted to move in that direction |
| 23:59 | <cpearce> | yeah. |