mozilla :: #content

11 Aug 2017
00:45kanrusmaug: what counts start of page load?
00:45kanrusmaug: there are navigation timing markers
01:08asuthIs "Raw pointer to ref counted object issues - Version 2" the most recent place to look at cool (as in dangerous) weak references found by tooling?
01:08asuth(It's a google sheets doc)
04:00asuth"mach build" should have a sanity check for linux users to make sure they have 16gigs free of physical RAM so their machine doesn't hard-lock during the build.
04:00asuthAlso, maybe it was a bad call to not have any swap enabled. Clearly swap is a super-power that slows down time so you can stop things that are going wrong. I should put a spinning disk in the machine just so I can add swap to it.
14:37snorpsmaug: I used to add a marker at those points, but it's bad to keep it in the tree all the time
14:37snorpsmaug: we could ifdef it though
14:37snorpsmaug: you can build a dynamic marker that includes the url
15:00annevkbz_sleep: I updated the various data URL bugs with some research and links to standards issue / proposed test format
15:01annevkbz_sleep: if you could review somewhere today and give feedback that'd be great, but I think I have enough to keep going for a bit
15:02annevkbz_sleep: the intersection with MIME type parsing seems a little icky as e.g., data:text/html;a=",",hi is not parsed by any browser as it should be
15:02jdmvendoring will impact mozilla-central too
15:03annevkbz_sleep: it's not clear if at that point we should just embrace the brokenness or hope for a much better tokenizer (or some kind of MIME type parse function that advances the pointer...)
15:03annevkbz_sleep: anyway, thought's welcome, unlikely I'm checking back in today, but I'm connected to IRCCloud and will check history
15:03annevkbz_sleep: but updating the various bugs/issues is probably better
15:28smaugwhat if... paint suppression for initial about:blank would be longer and not cleared at "load" time
15:31snorpugh paint suppression
15:32smaugif we don't paint so aggressively, other stuff has better chance to run
15:32smaugimproves benchmarks quite a bit
15:32snorphow about we never actually paint about:blank and instead short-circuit it
15:32snorpjust tell the compositor to glClear() to white
15:32smaugright, un-modified about:blank perhaps
15:37bzannevk: yeah, I'm not sure what the right thing is here.
15:37bzannevk: On the one hand, specifying simple parsing is nice.
15:37bzannevk: On the other hand, being able to use an off the shelf MIME type parser is nice.
15:38bzannevk: On the gripping hand, are there off the shelf MIME type parsers? ;)
16:03mystorfroydnj: Hey, do you have any idea why the changes I made in new_bhr_ping might have caused windows 32-bit mochitests to start timing out?
16:03mystorfroydnj: (I'm guessing the answer is no, but I figured I'd ask)
16:06froydnjmystor: uh. is that the one with sending message manager messages instead of observers?
16:06mystorfroydnj: <- it&#39;s just the entire mochitest times out
16:06mystorfroydnj: not related to the test_BHRObserver test at all :-/
16:07mystorfroydnj: (THe patches which seem to have caused this afaict are the changes to the ping format)
16:07froydnjmystor: which patch out of the 20 is new_bhr_ping? or is that an existing test?
16:07* froydnj is confused
16:08mystorfroydnj: Fair, I wasn&#39;t very clear, I think it&#39;s one of the patches on bug 1380081 which did it - don&#39;t have the ability to build win32 builds locally right now so I&#39;m not sure which one
16:08firebot NEW, Update BHR ping format
16:08mystordoing some try pushes to try to narrow it down
16:09mystorI have no idea why though :-/
16:12froydnjmystor: I can&#39;t even find new_bhr_ping in that log
16:12mystorfroydnj: Yeah, sorry
16:12mystorfroydnj: new_bhr_ping is the local name I use for the branch where I developed that bug
16:13mystorI&#39;m being incoherent right now :S
16:13mystorwhen I refer to new_bhr_ping I&#39;m refrering to the entire bug
16:13* froydnj grumbles about run-multiple-tests making it super difficult to actually find the failing tests in the log
16:14mystorfroydnj: As far as I can tell no tests are failing
16:14mystorfroydnj: Instead the tests are finishing and then we&#39;re timing out due to IDLENESS_LIMIT_EXCEEDED
16:15froydnjmystor: or maybe we haven&#39;t run all the tests compared to what, say bc2 was supposed to run?
16:15mystorIt&#39;s exactly at 1h, so maybe I&#39;m slowing down tests somehow to cause them to take more than an hour?
16:15froydnjthe log is not especially clear what is happening
16:15froydnjmystor: slowing down tests seems like a reasonable supposition
16:18mystorfroydnj: I&#39;ll look through the patches to see what might be slowing it down
16:24annevkbz: too small for a Rust project I guess? Also prolly tricky if it needs to integrate with a C++ parser
16:24bzannevk: you mean MIME parser?
16:24annevkbz: (I assume there are MIME type parsers out there, but I don&#39;t know if any are good, I suspect it&#39;s rife with interop issues such as this one)
16:25bzThat would be my guess too
16:25bzMIME type parsing is deceptively easy-looking
16:25bzesp. if you don&#39;t read the RFC
16:26bz(and Content-Type headers are even worse, because they can be a list of &quot;mime types&quot;
16:26annevkwell and the RFC is wrong
16:26annevk&quot;text/html;&quot; has to work as a MIME type yet doesn&#39;t parse per the RFC
16:26bzThat&#39;s normal. ;)
16:27annevkI wish the IETF tried to run their code now and then to see if it still functions
16:27annevkOr maybe the running code part is just an urban myth
16:29annevkI guess the Content-Type thing is a result of duplicate Content-Type headers?
16:30annevkSo I guess I&#39;ll focus on all the other data URL issues first and then figure out MIME type parsing as a larger project as there&#39;s lots of entry points for those
16:30bzSounds good
16:47bkellyehsan: do you know what &quot;Firefox (Beta) (Ion)&quot; is here?
16:48bkellyI guess its FF56 beta
16:48bkellyofficial PGO build, probably
16:48ehsanbkelly, not more than what the label suggests :)
16:49bkellyehsan: surprisingly better perf on that one data point compared to trunk
16:49ehsangiven the score that&#39;d make sense
16:49ehsanwhy surprising?
16:49bkellyehsan: maybe because of DIAGNOSTIC_ASSERT?
16:49ehsanwe have nighly only code that shows up in profiles
16:49bkellywell, m-c improvements have been made since 56 branched, no?
16:49ehsanfor example we have telemetry around the event loop
16:50ehsanform autofill
16:50ehsanbkelly, if you take any random changeset and build it with the right mozconfig to simulate the release channel it&#39;ll get a bit faster due to those factors
16:51bkellyehsan: ok.. thats kind of what I meant about the diagnostic assert thing... we have extra cruft in nightly
16:51ehsanbkelly, (perhaps diagnostics asserts themselves also contribute to the cost, I haven&#39;t seen any of them in profiles personally but that doesn&#39;t count for much :)
16:52ehsaninterestingly chrome has similar behavior going from canary -> release
17:02smaugehsan: were you going to ask review for bug 1385389 ?
17:02firebot NEW, Consider not deleting the common ancestor hashtable in nsRange::UnregisterCommonAncestor()
17:02bkellyehsan: ah... I *do* see equivalent perf or slightly better running dev edition 56 compared to nightly
17:02bkellyon my machine
17:02bkellyI haven&#39;t gotten beta 56 yet to test
17:19mystorfroydnj: I pushed a patch which just disables the BHRTelemetryService (as that runs on the main thread in the parent process), and the timeouts seemed to stop
17:20mystorfroydnj: So I&#39;m guessing that service is just really slow
17:22froydnjmystor: well, that&#39;s no good
17:22froydnjmystor: wonder which part of it is so slow
17:22mystorfroydnj: But it&#39;s something I can fix
17:22mystorfroydnj: I&#39;m not sure - I&#39;m thinking what I&#39;ll do is set up something on a background thread which we notify and performs the accumulation, and just dispatches to the main thread to actually submit the pings
17:22mystorfroydnj: So we do the absolute minimum amount of work on the main thread
17:29ehsansmaug, yes, after I address your review comment :)
17:29ehsansmaug, sorry, I&#39;ve had a super long backlog... still on my list to get to
17:29ehsanthe said backlog is getting longer sadly...
18:29bkellyI like how this bug had a qawanted flag for 13 years...
18:29firebotBug 83471 FIXED, Redirection loops
18:29bkellythats a long time to wait
19:40snorpbkelly: sorta playing with my bundling idea
19:41snorpbkelly: using chrome because of reasons
19:41snorpbkelly: interestingly I don&#39;t seem to always get a fetch event, is that right? seems like I should get it every time regardless of caching?
19:42bkellysnorp: higher level cache like img cache can prevent a fetch event...
19:42snorpbkelly: it&#39;s img, yeah
19:42bkellysnorp: its not very well spec&#39;d... I have an issue open on it
19:43bkellysnorp: img cache should response cache-control headers
19:43bkellyif you set it to be uncacheable
19:43bkellyshould respect
19:53snorpheh, chrome networking shit itself
19:53* snorp notifies blassey
19:54* blassey looks for a doc on how to file better bug reports
20:30mystorfroydnj: so umm - I think I finally figured out what was messing up perf
20:30froydnjmystor: oh?
20:30mystorfroydnj: There&#39;s a typo in the BHRTelemetryService.js which meant that it would submit a ping every time that a hang was detected
20:30mystorfroydnj: Which can&#39;t be cheap
20:31froydnjmystor: whoops!
20:31froydnjreview fail =/
20:31mystorlol - it&#39;s my fault too
20:31mystorI refer to a constant which I renamed but didn&#39;t change the use of
20:31mystorand comparing numbers against undefined is fun times
20:32froydnjJS ftw
20:32mystorI love how I wrote _one_ file of JS and have a classic JS bug in it already ^.^
21:19bkellyasuth: sadly I think I will have quite a few more patches in bug 1204254
21:19firebot ASSIGNED, service workers should stream response bodies when intercepting a channel
21:20asuthbkelly: okay, but I&#39;m hooked on well-split patches now, so I expect a *ton* of patches.
21:20bkellyasuth: one patch per statement changed it is
22:52qDotGod damnit docshell.
23:10mystorfroydnj: That wasn&#39;t it :&#39;(
23:10mystorfroydnj: (gosh I hate the turnaround time on this bug)
23:10mystorfroydnj: I did figure out what&#39;s happening though - in the good push every process shuts down promptly, while in the bad push we have to wait 3 minutes for the process to shutdown every time
12 Aug 2017
No messages
Last message: 10 days and 14 hours ago