| 00:00 | <wanderview> | JakeA: which change? lost context |
| 00:07 | <wanderview> | JakeA: oh, if you mean the VARY:* thing... our network stack treats VARY:* as never match, but our Cache implements whats currently in the SW spec |
| 00:08 | <wanderview> | I think we should just reject cache.put() if the response has VARY:* |
| 00:09 | <wanderview> | and add/addAll |
| 00:26 | <gsnedders> | wait, does the CSSOM spec still not define element.style.background = "green"? |
| 00:27 | <gsnedders> | i.e., the named property setter (if I'm recalling my WebIDL terminology) on CSSStyleDeclaration? |
| 00:38 | <karlcow> | gsnedders: this reminds me of |
| 00:38 | <karlcow> | > The CSSOM spec isn't crystal clear on which behavior is correct, so they might both be considered valid. |
| 00:38 | <karlcow> | https://miketaylr.com/posts/2014/01/when-should-a-stylesheetlist-update.html |
| 00:39 | <karlcow> | not related. :) but CSSOM seems to forget a couple of things |
| 00:40 | <gsnedders> | karlcow: tbf the CSSOM spec was totally unmaintained for such a long while it's not entirely surprising it isn't perfect |
| 00:40 | <karlcow> | https://miketaylr.com/posts/2014/01/yui-set-style-differences.html |
| 00:40 | <karlcow> | :) |
| 00:40 | <karlcow> | gsnedders: yup yup. |
| 00:40 | <karlcow> | part of the funny things. |
| 00:43 | <gsnedders> | that involves YUI, I ain't touching that link :) |
| 00:47 | <karlcow> | In fact, it's about different implementations of setProperty method of CSSStyleDeclaration in different browsers :) |
| 00:47 | <karlcow> | but yeah |
| 00:47 | <gsnedders> | I just have had enough of YUI for my lifetime. |
| 01:32 | <MikeSmith> | zcorpan: if you could go through http://goo.gl/sJ34Xj and resolve any really old/stale bugs you don't care about keeping open, I'd appreciate it. Anything you would actually still like to see fixed, please do keep it open. |
| 01:33 | <MikeSmith> | zcorpan: for open bugs that we would really like to see fixed, I think eventually we might want to migrate them all to https://github.com/validator/validator/issues But I don't want to do that just yet |
| 09:23 | <mounir> | Ms2ger: ping |
| 09:23 | <Ms2ger> | Here |
| 09:23 | <mounir> | Ms2ger: is moving from Foo(DOMString) to Foo(sequence<DOMString>) forward compatible per webidl? |
| 09:24 | <Ms2ger> | No |
| 09:25 | <mounir> | interesting |
| 09:25 | <mounir> | would you care to elaborate? |
| 09:26 | <Ms2ger> | Passing a string to a method that takes sequence<DOMString> would throw, I think |
| 09:27 | <Ms2ger> | Oh, no |
| 09:28 | <Ms2ger> | It would be interpreted as a sequence of characters, it seems |
| 09:28 | <annevk> | you'd need to accept either |
| 09:29 | <mounir> | Ms2ger: Foo(DOMString) extended to accept DOMString _or_ sequence<DOMString> would work then? |
| 09:30 | <Ms2ger> | Sure |
| 09:42 | <annevk> | GPHemsley: you around? |
| 09:43 | <annevk> | GPHemsley: I want to outline some stuff that compliments https://mimesniff.spec.whatwg.org/ |
| 09:43 | <annevk> | GPHemsley: in particular, we need a place to define how the no-sniff header influences various contexts, such as <script>, <link rel=stylesheet>, etc. |
| 09:44 | <annevk> | GPHemsley: I was thinking of jotting notes down on a wiki page, then getting that implemented, and then filing bugs to standardize it |
| 10:46 | <annevk> | jgraham: can web-platform-tests handle the case where I issue a HEAD and it responds with something that includes a body? |
| 11:12 | <jgraham> | annevk: Yes |
| 12:22 | <GPHemsley> | annevk: I'm here now, for a moment. But if you want to write stuff on the wiki, I can look at it when I have more time. |
| 12:37 | <annevk> | Is there a way to reset a git repo? |
| 12:37 | <annevk> | E.g. currently web-platform-tests suggests I've made some change to "tools" but I've no idea how to undo that |
| 12:38 | <GPHemsley> | git reset --hard |
| 12:38 | <jgraham> | Ah, well tools is a submodule (if you pulled recently) |
| 12:38 | <jgraham> | So it's a bit more compilcated |
| 12:38 | <annevk> | "fatal: Not a git repository: tools/../.git/modules/tools" |
| 12:38 | <jgraham> | Yeah, please rm -r that folder |
| 12:38 | <jgraham> | i.e. .git/modules/tools |
| 12:39 | <jgraham> | Then git submodule update --init --recursive |
| 12:40 | <zcorpan> | fatal: Not a git repository: ../.git/modules/tools |
| 12:40 | <zcorpan> | Unable to find current revision in submodule path 'tools' |
| 12:40 | <zcorpan> | after those instructions |
| 12:40 | <annevk> | yeah |
| 12:40 | <annevk> | same |
| 12:42 | <jgraham> | Hmm |
| 12:42 | <jgraham> | git is really properly terrible at deleing subrepos |
| 12:42 | <jgraham> | So does .git/modules/tools exist at all? |
| 12:42 | <zcorpan> | no |
| 12:43 | <zcorpan> | html5lib and resources exist in .git/modules/ |
| 12:44 | <annevk> | same |
| 12:44 | <zcorpan> | now `git fetch upstream` also results in fatal: Not a git repository: tools/../.git/modules/tools :-) |
| 12:45 | <jgraham> | so I would kind of expect git submodule init to fix this |
| 12:46 | <jgraham> | Maybe delete the tools/ directory and everything under .git/modules and git submodule update --init --recursive again? |
| 12:47 | <annevk> | "fatal: Not a git repository: ../.git/modules/resources" |
| 12:47 | <annevk> | "Unable to find current revision in submodule path 'resources'" |
| 12:47 | <GPHemsley> | Make sure .git/config is in the proper state |
| 12:47 | <annevk> | blargh |
| 12:47 | <jgraham> | Yeah remove resources/ too |
| 12:47 | <annevk> | I did |
| 12:47 | <zcorpan> | same result here |
| 12:48 | <jgraham> | So you have no $WPT_ROOT/resources directory and no $WPT_ROOT/tools directory? |
| 12:48 | <jgraham> | and $WPT_ROOT/.git/modules is an empty directory? |
| 12:49 | <zcorpan> | yep. i tried removing the modules directory itself also but no difference |
| 12:49 | <jgraham> | Hmm, well I just did exactly that and it wfm |
| 12:49 | <annevk> | jgraham: yeah works |
| 12:49 | <annevk> | jgraham: didn't realize what you meant by resources/ thought you meant .git/modules/resources |
| 12:49 | <annevk> | jgraham: one final question, how do I start the server again? |
| 12:50 | <zcorpan> | [submodule "tools"] |
| 12:50 | <zcorpan> | url = https://github.com/w3c/wpt-tools.git |
| 12:50 | <zcorpan> | GPHemsley: ^ |
| 12:50 | <jgraham> | https://pastebin.mozilla.org/8827681 |
| 12:50 | <jgraham> | annevk: ./serve |
| 12:50 | <jgraham> | in the root directory |
| 12:50 | <GPHemsley> | zcorpan: If things are in a hybrid state of deletion, you may want to remove that section of the file and reinit the submodules |
| 12:50 | <zcorpan> | ah. ok now it seems to work |
| 12:51 | <zcorpan> | excellento. thx |
| 12:52 | <GPHemsley> | annevk: Any pressing questions you have for me before I leave? |
| 12:52 | <annevk> | GPHemsley: no, thanks |
| 12:52 | <GPHemsley> | OK, then I'll just leave you with the reminder of the existence of https://wiki.whatwg.org/wiki/Contexts |
| 12:52 | <GPHemsley> | Let me know where you need me to look later |
| 13:07 | <annevk> | jgraham: see https://github.com/w3c/web-platform-tests/pull/1697 for my test |
| 13:37 | <JakeA> | annevk: given that fetch/XHR are HTTP APIs, and a response inc. body from a HEAD request is a violation, is it fair or not that the browsers try and do something to error correct? |
| 13:37 | <JakeA> | I can argue it both ways |
| 13:38 | <annevk> | Yes :-) |
| 13:40 | <annevk> | JakeA: since even Content-Length means something different arguably throwing away the body is sane |
| 13:42 | <annevk> | JakeA: what IE does makes no sense btw |
| 13:55 | <wanderview> | annevk: is this a general problem or does it sound chrome specific to you? https://code.google.com/p/chromium/issues/detail?id=448427 |
| 13:57 | <wanderview> | its unclear to me if "cross origin favicon tainting" is a consequence of the way chrome does content process caching or a general web attack |
| 13:58 | <annevk> | wanderview: I'm not sure what that means |
| 13:59 | <annevk> | wanderview: not sure why a favicon is different |
| 13:59 | <wanderview> | I'm going to assume its a chrome-specific issue |
| 14:00 | <smaug____> | who wants to spec how resize event works |
| 14:01 | <annevk> | smaug____: zcorpan |
| 14:02 | <smaug____> | good |
| 14:04 | <MikeSmith> | what's the best way for a normal person to collect usage data on a particular API? |
| 14:05 | <MikeSmith> | other than by browser-project telemetry I mean |
| 14:05 | <annevk> | MikeSmith: there's not really any other reliable way |
| 14:06 | <wanderview> | annevk: how will the fetch issue solve the HEAD method thing for Cache? |
| 14:06 | <annevk> | wanderview: it won't, that was the point |
| 14:06 | <JakeA> | It won't |
| 14:06 | <wanderview> | oh... "this issue" means the SW issue, not the fetch issue you linked in the first sentence |
| 14:07 | <wanderview> | its morning in america |
| 14:07 | <annevk> | typical wanderview coffee excuse :p |
| 14:07 | <wanderview> | annevk: if only I could use that in the afternoon too... |
| 14:07 | wanderview | feels slightly dirty for quoting Ronald Reagan. |
| 14:08 | <JakeA> | That was all good fun, been a while since I did some low-level HTTP testing |
| 14:16 | <wanderview> | JakeA: speaking of which... I remember you did some of that to see what browsers do when the body is truncated by a network error, right? |
| 14:18 | <wanderview> | guess I'm still wondering what to do here: https://github.com/slightlyoff/ServiceWorker/issues/665 |
| 14:18 | <zcorpan> | smaug____: http://dev.w3.org/csswg/cssom-view/#resizing-viewports |
| 14:18 | <zcorpan> | smaug____: https://html.spec.whatwg.org/multipage/webappapis.html#run-the-resize-steps |
| 14:30 | <JakeA> | wanderview: yeah https://github.com/slightlyoff/ServiceWorker/issues/362#issuecomment-48612616 |
| 14:38 | <wanderview> | JakeA: yea... it just seems a bit scary to me to potentially have truncated values in Cache |
| 14:38 | <wanderview> | JakeA: I wonder if we should have some kind of strict mode in Cache that rejects if content-length is wrong |
| 14:38 | <wanderview> | rather than make all script authors deal with this condition themslves |
| 14:41 | <smaug____> | zcorpan: that is surprising |
| 14:42 | <zcorpan> | smaug____: what? that it's specced? |
| 14:42 | <smaug____> | the behavior is a bit surprising |
| 14:42 | <smaug____> | I would have expected we spec resize to fire around animation frame callbacks |
| 14:42 | <smaug____> | but ok, perhaps this is fine too |
| 14:43 | <smaug____> | why isn't it just using a task? |
| 14:43 | <smaug____> | to fire the event |
| 14:44 | smaug____ | hasn't looked at 8.1.4.2 Processing model for ages |
| 14:44 | <smaug____> | very different to how Gecko works :/ |
| 14:46 | <smaug____> | wait, I'm misreading it or what.. "An event loop must continually run through the following steps for as long as it exists:" ... "For each fully active Document in docs, run the animation frame callbacks for that Document, passing in now as the timestamp." |
| 14:46 | <smaug____> | I see, that mixes animation frame handling into the event loop |
| 14:48 | <JakeA> | wanderview: If we need a strict mode, shouldn't it go on fetch()? |
| 14:48 | <smaug____> | so fine (just differently modeled comparing to what I have in mind for animation frame handling and such) |
| 14:49 | <wanderview> | JakeA: well, its Cache that has to decide what to do if the body stream is truncated, no? |
| 14:49 | <zcorpan> | smaug____: it's intended to fire just before animation frame callbacks |
| 14:49 | <smaug____> | but end result should be the same |
| 14:49 | <zcorpan> | smaug____: it was using a task before but we changed it to sync with animation frames since impls do that or want to do that |
| 14:50 | <wanderview> | JakeA: I mean... content uses fetch() can decide what to do if the Response.body stream gives them an error |
| 14:50 | <JakeA> | wanderview: hmm yeah, good point |
| 14:50 | <wanderview> | JakeA: but if there is no way for Cache to surface an error after resolving Cache.put() promise... then it needs some strategy for handling it |
| 14:50 | <smaug____> | zcorpan: some impls do that |
| 14:50 | <smaug____> | but ok |
| 14:51 | <smaug____> | I think this is fine |
| 14:51 | <zcorpan> | smaug____: it's possible that the event loop spec is wrong and should be changed in some way. i think bz had vague concerns about it not matching impls (or at least gecko) |
| 14:51 | <zcorpan> | smaug____: ok |
| 14:51 | <smaug____> | it means that resize is occasionally pending while layout has changed its state already |
| 14:52 | <zcorpan> | another issue here is that the concept of flushing layout is not specced yet |
| 14:53 | <JakeA> | wanderview: wondering if .text() etc should also reject |
| 14:54 | <wanderview> | JakeA: I think it should, yea |
| 14:54 | <wanderview> | JakeA: can it provide the partial body if it rejects? or just say "use the stream version" if you want that behavior |
| 15:00 | <smaug____> | zcorpan: shoud resize fire if an iframe is first resized to size foo,bar, then foo+1, bar+1, and then back to foo,bar, before animation frame callbacks are run? |
| 15:01 | <annevk> | GPHemsley: FWIW, the Contexts wiki page is hopelessly out of date with respect to the number of contexts |
| 15:05 | <JakeA> | wanderview: it should reject with an error, it's possible but weird to have the partial as a property of the error. I think that might be too weird though |
| 15:05 | <wanderview> | yea... especially with promise propagation |
| 15:10 | <Domenic> | why does fetch/cache care about the content-length header at all? |
| 15:11 | <zcorpan> | smaug____: how do you interpret the spec for that case? "If doc’s viewport has had its width or height changed ... since the last time these steps were run" |
| 15:12 | <zcorpan> | maybe it should say if the width and height are different, rather than have changed |
| 15:13 | <JakeA> | wanderview: I guess the cache should take the whole body stream, and it's down to stream consumers to decide if they carry on reading or not |
| 15:14 | <wanderview> | JakeA: not sure I understand... what does "take the whole body stream" mean if there is an error while reading Response.body and streaming it to disk? |
| 15:14 | <JakeA> | Domenic: if a request has a content-length, should the stream stop at that content length even if there's more content? |
| 15:15 | <JakeA> | wanderview: I mean if the body stream is > content-length. If there's an error reading response.body it shouldn't go into the cache |
| 15:15 | <Domenic> | JakeA: I would just treat content-length as incidental metadata that in some authors' minds might have some relation to the body length in bytes, or might not |
| 15:15 | <Domenic> | not sure how that squares with XHR though |
| 15:15 | <wanderview> | JakeA: yea... I don't think we can make content-length strict by default... too many broken servers out there |
| 15:15 | <wanderview> | at least, we can never seem to get away with it in FF for other network requests |
| 15:15 | <JakeA> | Domenic: that's fair. Although .text etc may truncate at content-length, that's how browsers seem to behave today |
| 15:16 | <Domenic> | JakeA: hmm I mean that seems OK but unnecessary |
| 15:17 | <JakeA> | Domenic: I know what you mean, but it's something all browsers do so I guess there's a good reason. Maybe it's ok to break that tradition with fetch() |
| 15:17 | <Domenic> | I dunno, I feel like we need an expert :) |
| 15:17 | <JakeA> | Can't we just make shit up outselves? |
| 15:18 | <JakeA> | Can't we just make up words like "outselves"? |
| 15:18 | <Domenic> | aka "all the web platform" |
| 15:19 | <Domenic> | annevk: @fetchstandard should tweet this question and we'll all RT |
| 15:20 | <JakeA> | What? "Can't we just make shit up ourselves?" |
| 15:20 | <Domenic> | lol |
| 15:21 | <Domenic> | i meant, should content-length have any impact on .json(), but that works too |
| 15:21 | <Domenic> | hmm |
| 15:21 | <wanderview> | JakeA: pretty sure gecko is going to ignore content-length for the short term... |
| 15:21 | <Domenic> | what if the stream ends early before content-length is reached |
| 15:21 | <wanderview> | too many servers send the wrong value when gzip content-encoding is applied |
| 15:21 | <Domenic> | do we error or ignore content-length or...? |
| 15:21 | <JakeA> | Domenic: that tends to be an error |
| 15:22 | <Domenic> | hmm |
| 15:22 | <Domenic> | given the gzip thing i'm not sure i believe you? |
| 15:22 | <wanderview> | I think some browsers with less legacy just return error there |
| 15:23 | <JakeA> | Domenic: https://github.com/slightlyoff/ServiceWorker/issues/362#issuecomment-48612616 - although this research was done by past-Jake and I don't trust that guy |
| 15:23 | <Domenic> | ah that's very nice |
| 15:23 | <JakeA> | Maybe I'd have seen different results with gzipping |
| 15:23 | <JakeA> | I didn't test that |
| 15:23 | <wanderview> | its harder for us because "Firefox used to work, but doesn't in this new release!" when we try to treat content-length strictly |
| 15:24 | <JakeA> | wanderview: In my tests, content-length > content caused Firefox to wait until timeout |
| 15:24 | <JakeA> | Maybe that was keep-alive |
| 15:25 | <wanderview> | JakeA: maybe we check in one direction and not the other... probably depends on exactly what server bugs we have to bend to |
| 15:28 | <wanderview> | can we just spec the network to be infallible |
| 15:28 | <wanderview> | and no aborting fetches |
| 15:32 | <Domenic> | yes please |
| 16:23 | <annevk> | wanderview: we do use Content-Length to some extent |
| 16:24 | <annevk> | but I doubt it matters much in an HTTP/2 world |
| 16:33 | <annevk> | JakeA: your responses to https://github.com/slightlyoff/ServiceWorker/issues/651 don't really seem to take into account OP |
| 16:34 | <annevk> | JakeA: if I stream the body from a response, the SW shutting down once the promise resolves kills the body |
| 16:34 | <annevk> | doesn't* |
| 16:36 | <JakeA> | annevk: ah yes, I got lost in the replies |
| 16:53 | <wanderview> | jsbell: hi, were you looking for me yesterday? |
| 17:11 | <smaug____> | zcorpan: back. So I interpret it so that if there was a change after last resize, fire a new resize, even if the current size is the same. |
| 17:13 | <smaug____> | zcorpan: do you happen to know what blink does currently? |
| 17:57 | <jsbell> | wanderview: yeah, sorry. Wanted to see if your CacheStorage was exposed to windows yet or just for SW contexts |
| 17:57 | <wanderview> | ah... I think I ended up answer on list |
| 17:57 | <jsbell> | wanderview: but you replied on blink-dev :) |
| 17:57 | <wanderview> | yep :-) |
| 17:57 | <wanderview> | thanks |
| 17:58 | <jgraham> | jsbell: Thanks for the heads up |
| 18:00 | <jsbell> | np |
| 18:01 | <jsbell> | wanderview: also, I just told jgraham (via email), but I revamped the blink tests for cache storage (yesterday) so if you were pulling those, now's a good time to re-grab them |
| 18:03 | <wanderview> | thanks |
| 18:03 | <wanderview> | I don't think we're quite running those yet |
| 18:05 | <wanderview> | I did some temporary hacks in our tree to run them before... but have not tried again in the last few months |
| 18:06 | <Ms2ger> | So is TabAtkins going to do the geocities look again? |
| 18:07 | <jgraham> | I was sort of hoping that the upstream tests would be revamped a bit to make dealing with the origin issues a bit easier before I had another go at importing them into wpt |
| 18:11 | <jsbell> | jgraham: once this is out the door I'm hoping to tackle that. the cache ones don't have any actual server references except one php file, at least |
| 18:22 | <jgraham> | jsbell: Oooh, that seems like something I could import rather quickly then :) |
| 20:21 | <zcorpan> | smaug____: in http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3477 i get one resize event in blink, two events in gecko. remove the clientWidth and i get no events in either. |
| 20:21 | <smaug____> | zcorpan: in my test case blink fired event, gecko didn't |
| 20:22 | <smaug____> | zcorpan: https://pastebin.mozilla.org/8827770 |
| 20:22 | <zcorpan> | smaug____: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3478 webkit 2 events |
| 20:23 | <smaug____> | ah, you have layout flush |
| 20:24 | <zcorpan> | yeah. different case from what you asked about i suppose :-) |
| 20:24 | <smaug____> | oh, wait, blink fires resize even without any actual resize |
| 20:25 | <smaug____> | zcorpan: so current Gecko fires resize if there is one pending and one does layout flush |
| 20:26 | <smaug____> | otherwise resize is fired async |
| 20:26 | <zcorpan> | blink seems to fire resize sometimes (?) when loading an iframe |
| 20:26 | <zcorpan> | smaug____: ok |
| 20:27 | <smaug____> | my testcase runs after the iframe has been loaded |
| 20:27 | <smaug____> | and resize should fire before animation frame callbacks |
| 20:28 | <smaug____> | so gecko nor blink follows the current spec |
| 20:28 | <smaug____> | s/so/so not/ |
| 20:28 | <zcorpan> | right |
| 20:29 | <zcorpan> | blink fires an event here which is pretty weird http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3479 |
| 20:30 | <smaug____> | does it perhaps just fire pending resize after animation frame callbacks have run? |
| 20:34 | <Domenic> | TabAtkins: I am a bit confused by Bikeshed's "Terms defined by this specification" vs. exported dfns. Is there anywhere in the output that lists exported dfns? |
| 20:34 | <zcorpan> | maybe. but there shouldn't be any resize at all in this case (unless it considers a page load to be a resize) |
| 20:36 | <Domenic> | TabAtkins: also how should I mark up ES-style "abstract operations" that I want other specs to be able to call? Just <dfn>s? But they are already <h4>s... what's the suggested markup? |
| 20:37 | <smaug____> | zcorpan: sure. But does blink perhaps fire resize always after animation frame callbacks? |
| 20:38 | <smaug____> | I'm just about to upload a patch to change gecko's behavior to fire resize around animation frames, but would be good to know whether event should fire before or after the callbacks |
| 20:42 | <zcorpan> | smaug____: i'm not sure how to test the order |
| 20:43 | <zcorpan> | smaug____: i think the html spec's order has some reasoning behind it, that animation frames happen last |
| 20:43 | <zcorpan> | animation frame callbacks |
| 20:44 | <smaug____> | not sure the order matters much |
| 20:45 | <smaug____> | except for interoperability |
| 20:46 | smaug____ | tries to find where blink dispatches resize |
| 20:52 | <zcorpan> | smaug____: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/FrameView.cpp&q=enqueueresizeevent&sq=package:chromium&type=cs&l=2102 |
| 20:54 | <smaug____> | that doesn't dispatch it, right? |
| 20:55 | <smaug____> | ensureScriptedAnimationController().enqueuePerFrameEvent |
| 20:55 | <smaug____> | no idea what that might do |
| 20:55 | <smaug____> | sounds like something not what the spec says |
| 20:56 | <zcorpan> | it predates the spec changes, so entirely possible it is not at all what the spec says |
| 20:56 | <zcorpan> | i'd try to match the spec unless you find the spec insane |
| 20:56 | <smaug____> | ok |
| 20:56 | <smaug____> | thanks |
| 20:56 | <smaug____> | I don't find it insane |
| 20:56 | <smaug____> | it is just not what anyone is doing |
| 20:57 | <zcorpan> | yeah. i'll file a bug on blink to investigate getting closer to the spec |
| 20:58 | <zcorpan> | do you have a mozilla bug for your change? |
| 20:59 | <smaug____> | zcorpan: https://bugzilla.mozilla.org/show_bug.cgi?id=1149555 |
| 21:00 | <zcorpan> | thx |
| 21:16 | <zcorpan> | smaug____: https://code.google.com/p/chromium/issues/detail?id=472247 |
| 21:17 | <caitp-> | someone on blink-dev just noticed that idl attributes are found on prototypes now, rather than own properties of instances |
| 21:18 | <caitp-> | is it here to stay this time? :O |
| 21:24 | <smaug____> | caitp-: blink is late getting idl attributes to behave per spec |
| 21:24 | <caitp-> | yeah I know |
| 21:25 | <smaug____> | and ++blink getting this stuff fixed finally :) |
| 21:25 | <caitp-> | i think it's been attempted before |
| 21:27 | <Domenic> | before it was reverted because perf |
| 21:27 | <Domenic> | this time the only thing that can stop it is another MS Exchange/Array.prototype.contains-style debacle once it reaches stable channel |
| 21:27 | <Domenic> | And even then they might just be able to turn it off for one or two properties... |
| 21:28 | <Domenic> | Array.prototype.values, rather |
| 21:28 | <caitp-> | well, won't have to worry about A.p.values until it's actually implemented in v8 |
| 21:28 | <smaug____> | Domenic: curious, which properties? |
| 21:29 | <Domenic> | smaug____: I meant, hypothetical ones that cause compat problems. So far none have done so on a large scale... |
| 21:29 | <Domenic> | caitp-: pretty sure it was implemented but had to be backed out because it broke MS Exchange Online? Was that something else? |
| 21:29 | <zcorpan> | w00t! let's hope it sticks this time |
| 21:30 | <caitp-> | Domenic I believe that's what it was |
| 21:30 | <caitp-> | @@iterator is there, but the values alias isn't exposed |
| 21:30 | <Domenic> | yeah |
| 21:31 | <Domenic> | wonder when we're going to feel brave enough to try that again |
| 21:31 | <smaug____> | while fixing this all Gecko had some issues. onmouseenter/leave required special handling |
| 21:31 | <Domenic> | spartan is shipping it i believe |
| 21:31 | <smaug____> | but I guess that ended up to some spec |
| 21:31 | <smaug____> | http://mxr.mozilla.org/mozilla-central/source/dom/webidl/EventHandler.webidl#65 |
| 21:32 | <smaug____> | (and of course all the issues related to global ) |
| 21:33 | <zcorpan> | https://html.spec.whatwg.org/multipage/webappapis.html#idl-definitions:handler-onmouseenter |
| 21:33 | <smaug____> | good |
| 21:33 | <zcorpan> | idl attributes on globals is on the instance per spec |
| 21:35 | <smaug____> | right, and it took quite some time to find something compatible-enough-with-the-web |
| 21:37 | <caitp-> | so how was the perf issue solved? |
| 21:37 | <caitp-> | i don't remember seeing any bugmail about it, so I missed something :> |
| 21:38 | <smaug____> | zcorpan: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/GlobalEventHandlers.idl&q=onmouseenter file:idl&sq=package:chromium&l=73 |
| 21:40 | <zcorpan> | smaug____: thx. will file |
| 21:41 | <caitp-> | hmmm, fixme comment in that file does not have a name on it :> |
| 21:52 | <zcorpan> | https://code.google.com/p/chromium/issues/detail?id=472260 |
| 21:52 | <zcorpan> | it's probably philipj |