| 00:00 | smaug | wonders if intersection observer has any good tests |
| 00:11 | <jsbell> | smaug: https://github.com/w3c/web-platform-tests/pull/4384 in theory... |
| 00:12 | smaug | is thinking about cases like moving elements to other documents etc |
| 00:18 | <jsbell> | smaug: spec/test author says no. He also says "patches welcome!" :) |
| 00:18 | <smaug> | heh |
| 00:18 | <jsbell> | (admitting it's a major omission) |
| 00:20 | <jyasskin> | smaug: An element's browsing context would be the element's node document's browsing context, right? https://dom.spec.whatwg.org/#concept-node-document to https://html.spec.whatwg.org/#concept-document-bc |
| 00:25 | <smaug> | jyasskin: sure, but it isn't defined anywhere what element's browsing context is, right? |
| 00:25 | <jyasskin> | Yeah, HTML always says "foo's node document's browsing context" or "iframe element's browsing context". |
| 00:26 | <jyasskin> | I believe the second means the nested browsing context, which makes it less straightforward to just define "element's browsing context". |
| 08:43 | <annevk> | jyasskin: smaug: we should probably just change it to element's node document's browsing context, unless it's actually element's associated browsing context (the nested browsing context) |
| 08:43 | <annevk> | jyasskin: smaug: I'd happily fix instances/take PRs |
| 09:01 | <annevk> | zcorpan: do you have a pointer to the Safari TP crash issue? |
| 09:03 | <zcorpan> | annevk: https://bugs.webkit.org/show_bug.cgi?id=167730 |
| 09:05 | <annevk> | zcorpan++ for https://github.com/w3c/web-platform-tests/pull/4690 |
| 09:05 | annevk | created that mess |
| 09:18 | <zcorpan> | annevk: it was fun to see if my idea would work, which it did. but it's kinda non-obvious. if we need this sort of setup in more places we should think of better ways to do it in testharness |
| 09:19 | <annevk> | zcorpan: I don't think we generally need this |
| 09:19 | <zcorpan> | yeah |
| 09:19 | <annevk> | zcorpan: this is mostly for aligning legacy setups |
| 09:21 | <zcorpan> | although "missing" assertions because an early but less important assertion failed is something people find annoying sometimes, i think. |
| 12:40 | <smaug> | what does step() mean with async tests? why is that needed, why not just use asserts? |
| 12:40 | <smaug> | jgraham: ^ |
| 12:42 | <smaug> | another question, why does http://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/embedded-content/the-canvas-element/toBlob.jpeg.html work? http://searchfox.org/mozilla-central/source/testing/web-platform/tests/common/canvas-tests.js#53 seems to call t.done() before the callback to toBlob is called |
| 12:47 | <annevk> | smaug: it helps catch the exception |
| 12:47 | <smaug> | annevk: step() ? but it isn't needed, right? asserts without step work fine? |
| 12:48 | <annevk> | smaug: no they don't work fine, since there's no global exception handler, unless you're creating a standalone test |
| 12:48 | <smaug> | annevk: I mean if one has simple test without any possible exceptions |
| 12:49 | <annevk> | smaug: if it's a single test you can use http://testthewebforward.org/docs/testharness-library.html#single-page-tests |
| 12:49 | <smaug> | and async.. |
| 12:49 | <annevk> | smaug: yes, you can still use that |
| 12:50 | <smaug> | so, step isn't needed |
| 12:50 | <smaug> | it can be useful in some cases |
| 12:50 | <annevk> | smaug: only if you explicitly call async_test() |
| 12:50 | <smaug> | sure, t = async_test(); assert(); t.done() |
| 12:51 | smaug | is still puzzled why asserts work even _after_ calling done(); |
| 12:51 | <annevk> | smaug: no, that's not okay |
| 12:51 | <smaug> | why not? |
| 12:51 | <annevk> | smaug: because then it's unclear to what test the assert belongs |
| 12:55 | smaug | assumes if there is just one async tests not-done, asserts would be bound to that |
| 12:56 | <smaug> | and based on a patch that works |
| 12:56 | <smaug> | and http://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/embedded-content/the-canvas-element/toBlob.jpeg.html |
| 12:56 | <smaug> | that calls assert asynchronously |
| 12:56 | <smaug> | certainly outside any step |
| 12:57 | <smaug> | (and even after t.done()) |
| 12:58 | <annevk> | smaug: that it works after t.done() should be enough of an indication that it isn't bound to the test whatsoever... |
| 12:58 | <smaug> | what you mean with that |
| 12:58 | <annevk> | exactly what I wrote |
| 12:59 | <smaug> | harness says the test passed |
| 12:59 | <smaug> | testname "toBlob with image/jpeg returns a JPEG Blob" passed |
| 12:59 | <Ms2ger> | _addTest does special things |
| 13:00 | <annevk> | Oh yeah, that resource doesn't look like a normal assert either |
| 13:00 | <annevk> | it uses a* |
| 13:01 | <Ms2ger> | smaug, I'm not sure I follow; done() is called after step() |
| 13:01 | <smaug> | Ms2ger: done is called before the assert |
| 13:01 | <smaug> | in http://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/embedded-content/the-canvas-element/toBlob.jpeg.html |
| 13:01 | <Ms2ger> | No... |
| 13:01 | <Ms2ger> | Oh, wait |
| 13:01 | <smaug> | I didn't say done is called before step |
| 13:01 | <Ms2ger> | Is toBlob sync? |
| 13:01 | <smaug> | no |
| 13:01 | <Ms2ger> | I guess that would make no sense |
| 13:03 | <Ms2ger> | Yeah, that test is wrong |
| 13:03 | <Ms2ger> | I should find some time to make those canvas tests make sense |
| 13:04 | <smaug> | Ms2ger: so why does the test work? |
| 13:04 | <smaug> | in other words, what is the meaning of done() ? |
| 13:05 | <Ms2ger> | "work" how? |
| 13:05 | <Ms2ger> | I don't think the test checks anything |
| 13:05 | <smaug> | oh, hmm |
| 13:06 | <smaug> | do we get pass even without any asserts? |
| 13:06 | <Ms2ger> | Yes |
| 13:06 | <smaug> | aha, that is a bug in framework |
| 13:06 | <smaug> | ok, I see |
| 13:06 | <smaug> | and asserting after done() should cause failure |
| 13:09 | <Ms2ger> | That would mean the test could never finish |
| 13:09 | <Ms2ger> | Anyway, I'll go and fix these |
| 13:10 | <smaug> | Ms2ger: mochitest does warn if you don't have any asserts, and it does warn if you try to use ok() or such after finish() |
| 13:14 | <Ms2ger> | https://github.com/w3c/web-platform-tests/pull/4753 |
| 13:15 | <nox> | * |
| 13:15 | <nox> | focus fail |
| 13:28 | <jgraham> | smaug: Warning for assert-after-done is probably possible, but it's not possible to make it affect the test outcome because it would obviously be racy. |
| 13:29 | <jgraham> | A test with no asserts seems legit e.g. img.onload = done; img.onerror = () => assert_unreached("image should not have errored"); |
| 13:29 | <jgraham> | smaug: done() and t.done() and different things |
| 13:30 | <jgraham> | *are |
| 13:30 | <jgraham> | One says that a particular async test is finsihed, the other says that the entire page is finished (assuming there are no more tests which are not themselves finished) |
| 13:30 | <jgraham> | If you have only a single test in a file you can just write bare asserts |
| 13:31 | <jgraham> | If you want multiple tests in a file they have to be called inside a specific step otherwise they will simply cause the page to have status ERROR without failing any specific test |
| 15:54 | <MikeSmith> | zcorpan: count me a bit amazed but genuinelyhappy https://git.gnome.org/browse/libxslt/commit/?id=5f472f85d074828316ecfa8e5df91e6be4163aeb |
| 15:56 | <zcorpan> | MikeSmith: š |
| 15:56 | <zcorpan> | time to write some sweet XSLT |
| 16:01 | <nox> | zcorpan: My condolences. |
| 16:01 | <MikeSmith> | zcorpan: haha š |
| 16:06 | <smaug> | jgraham: why is test without asserts ok? I would expect img.onload to require something like function() { assert(true); done(); } |
| 16:09 | <jgraham> | smaug: Congratulations you are the first person ever to ask for more boilerplate in a wpt :) |
| 16:09 | <smaug> | ha |
| 16:09 | <smaug> | I'm trying to ask API I could understand and which would be less error prone |
| 17:18 | <zcorpan> | smaug: a test passes if no assertions fail. so no assertions means it passes |
| 17:18 | <smaug> | no assertions most likely mean buggy tests |
| 17:19 | <smaug> | like in toBlob.jpeg.html case |
| 17:41 | <annevk> | MikeSmith: so XSLT now depends on non-standardized features? |
| 17:43 | <MikeSmith> | I guess XSLT itself doesnāt, but in practice getting the two most-commonly used XSLT engines to output <!DOCTYPE html> does |
| 17:43 | <MikeSmith> | now |
| 17:46 | <MikeSmith> | anyway XSLT overall is a ādoctor it hurts when I do thisā thing but a lot people still use it so it seems useful to mitigate bad consequences of it when we can |
| 17:47 | <MikeSmith> | I just want people to be able to use <!DOCTYPE html> in their docs without their toolchain getting in teh way |
| 17:49 | <MikeSmith> | make fugly <!DOCTYPE html SYSTEM "about:legacy-compat"> the forgottent footnote in history it deserves to be |
| 17:50 | <MikeSmith> | and further eliminate the misunderstanding that people continue to have that the doctype means anything or that browser do anything with it other than just using it as signal to not switch into quirks mode |
| 18:03 | <gsnedders> | why am I trawling through MO-archive drama? |
| 18:03 | <gsnedders> | this isn't productive. |
| 18:11 | <annevk> | gsnedders: work on WPT docs š |
| 18:36 | <annevk> | MikeSmith: I made a mistake in my shadow tree review |
| 18:36 | <annevk> | MikeSmith: you were right |
| 18:36 | <annevk> | MikeSmith: a shadow tree has a root that's a shadow root |
| 18:36 | <annevk> | MikeSmith: and that is the thing that has a host |
| 18:36 | <annevk> | MikeSmith: sorry |
| 18:39 | <Domenic> | annevk: this seems like a perfect case for pushing a fixup for him :) |
| 18:40 | <annevk> | Domenic: MikeSmith: I'm happy to fix it tomorrow |
| 18:42 | <boogyman> | MikeSmith: are you trying to say that about:legacy-compat should be used? |
| 18:50 | <annevk> | MikeSmith++ |
| 19:04 | <MikeSmith> | annevk+++ š» |
| 19:04 | <MikeSmith> | boogyman: saying that it should not be used |
| 19:05 | <MikeSmith> | saying we should help it along to death |
| 19:11 | <MikeSmith> | right now the spec says, Hereās what a doctype looks like: <!DOCTYPE html>. Itās just that simple!... Oh, except hereās this other crazy-ass bit that literally only 0.1% of you reading this will even understand the purpose of but that weāre gonna just drop it in here anyway |
| 19:12 | <annevk> | Domenic: https://github.com/whatwg/fetch/issues/479 could use your input somewhere today |
| 19:12 | <annevk> | (your timezone) |
| 19:22 | <jyasskin> | annevk: FWIW, I agree with your preference that `{}` empty the header list and `undefined` pass it through, and with bz's preference for having a general rule that absent braced things are equivalent to `{}`, so I'm no help. |
| 19:25 | <annevk> | jyasskin: good times |
| 19:26 | <annevk> | jyasskin: maybe we need [AllowOmission] |
| 20:08 | <jsbell> | Gecko peeps: https://developer.mozilla.org/en-US/Firefox/Releases/51 and MDN claim Storage API's navigator.storage.estimate() is in 51 but I'm not seeing navigator.storage existing. Patch is https://bugzilla.mozilla.org/show_bug.cgi?id=1267941 - am I missing something? |
| 20:15 | <jgraham> | jsbell: Secure context only, perhaps? |
| 20:15 | <jsbell> | jgraham: was trying it in console from https site, hrm... |
| 20:16 | <jgraham> | jsbell: WFM in nightly at least |
| 22:10 | <Domenic> | MikeSmith: botie has gone missing, making it hard for me to deal with zcorpan having gone missing :P |
