[09:01:35] <DaveMethvin> meeting time!
[09:01:41] <arthurvr> Hi!
[09:02:10] <DaveMethvin> hey arthurvr
[09:02:15] <DaveMethvin> m_gol markelog gibson042 timmywil   ... who did i miss?
[09:02:44] <DaveMethvin> it's quiet....TOO quiet
[09:02:58] * gibson042 cues music
[09:03:07] <DaveMethvin> muzak
[09:03:18] <DaveMethvin> hey gibson042 while we're waiting .... :)
[09:03:27] <DaveMethvin> how's the deferred stuff going?
[09:04:09] <gibson042> no word from jaubourg on my PR, but no explicit invitation for him either
[09:04:27] <gibson042> I think it's in a state where it can land, with size reduction pushed off for post-beta
[09:04:34] <DaveMethvin> i think we need to move ahead if he's too busy, yeah
[09:05:12] <gibson042> let me message him on it and we'll do something one way or another by Friday
[09:05:18] <DaveMethvin> ok that would be good
[09:05:27] <DaveMethvin> we can't really have a beta without some of these big items in there
[09:05:30] <markelog> hey-hey
[09:05:37] <DaveMethvin> we can do the size fixes later
[09:05:40] <DaveMethvin> hey markelog !
[09:06:06] <DaveMethvin> oh awesome that guy just did the pr for his data change
[09:06:57] <DaveMethvin> arthurvr: whoops! forgot to escape the brackets https://github.com/jquery/api.jquery.com/issues/636
[09:07:23] <DaveMethvin> okay let's see what else has to land
[09:07:37] <arthurvr> DaveMethvin: :( I’ll fix it
[09:07:48] <DaveMethvin> i hope timmywil is making some progress on the build stuff
[09:09:11] <DaveMethvin> markelog I saw you have PRs for quite a few things, if you think they are ready just land them
[09:09:21] <markelog> okay
[09:10:01] <DaveMethvin> and thanks for all that work!
[09:10:17] <markelog> sure )
[09:10:47] <markelog> meant to ask, why "_evalUrl" is exposed?
[09:11:02] <markelog> it was before amd right?
[09:11:18] <DaveMethvin> i can't remember
[09:11:28] <gibson042> I'm pretty sure it predates AMD
[09:12:06] <gibson042> there was also some discussion about _external_ definitions of it, but I'm sure none ever materialized
[09:12:08] <DaveMethvin> well you can tell by the _ it's supposed to be private :)
[09:12:33] <markelog> so maybe we should encapsulate it?
[09:12:56] <gibson042> sure
[09:13:03] <DaveMethvin> yeah
[09:13:05] <markelog> okay, will do another PR
[09:13:11] <DaveMethvin> 3.0 is a good time for that
[09:13:21] <markelog> rihgt
[09:13:22] <markelog> right
[09:13:35] <gibson042> it also manifests a certain hope for dynamically-loaded modules, but that will probably look different when it comes anyway
[09:13:55] <gibson042> (again, predating our AMD builds)
[09:14:23] <DaveMethvin> i think we can assume we'll have jQuery 4.0 in a year or so after 3.0 so we can break more stuff :)
[09:14:52] <gibson042> oooh, dcherman is speaking truth in #jquery-dev
[09:15:11] <gibson042> "that way you could redefine it [_evalURL] if you wanted to exclude $.ajax from your build"
[09:15:28] <DaveMethvin> oh right, that was the big battle wasn't it?
[09:15:37] <DaveMethvin> whether it went in manip or ajax
[09:15:42] <gibson042> so take that as the guiding principle and work from there
[09:15:54] <DaveMethvin> how could i forget THAT
[09:16:06] <markelog> hm, although we have this - test/unit/manipulation.js
[09:16:14] <markelog> anyway, will check it out
[09:16:18] <gibson042> http://en.wikipedia.org/wiki/Repressed_memory
[09:16:20] <markelog> https://github.com/jquery/jquery/blob/master/test/unit/manipulation.js#L2331
[09:16:55] <DaveMethvin> so the basic rule is that if you replace ajax you'd need to provide a hook for evaluating scripts for the convenience of manipulation.js
[09:17:17] <DaveMethvin> and if we ever got our $.fetch module off the ground we might actually  need that
[09:17:45] <markelog> should it stay with "_" then, should we document that?
[09:18:24] <m_gol> present, sorry for delay
[09:18:31] <markelog> hey there
[09:18:40] <DaveMethvin> hey m_gol
[09:18:50] <arthurvr> Hi m_gol
[09:19:12] <DaveMethvin> i think it's low level, if we end up with our own ajax alternative we'd need it too
[09:19:28] <timmywil> hi!
[09:19:34] <DaveMethvin> hey timmywil
[09:19:34] <arthurvr> Hi timmywil
[09:19:40] <timmywil> I'm in San Fran
[09:19:56] <DaveMethvin> so i wouldn't document _evalURL yet but we might in the future
[09:20:04] <timmywil> Sorry I've been busy, but I will actually be able to work on build stuff this week.
[09:20:21] <timmywil> With everyone else at my company distracted by a sales conf.
[09:20:24] <DaveMethvin> awesome
[09:20:37] <DaveMethvin> and it's still so early in SF!
[09:20:50] <timmywil> inorite
[09:20:51] <DaveMethvin> poor markelog and m_gol  their day is almost over :)
[09:21:06] <DaveMethvin> although i see no evidence that either of them ever sleep
[09:21:17] <m_gol> I'll probably leave work in about 6 hours today so not so late for me :P
[09:21:19] <markelog_> how about we add comment, so we wouldn't forget in the future
[09:21:23] <DaveMethvin> gibson042: thanks for the note in that ticket
[09:21:35] <DaveMethvin> markelog: in the code, sure
[09:21:47] <markelog_> okay
[09:22:49] <DaveMethvin> now that we have a PR for that one data change, i will land both of them and ping rwaldron
[09:23:42] <DaveMethvin> any other topics we need to discuss?
[09:23:50] <markelog_> offsetParent?
[09:24:02] <markelog_> what should we do about it?
[09:24:09] <DaveMethvin> oh yeah, whether we wanted to tackle that for 3.0
[09:24:16] <markelog_> yep,
[09:24:28] <DaveMethvin> it should be a pretty simple fix
[09:24:42] <DaveMethvin> more a question of whether we shoudl be doing that without the standard being set
[09:24:59] <markelog_> and expensive one (
[09:25:05] <markelog_> and there is that
[09:25:16] <markelog_> right now it looks like an isolated edge-case
[09:25:32] <markelog_> should be pretty big hit on perf
[09:25:41] <DaveMethvin> we certainly haven't had a lot of people encountering it
[09:26:01] <gibson042> gg now; probably back later though
[09:26:08] <markelog_> since position stuff already is pretty hard to do
[09:26:38] <markelog_> okay, so we close it, until (if) more tickets will pop up?
[09:26:46] <DaveMethvin> well just changing offsetParent doesn't look *that* expensive
[09:27:01] <DaveMethvin> https://github.com/jquery/jquery/issues/1765
[09:27:25] <DaveMethvin> it's just another call to .css() in the loop?
[09:27:44] <markelog_> i have an example where it could have massive impact on perf - https://github.com/jquery/jquery/issues/1765#issuecomment-69848873
[09:28:07] <DaveMethvin> right, if it were really deep and the body was the offsetParent
[09:28:10] <markelog_> since we would need to remove offsetParent use
[09:28:26] <markelog_> just like you mentioned early in the discussion
[09:28:50] <markelog_> that is worst case
[09:28:56] <DaveMethvin> i don't  know how common a really deep tree is
[09:29:19] <markelog_> yeah, don't know about that too
[09:29:28] <DaveMethvin> i think there's enough concern that we leave this out for now, esp since the standard isn't final
[09:29:47] <markelog_> okay, so lets close it and wait?
[09:30:12] <m_gol> when you webcomponentize everything, the hierarchy can get pretty deep
[09:30:14] <m_gol> in complex apps
[09:30:24] <markelog_> its a bit sad that offsetParent it treat as a legacy property
[09:30:25] <m_gol> the fact it's not common now doesn't meen it soon won't be
[09:30:49] <DaveMethvin> it's not marked for the 3.0 milestone anyway, let's leave it open and deal with it later
[09:30:55] <timmywil> +1
[09:30:55] <markelog_> okay
[09:31:06] <DaveMethvin> really you'd think the browser itself would figure this out
[09:31:16] <DaveMethvin> so maybe we file a bug with them
[09:31:32] <markelog_> to the spec?
[09:31:44] <markelog_> we probably shoud
[09:31:46] <markelog_> should
[09:32:09] <DaveMethvin> yeah, if the browser implements 3d transforms it shoudl be looking at them when calculating offsetParent
[09:32:46] <m_gol> bzbarsky said offsetParent is treated as a legacy API
[09:32:58] <m_gol> and that's why it's not fixed for new APIs as it basically shouldn't be used
[09:33:10] <DaveMethvin> well geez
[09:33:12] <markelog_> that is a sad part
[09:33:18] <timmywil> well, there's an argument that it shouldn't take transforms into account
[09:33:22] <markelog_> maybe we could change their minds?
[09:33:25] <m_gol> and that we should use getBoundingClientRect/getBoxQuads everywhere
[09:33:38] <DaveMethvin> if it changes the real offsetParent it seems stupid that it wouldn't take it into account
[09:33:41] <m_gol> and compute the offset to parent by substracting two values
[09:33:45] <timmywil> if offsetParent is a layout-only property
[09:34:05] <DaveMethvin> oh right now i recall that conversation m_gol
[09:34:09] <DaveMethvin> well then ...
[09:34:21] <DaveMethvin> that brings up the question of whether we shoudl be using gBCR etc
[09:34:31] <timmywil> yeh
[09:35:09] <DaveMethvin> fractional pixels is likely to break old code
[09:35:18] <DaveMethvin> but if we were going to do it then 3.0 would be a good time
[09:35:24] <m_gol> it'd be worth trying but it's either for 3.0 or not before 4.0
[09:35:46] <DaveMethvin> right
[09:35:46] <m_gol> DaveMethvin: do you want to have all new breaking stuff in the first beta?
[09:35:47] <timmywil> needs more discussion
[09:35:56] <DaveMethvin> m_gol: yes
[09:36:06] <timmywil> well yes, but there can be more breaking stuff in 4.0
[09:36:08] <DaveMethvin> i think we'll have to wait on this one
[09:36:15] <markelog_> +1
[09:36:36] <gibson042> back
[09:36:47] <markelog_> to much to do for 3.0 already
[09:37:01] <m_gol> k
[09:37:05] <DaveMethvin> agreed
[09:37:31] <DaveMethvin> okay more work avoided!  yay!
[09:37:35] <markelog_> ))
[09:38:15] <DaveMethvin> any other items to discuss?
[09:38:17] <m_gol> if anyone has any idea why Chrome is behaving randomly at https://github.com/jquery/jquery/pull/1842, that'd be great; otherwise I'll have to restore the whole hack without wrapping it in a support test :(
[09:38:39] <DaveMethvin> and it only happens on testswarm m_gol
[09:38:42] <DaveMethvin> ?
[09:38:46] <m_gol> so the thing is that Android 4.0-4.3 fail the test *always* and Android 2.3 & Chrome (current) fail it in certain circumstances only
[09:38:49] <markelog_> m_gol: i can check it out, but would have to do mine tickets first
[09:38:52] <m_gol> no, locally as well
[09:38:56] <DaveMethvin> oh
[09:39:15] <m_gol> the bodyBackground test iframe triggers the bug on those two
[09:39:28] <DaveMethvin> strange
[09:39:42] <markelog_> as always )
[09:39:43] <m_gol> it'd be good to isolate a simple test case, if it's too broken we might need to broaden the support test to catch Android 2.3 & Chrome as well
[09:39:56] <m_gol> but since it looks as a race condition, that might not be so easy
[09:40:47] <m_gol> ok, I'll try to narrow the issue down but if I don't manage to do it before Monday then I'll just apply it everywhere
[09:40:50] <mikesherov> hi!
[09:40:55] <m_gol> a pity since Firefox (as usual) behaves sanely here
[09:40:58] <m_gol> mikesherov: hi
[09:41:01] <markelog_> hi Mike!
[09:41:04] <m_gol> mikesherov: good moment
[09:41:24] <m_gol> mikesherov: I have a race condition in what Chrome returns for gCS.marginRight ]:->
[09:41:34] <timmywil> it's mikesherov!
[09:41:35] <m_gol> mikesherov: see https://github.com/jquery/jquery/pull/1842 if you find time
[09:41:56] <mikesherov> if you guys are at the end of your meeting, I submitted a potential change to the style guide in case anyone likes bikeshedding: https://github.com/jquery/contribute.jquery.org/pull/104
[09:42:00] <m_gol> mikesherov: specifically this comment: https://github.com/jquery/jquery/pull/1842#issuecomment-71346623
[09:42:03] <mikesherov> m_gol: looking
[09:42:28] <mikesherov> WHYYYYY
[09:42:33] <mikesherov> why oh why
[09:43:13] <m_gol> mikesherov: yup
[09:43:26] <m_gol> one might say Android 4.0 made it better since now at least it fails always, not sometimes
[09:43:54] <DaveMethvin> yeah, at least we know it sucks consistently
[09:43:59] <mikesherov> so, is this fixed in latest android?
[09:44:01] <mikesherov> please say yes
[09:44:12] <m_gol> well, Android 4.4 is Chrome so I'd guess it's back to being worse now
[09:44:22] <DaveMethvin> consistently worse, so better :)
[09:44:23] <m_gol> since Chrome is behaving exactly as Android 2.3 here
[09:44:27] <markelog_> gotta go, see ya
[09:44:35] <DaveMethvin> thanks markelog_
[09:44:37] <m_gol> DaveMethvin: back to being worse non-consistently
[09:44:45] <DaveMethvin> oh right the other way around
[09:44:47] <DaveMethvin> inconsistent
[09:45:08] <DaveMethvin> makes you want to do a user agent test
[09:45:28] <m_gol> I believe I stumbled upon it a while ago in my own app... but it was so deep in some other code it was hard to pinpoint
[09:45:32] <m_gol> maybe now it'll be easier to reduce
[09:45:43] <m_gol> why does this API suck so much in real life
[09:46:04] <mikesherov> wait, so what?
[09:46:11] <mikesherov> is the hack necessary in 4.4?
[09:46:17] <mikesherov> m_gol: ?
[09:46:26] <DaveMethvin> yes, even current chrome as i understand it
[09:46:29] <m_gol> mikesherov: if we don't find a way to do a feature test that will behave consistently in Chrome, we'll have to apply the hack to all browsers
[09:46:43] <m_gol> mikesherov: which is bad considering it triggers a layout etc.
[09:47:00] <mikesherov> OH
[09:47:05] <mikesherov> pixelMarginRight!
[09:47:10] <mikesherov> yeah, this is a real thing
[09:47:15] <mikesherov> this is definitely needed
[09:47:28] <mikesherov> I was mistaking for reliableMarginRight which died years ago
[09:47:32] <m_gol> yes, but if it sometimes gives true & sometimes false...
[09:47:33] <m_gol> yeah
[09:47:47] <mikesherov> when does it sometimes give true?
[09:48:05] <m_gol> true means it succeeds, false that it gives 50% instead of pixels
[09:48:06] <DaveMethvin> on runs that end in prime numbers
[09:48:25] <m_gol> if you run tests on the support module, you'll see the test fails in the bodyBackground test
[09:48:37] <DaveMethvin> it's inconsistent run to run though m_gol ?
[09:48:53] <m_gol> it always fails on the bodyBackground and it always succeeds in the regular test
[09:49:15] <DaveMethvin> ugh
[09:49:24] <m_gol> it's hard to see what could make the test switch its value with such a simple template, though: https://github.com/jquery/jquery/blob/master/test/data/support/bodyBackground.html
[09:50:16] <DaveMethvin> maybe wrap that in an onload?
[09:50:47] <DaveMethvin> it's not cheating if it works!
[09:52:27] <m_gol> DaveMethvin: it fails then as well
[09:52:35] <DaveMethvin> dammit!
[09:52:37] <DaveMethvin> :)
[09:52:52] <DaveMethvin> thought it might be some crazy race condition
[09:52:57] <DaveMethvin> i guess it still could be
[09:53:06] <m_gol> an additional setTimeout doesn't help either :P
[09:53:32] <DaveMethvin> man you are READING MY MIND
[09:54:11] <gibson042> what about TWO setTimeouts?
[09:54:17] <DaveMethvin> LOL
[09:54:33] <m_gol> nice try but nope ;)
[09:54:40] <DaveMethvin> any good solution or prolbem involves setTimeout and iframe
[09:55:17] <DaveMethvin> okay, let's wrap up here and can continue in jquery-dev if needed ... i have to run off for another meeting
[09:55:22] <m_gol> yup
[09:55:26] <DaveMethvin> thanks guys!
[09:55:27] <mikesherov> we still test in iframes right?
[09:55:33] <DaveMethvin> yep
[09:55:41] <mikesherov> there is some bonkers stuff going on in testswarm
[09:55:52] <m_gol> mikesherov: this is reproducible locally
[09:55:56] <mikesherov> I see
[09:56:02] <mikesherov> ok then
[09:56:10] <DaveMethvin> let's move over to #jquery-dev