mozilla :: #content

18 May 2017
02:28bkellyits kind of concerning to me that FF feels sluggish on my 2016 mac pro... I wonder if its the software rendering
05:22floriansmaug: the "DOMContentLoaded" and "load" notifications are visible in the profiles as big black rectangles. And then what I use to know when the window is visible is that I filter the stacks on nsWindow::Show (nsCocoaWindow::Show on Mac).
06:25qDotbaku|away: pong
06:26qDot... 16 hours later.
08:48bakuqDot: np
12:21farreping :florian
13:11florianfarre: pong (but I replied in the bug before seeing your ping)
13:12farreflorian: that's ok, but yeah, then the bulk of the work is done in bug 1358476
13:12firebot NEW, Add nsThread::idleDispatch(nsIRunnable, uint32_t aTimeout)
13:13farreif not the entirety
13:13florianI'm still curious about the answer to Mike's question in comment 8 ("Perhaps I'm oversimplifying to a great extent, but could we make nsIThread's idleDispatch not [noscript]?")
13:18farrewe'd want to expose nsIIncrementalRunnable as well (or nsIIdleRunnable when 1358476) to be able to expose deadline management and timeouts
13:19farrebut, otoh, if we're ok with not having timeouts in the meantime, then yes, just removing [noscript] is possible
13:23farreand we need to fiddle with the nsIRunnable argument as well, I think that we need something that's not an already_AddRefed (as in nsIEventTarget)
13:26florianI think it would be good to have a simple API for the simple case where we just want something to run without being in the user's way, and a more detailed API for when we want the runnable to run 'not before that many ms' or 'at the latest after this many ms'
13:28florianfarre: from looking at the patches in bug 1358476, they don't seem to add any scriptable API, so I guess you'll need at least another patch on top of them
13:28firebot NEW, Add nsThread::idleDispatch(nsIRunnable, uint32_t aTimeout)
13:29farreflorian: that's right
13:35farreflorian: so, I have a front end question. is it a big hassle implementing nsI*-interfaces from script?
13:36floriandefine "big hassle". In most cases we'll say yes if doesn't fit on a single line ;).
13:39florianfarre: what makes the nsIRunnable JS-friendly is the "function" keyword at
13:39florianthat means JS can just pass a function instead of implementing an object with a "run" method
13:41farreflorian: so I guess that we probably need some kind of wrapper then to get the more advanced features
13:42farreflorian: something that can respond to SetDeadline (and when 1358476 lands) SetTimer which does plumbing and timer handling
13:43florianfarre: a JS friendly API would be to add to nsIThreadManager an idleDispatch method, taking an nsIRunnable as first parameter, and then an additional optional parameter implementing an interface with readonly attributes for the advanced features
13:52farreflorian: patch uploaded and try run requested. I'll start getting it reviewed when I've seen the try results
14:00bkellysmaug: I'm tempted to try making MozPromise accept nsIEventTarget... its either that or make a lot of other changes to deal with AbstractThread::GetCurrent() going away
14:07bkellyit seems like firefox loses content in forms more frequently lately
14:07bkellyI used to be able to refresh bugzilla when I know a mid-air collision was going to happen and it would keep my comment... now the comment box is erased
14:08bkellyI just had another situation where the back button did not restore a form I was on
14:08bkellyI wonder if we regressed something
14:09smaugbkelly: or did bugzilla change
14:09bkellysmaug: well, this other form was on a different site
14:09bkellycould be the site, too
14:09bkellyjust a trend I've been noticing lately
14:10mystorbkelly: Are the runnables being run during fetch interception labeled?
14:10bkellymystor: depends which runnables you mean
14:11bkellymystor: stuff that goes from worker thread to main thread should go through the WorkerPrivate::DispatchToMainThread() which gets labeled
14:11mystorbkelly: I'm wondering how important the TabGroup which uses is
14:12bkellymystor: thats unlabeled... and likely will completely change/go-away as we implement our multi-e10s refactor
14:13bkellymystor: service worker is not really associated with any TabGroup... the SW runs in the background and can have zero or more windows interacting with it... it probably needs its own label or the system label
14:13mystorbkelly: mk - I'll just let WhenPermissionsAvaliable dispatch an unlabeled runnable in the case where the permissions aren't avaliable for now
14:14bkellymystor: also, it will be in a different process in the future
14:14mystorjw is moving the promises to the system group.
14:14mystorbkelly: Yeah, I've heard
14:14mystorbkelly: This code path still exists for now and I wanted to be sure not to break it
14:15mystorbkelly: Would running that runnable in the system group be bad?
14:15bkellyI have no idea the implications of running things in different groups
14:15mystorbkelly: It changes ordering constraints
14:16mystorbkelly: runnables within the same group have ordering wrt eachother. system group has no ordering wrt anything related to any page
14:16mystorbkelly: It's used for stuff like background chrome jobs
14:16bkellymystor: the runnable you linked doesn't race with anything else... I don't think ordering matters there
14:16bkellyoverholt: somewhat shocking, it seems chromium doesn't have a real quota system?
14:34overholtbkelly: interesting
14:34bkellyoverholt: I'm asking Jake if I'm reading that right...
14:50smaugcould someone CC me to Bug 1365602
14:50firebotBug is not accessible
15:28bkellyfroydnj: we still don't have anything that makes an nsITimerCallback with a lambda, right?
15:28bkellythinking of adding one
15:28froydnjbkelly: I think there's something in media/? SimpleTimer, or something like that? but nothing in xpcom, no
15:29bkellyfroydnj: I guess it wraps a runnable which can take NS_NewRunnable() with a lambda
16:00freesamaelsmaug: OK, this is fun...
16:00freesamaelsomeone created a new nsISHistory and just moved nsSHEntry to that new history
16:00smaughmm hmm
16:02smaugoh, seamonkey
16:02freesamaelsmaug: Yup. I believe the windows crash was hit in the same way by some addons
16:03smaugcouldn't have through anyone doing that
16:04bzsmaug: so just to be clear, we're not that much slower than Safari on the innerHTML thing, right
16:04smaugbz: I believe we're a bit slower
16:04smaugwe should be around on par with Chrome
16:04smaugand Safari was faster than Chrome
16:04bzsmaug: about 14% slower afaict
16:05* bz sees us faster than chrome dev, on mac
16:05smaugChrome canary is for some reason slower than release
16:05smaugmy guess was that they have some non-release assertions or so
16:06* bz has dev, not canary
16:06smaugon Windows at least
16:07bzso I have an instruments profile....
16:07* bz pokes at it
16:08smaugnot sure we have any easy ways to speed up, except possibly
16:08firebotBug 1351857 FIXED, nsHtml5ElementName::elementNameByBuffer and nsHTML5AttributeName::nameByBuffer are too slow
16:08bzI did just see that in the profile, yes
16:09bzSo I see 8% or so spent removing kids
16:09bzbut that might be because I'm running this in a loop
16:09* bz tries a single loop iteration
16:10bzSo there's malloc traffic from nsHtml5String::Release
16:11bzFrom nsHtml5HtmlAttribues::clear
16:11bzer, Attributes
16:11bzStill seeing 8% under RemoveChildAt
16:12bzOh, right, because it's still resetting innerHTML on the same node multiple times
16:13bzThere's various stuff under that removal, but nothing easy to fix. :(
16:13* bkelly considers relying on CC being slow for back pressure.
16:14bzUnbindFromTree just does so much stuff. :(
16:16bzso ok, nameByBuffer...
16:16smaugI reopened that bug
16:16smaugwe shouldn't be using array + binary search
16:16smaugat least not without some cache
16:18* bz tries to figure out what this is doing
16:18bzI guess the idea is this is meant to find pre-interned attr names for "known" attrs
16:19smaugoh, I think I've seen usually elementNameByBuffer
16:19smaugwhich is the same for elements obviously
16:19bzI have 4% under AttributeName::nameByBuffer
16:21bzAttr array growth...
16:21bzLots of notifications
16:21bzContentAppended, etc
16:22bz3% HTMLInputElement::HandleTypeChange....
16:22bzThis is from the SetAttr when creating it initially
16:22smaugthat is still quite bad, but it used to be even worse
16:23bzIt's a type="checkbox"
16:23bzdropping text editor states, etc
16:23smaugright. We used to allocate TextEditorState in Ctor, and then delete it immediately in SetAttr
16:23bzThat's what I'm seeing
16:23smaughmm, still allocating?
16:23* bz checks
16:24bzwe're doing ReleaseTextEditorState
16:24smaugwe should try to reuse some TextEditorState object
16:24bzwhich sticks it in the cache
16:24bzI'm seeing that happen
16:24bzWhy don't we just allocate it from DoneCreatingElement?
16:25smaugbecause other SetAttr calls expect it to be there for type=text?
16:25bzI guess this testcase has no value attr
16:25bzstill seems like we could allocate lazily
16:26bzThe first time someone asks for it, or from DoneCreatingElement
16:26bzSo ok
16:27bzI'm not seeing any big wins here.
16:27bzJust lots of grind
16:27bzIf we can avoid free() when nsHtml5Tokenizer::emitCurrentTagToken calls nsHtml5HtmlAttributes::clear that would be kinda nice
16:27bz3% of our time is there
16:29bzsmaug: I'm tempted to stop spending time on this for the moment. ;)
16:29smaugsounds good :)
16:29smaugWe optimized it quite a bit already
16:30smaugand being somewhere between Chrome and Safari is hopefully good enough
16:30smaugbz: thanks for profiling
16:36bzsmaug: no problem
19:33bkellysmaug: what sort of things prevent a page from being in bfcache?
19:46bkellysmaug, thanks
19:46bkellysmaug: I noticed none of twitter, facebook, and linkedin could be bfcached.... I guess maybe the network connection bit
19:47smaugor unload listeners
19:47bkellyit seems calling nsGlobalWindow::EventTargetFor() too early at startup crashes :-\
19:49billmbkelly: are you asking for a Worker or Timer category?
19:50bkellybillm: timer
19:50billmbkelly: is it this assertion?
19:50bkellybillm: perhaps... although I didn't get a good assertion statement out... it is a chrome window, though
19:51billmhmm, that's odd
19:51billmI dunno
19:52bkellyI'll add a chrome check
19:53bkellybillm: is the chrome assertion there just because we used to exempt chrome in my timer flooding stuff?
19:55billmbkelly: yeah, we don't use a ThrottledEventQueue for the chrome tabgroup
19:55billmbkelly: so there's no need to initialize it
19:56bkellybillm: but what is suppsoed to prevent hitting that assertion... stuff like this calls it for chrome anyway...
19:56billmbkelly: well, that's what the special mIsChrome exemption is for.
19:57billmbkelly: in that case we return a normal event target (not throttled)
19:57billmwell, I guess we just return do_GetMainThread(), actually
19:58bkellybillm: I see the problem... I'm trying to do this inside nsGlobalWindow() before mIsChrome is set
20:00billmbkelly: which mIsChrome? the one on TabGroup is set in the constructor.
20:00bkellynot sure
20:00bkellyI'm going to change my stuff not to do this in the constructor
20:25jugglinmikebkelly: Does Firefox maintain a blacklist of WPT tests that are known to fail?
20:25bkellyjugglinmike: yes
20:26jugglinmikeWould you mind linking me to it?
20:26bkellyjugglinmike: in .ini files in testing/web-platform/meta
20:26jugglinmikeah, got it
20:29bkellyoverholt: this actually surprises me:
20:29firebotBug 1362412 ASSIGNED, is still slow to animate
20:30bkellyare tables really that common on the web these days?
20:30overholtbkelly: what surprises you?
20:30* overholt was just typing what others said
20:30overholtbut I don't know
20:30bkellyI just thought tables "were so 1990's" or something
20:30overholtplus, I'm not sure what p1 will do; someone's already working on it
20:30overholtthis is like in b2g when we'd mark something a blocker and it was always unclear what that actually did :)
20:46jugglinmike1The Foo Fighters are also so 1990's
20:48bzoverholt: held the door open?
20:48bkellyjugglinmike: I have looked at their site a lot lately and I can tell you they are still touring
20:49overholtbz: perhaps
20:49overholtI would like to see the Foo Fighters perform
20:49jugglinmikesame here
20:49overholtif only their site would load fast enough for me to see where they are playing (jokes)
20:49jugglinmike but I'm a nostalgic sucker
20:50bkellyoverholt: use chrome
20:50overholtbkelly: it's quite smooth in Edge
20:52bkellyholy cow... my patches for bug 1363829 make the servo tiles stress test a lot smoother
20:52firebot ASSIGNED, consider using a single nsITimer for setTimeout() in windows
20:52bkellyI didn't really expect such a noticeable impact
21:18billmfroydnj: ping
21:18jugglinmikebkelly: I'm jumping back and forth between Fetch and Service Worker, but I can't find anything about when the User-Agent header is restricted
21:19jugglinmikeTrying to understand where this comes from
21:19bzThat tiles experiment sure is faster in Safari....
21:19jugglinmikebut maybe it's defined elsewhere--like wherever the "navigation" request is initially created
21:20bkellyjugglinmike: its because its added in fetch at step 14 here:
21:21bkellyand that algorithm should run after service worker interception
21:21bkellysorry, step 12
21:22bkellybillm: I owe you a beer:
21:22firebotBug 1366072 NEW, Allow MozPromise to take an nsIEventTarget as well as an AbstractThread
21:22bkellyor other suitable beverage
21:24billmbkelly: yeah, I sat there for a while thinking about what to do with AbstractThread. then I just decided to write that patch, since it would at least contain it to media code.
21:25jugglinmikebkelly: I see. I was assuming that it was set prior to that and somehow hidden from the service worker
21:26jugglinmikebut I guess the condition that begins the step is to support specification of user-agent from the `fetch` API
21:27bkellybillm: I was planning to write that patch too... so happy to see it magically appear :-)
21:28billmbkelly: do you know if there's any reason that AbstractThread shouldn't implement nsIEventTarget?
21:29bkellybillm: the reasons bobbeyholley gave me: 1) he wanted to guarantee a "only one runnable at a time" semantic, but I think that could be done as a specialized nsIEventTarget
21:29bkellybillm: 2) he didn't like XPCOM call signature 3) he wanted an infallible dispatch
21:30bkellybut I could be mis-remembering
21:30billmbkelly: well, the first reason doesn't prohibit making AbstractThread an nsIEventTarget. it just means we shouldn't take an nsIEventTarget from places that expect single-threadedness. I'm not sure what those places are though. not mozpromise though.
21:31bkellybillm: it was stuff like TaskQueue
21:31mystorWhat triggers the "Nightly closed unexpectedly while starting" dialog to show up? I had gdb connected and it didn't seem to pause, so I'm not sure what's going on.
21:33billmbkelly: hmm, but that seems like the same thing. there's nothing about TaskQueue that doesn't make it an nsIEventTarget. it just happens to provide more guarantees than nsIEventTarget.
21:33billmbkelly: for the signature stuff, it seems like we could add C++ wrappers in the IDL file
21:33bkellybillm: I agree with you... nsIEventTarget could be a base interface
21:34bkellyI'm just trying to proxy explain the answer I got when I asked this stuff before
21:34billmbkelly: anyway, if JW takes this MozPromise patch, then I'll go through and remove all the AbstractThread usage outside of media
21:35billmat that point it probably doesn't matter as much what happens
21:36mystorbillm: Sounds awesome :)
21:37bkellybillm: I have to admit I thought this AbstractThread change was related to the main thread splitting stuff
21:38billmbkelly: it is a little bit. figuring out what AbstractThread::GetCurrent() should return for the cooperative threads is really messy. this will make it a little easier to clean that up, although I think JW is already planning to do that somehow.
21:39bkellybillm: something that would help my use case for NS_GetCurrentThread(), etc... if we have a NS_GetThreadForGlobal(nsIGlobalObject*) helper... on window pull it out of the window's tab group... on workers pull it out of the WorkerPrivate
21:40billmbkelly: what are you using the thread for?
21:40bkellybillm: moz promise
21:40bkellybillm: but when I get a DOM binding call I don't really know what thread I am on
21:40bkellyso I either need TLS or a way to map it from my owning global
21:41billmbkelly: hmm, ideally you could do globalObject->EventTargetFor(category). that doesn't work on workers now but we could make it work. would that satisfy your use case?
21:41bkellybillm: I'm making a DOM binding that can be exposed to either window or worker
21:42bkellybillm: yea, that would be perfect
21:42* bz applauds whatever makes worker code and non-worker code looks as much alike as possible
21:42bkellybillm: but what does the category mean on workers?
21:42bzI mean, within reason; no need to convert both to perl. ;)
21:42billmbkelly: it would be ignored, I guess
21:43billmbkelly: how can I tell from a global if we're on a worker?
21:43billmin that case I think it could just return NS_GetCurrentThread()
21:43billmwell, hmm, maybe it should work on other threads too
21:44bkellybillm: I think we would want it to QI to something workery
21:44bkellyif it doesn't already
21:44bkellybillm: today I am using GetCurrentThreadWorkerPrivate()... but that is TLS and it also asserts if called from main thread
21:45billmbkelly: where do we subclass nsIGlobalObject for workers? could I just override EventTargetFor?
21:45billmor does it not work that way?
21:45bkellybillm: that would work yes... sorry, got confused... its in dom/workers/WorkerScope.* I think
21:46bzbillm: and
21:46bzPlus there's the worklet global scope
21:46billmbkelly: ok, cool. is there a way to get the thread from a WorkerScope?
21:47bkellybillm: we would have to store it there at startup... don't think its there right now... RuntimeService sets up both I think
21:47bkellybillm: sorry, I have to run to dinner right now
21:47billmok, I'll file something
21:53billmbz: would it work to use scope->mWorkerPrivate->mThread?
21:55bzbillm: Seems fairly possible.
21:55bzbillm: I mean, right now I _think_ the worker global hands back mainthread as its event target thing
21:56billmyeah, it does
21:56billmwhich makes no sense
21:56bzRight, I was going to say. ;)
21:56bzUsing the worker private's mThread makes sense to me
23:50bkellyactually, I think WorkerPrivate::GetEventTarget() would make more sense
23:52* bkelly responds on the bug.
23:53qDotFor someone familiar with test_interfaces.js: - This would turn on WebVR for /only/ windows release builds, right? I think they just want windows: true?
23:58qDotOh, wait, no, was misreading the logic. That makes sense. open everywhere that's not release, only release on windows.
19 May 2017
No messages
Last message: 10 days and 14 hours ago