mozilla :: #content

12 Oct 2017
08:30smaugjessica: FYI, I'm still hoping hsivonen would answer to the email too
08:30smaugabout the parser
08:33jessicasmaug: sure, let's wait. I have a new patch coming but it's to fix the innerHTML case.
13:57froydnjbaku: ping
14:39bakufroydnj: pong
14:39bakufroydnj: I wrote a comment.
14:39froydnjbaku: ni?'d you on the bug
14:40bakufroydnj: yep. already answered.
16:19smauggabor: ping
16:19gaborsmaug: pong
16:19smauggabor: I think I found. dom.ipc.processPrelaunch.enabled controls the preloading of a process, right?
16:20gaborsmaug: correct
16:20smaugJust need to disable it for process creation speed testing
16:21gaborsmaug: the cpstartup talos test does something like that... well content process startup plus all the process/frame scripts executing combined actually
16:22gabor(spoiler: it's not fast enough)
16:26bkellyI just loaded a page... and got a white screen.... when I opened inspector and hovered over elements in DOM they started painting
16:27gaborso lazy painting?
16:29bkellygabor: really lazy... perhaps a bit too lazy
16:30firebotBug 1408060 NEW, tab failed to paint on FF57
16:45bzbkelly: Do you have webrender turned on by any chance?
16:45bkellybz: not that I'm aware of
16:45bkellyI posted my support output in the bug
16:45bzyeah, I see
16:45bzno webrender
16:46bzThat means users might hit it too..
16:46bkellybz: I&#39;ve been running beta 57 for a week or two... this is the first time I&#39;ve seen it AFAIK
16:47bkellyoh, but I see a facebook ghost window :-(
16:49bzA faceless book, you say?
16:52ursuladthayer: ping
16:52bkellybz: uh... 12k callback references?
16:52dthayerursula: pong
16:52bkellybz: 000002A588B9C000 [rc=12432] nsGlobalWindow # 4294971081 inner
16:54bkellybz: ugh... taking a verbose GC log cleaned it up
16:54ursulahey, i&#39;m working on activity stream, where we&#39;re now loading about:newtab in the content process (rather than the main process where the old newtab lives). we&#39;ve run into some performance concerns now that we&#39;re in the content process, mainly a white flash when opening a newtab before seeing any of the content loaded
16:55ursulawas wondering if you had any insights on what would be causing that? i can link to some bugs for more context
16:55bkellyursula: we preload about:newtab in the process, no?
16:56ursulathere seems to still be some overhead though in loading it in the content process at all
16:56smaughave you profiled it?
16:56smaugor is the white flash coming from graphics layer... compositor not having the data soon enough
16:57ursulai&#39;ve got a profile handy actually maybe someone could see it?
16:58ursulasmaug: it does make a sync call to the compositor thread:
16:58firebotBug 1373773 NEW, PCompositorBridge::Msg_NotifyChildCreated sync IPC when opening tabs
16:59dmoseursula: so you&#39;re seeing the flash on mac, correct?
16:59ursulawe&#39;re not sure if that&#39;s contributing to the white flash
16:59ursuladmose: yep
16:59dmoseursula: so compositor thread is windows-only, believe
16:59smaugursula: what does preloading mean in this context?
16:59dthayerI went down that road in 1389546, but the white flash was only going away for me because my change inadvertently flipped the logic at this line:
16:59smaugdmose: you mean compositor process?
17:00ursulasmaug: we get another newtab ready in the background after you&#39;ve opened up a newtab so that can swap the ready one in when we open a new tab
17:00smaugthat might be windows only
17:00dmosesmaug: perhaps im confused.
17:01smaugursula: right. ok, so it hasn&#39;t been painted yet, I guess, since there hasn&#39;t been need to paint it or so
17:01smaugmstange: you might have some ideas here
17:02dmosesmaug: it looks like you&#39;re correct. apparently the main reasoning for using Quantum Compositor in separate process on windows was because of browser device driver instability, and there&#39;s no such problem on mac.
17:04ursuladthayer: is that patch going to land?
17:04smaugursula: I could imagine something like this to happen: parent process switches tabs, this puts a new tab to foreground, then paint is requested -> message to compositor, which sends back vsync, refreshdriver ticks in child process and paints, and then we have data ready to composite
17:04smaugmstange: does that sound reasonable
17:05dthayerursula: I got sidetracked onto other things and it fell by the wayside. if a patch for that bug lands though it&#39;s going to look very different
17:05dthayeri think visually fixing the white flash might be most easily done by fiddling with that logic in the tab switcher though
17:05dthayerbecause the flash is only ever a frame or two, which makes displaying the previous tab until it&#39;s ready unnoticeable
17:06dmoseursula: it looks like the flash code was last touched in
17:06firebotBug 1342927 FIXED, Don&#39;t wait for a layer tree if the TabChild hasn&#39;t actually been created yet
17:06smaugdoes the flash happen only when a preloaded tab is shown first time?
17:07ursulasmaug: no, on every tab
17:07smaugI guess so
17:07smaugursula: hmm
17:08smaugperhaps we don&#39;t store the layers
17:08dmoseso looking at that bug i just pasted seems to suggest that if that code is in play, it&#39;s because the content process is blocked and can&#39;t actually render the tab yet
17:08smaugmstange or other gfx folks would know better this stuff
17:08dmosebase on a very naive reading of comment 0
17:13ursuladthayer: so the patch you&#39;ve got in bug 1389546 gives the preloaded tab an active state, which means we show that tab immediately rather than switching to it once we figure out that it&#39;s the tab being shown?
17:14firebot ASSIGNED, Set the new tab page as active when preloading enabled
17:14ursulaand as a result gets rid of the flash
17:14ursulabut why wouldn&#39;t that reproduce itself when the newtab is running in the main process?
17:17ursulasmaug: what you described above, that means the flash of white comes from the time it takes between the when paint is requested to when we have data ready? and since it needs to communicate with the child process, the entire thing takes a tad longer?
17:17dthayerursula: the patch in that bug should probably be ignored - I don&#39;t remember exactly where it screwed things up, but basically a bug led to the &quot;showTab = this.lastVisibleTab;&quot; path being taken
17:18dthayerursula: you can see the white flash &quot;go away&quot; by just adding &quot;shouldBeBlank = false&quot; right below where it&#39;s set
17:18smaugursula: right. parent->child communication is after all certainly async
17:18dthayeron line 4533
17:18dthayer(of tabbrowser.xml)
17:18smaugursula: but gfx folks might have ideas whether this could be improved in gfx lever, or whether this needs to be fixed in tabbrowser level
17:20ursulasmaug: cool. i&#39;ll bug them in toronto about it. thanks!
17:22ursuladthayer: yeah you&#39;re right, the flash does &quot;go away&quot; with just that change. there were some mem concerns with taking this approach?
17:23dthayerursula: the memory concerns were from setting the preloaded tab to active beforehand, which turns out to not be the deciding factor in making the flash go away
17:25ursulawhat&#39;s the deciding factor then?
17:27dthayerthe deciding factor was shouldBeBlank being false (or equivalent) for the new tab page, which results in &quot;showTab = this.lastVisibleTab;&quot;
17:27dthayermeaning we keep displaying whatever tab you&#39;re on until the new tab page is ready to display
17:27dthayerwhich since it only takes 1 frame, makes it appear instant
17:34dmoseexcept that we&#39;re opening a new tab
17:34dmoseoh, i see
17:34dmosenever mind
17:59ursuladthayer: ok this is some great info, thanks for all your help! we may bug you a bit more about this in the future if that&#39;s ok
17:59dthayerursula: of course!
18:58smaugddurst: curious, have you used devtools?
18:58smaug(I&#39;m about to start to look at the logs. Sorry about delay)
19:00smaugprocess 41378 has some ghosts
19:00smaugtwitter in particular
19:01smaugbkelly: did you say something about ghosts earlier today?
19:05ddurstsmaug: sorry, you mean in looking at what&#39;s going on?
19:06smaugddurst: I mean, have you used devtools when you see the high pause times?
19:06smaugI guess with twitter tab for example
19:06ddurstRight, I mean: do you mean to investigate, or do I use it in the session where I see this issue?
19:07ddurstno to the former, yes to the latter
19:07smaugddurst: the latter
19:07ddurstYes, but not a lot. And it&#39;s usually use and then close. But I can&#39;t say that I&#39;ve used devtools every time this has happened.
19:07bkellysmaug: the ghost went away when I get the verbose CC logs
19:08smaugddurst&#39;s concise log is so large that this machine may not have enough memory to analyze it :/
19:08smaugmccr8: do you have some desktop machine with tons of memory?
19:08ddurst(sorry, this session has been running for about a week)
19:09ddurst(took 3 days to even start to see the problem)
19:09smaugI guess you&#39;ve had twitter open for long time?
19:11smaug95000+ elements from twitter in the concise log
19:15smaugoh, I managed to run find_roots. Had to first close most of other programs
19:27smaugcrap, the verbose log doesn&#39;t know about the missing edge
19:29smaugSomething keeps a ref to an inner window
19:52smaugddurst: do you have any unusual prefs set?
19:52ddurstdefine &quot;unusual&quot;
19:53ddurstthe only thing I *think* I&#39;ve set on that machine was forcing to e10s previously.
19:53ddurstBut I&#39;m happy to check ... anything changed.
19:56bkellysmaug: the thing I saw earlier had 12k callback listeners on it... but then when I ran another memory report after collecting CC logs it was gone
19:56smaugbkelly: if one has tons of elements around (if the page itself is leaking), that isn&#39;t too unexpected
19:57smaugevery element might have several listeners
19:57ddurstsmaug: looking at modified prefs now -- not entirely sure what to look for
19:57smaugso, might not even need a page leak
19:58smaugddurst: want to pastebin the prefs section from about:support?
19:59smaughmm, ddurst: have you possibly used &#39;find&#39;?
20:00smaug(logs don&#39;t help too much here, so need to just go through somewhat random possible suspects)
20:03ddurstI have almost certainly used &#39;find&#39;
20:03* ddurst waiting on pastebin
20:12smaugnothing unusual there
20:15ddurstalso, battery is dropping unusually quickly
20:18froydnjooh, does ddurst have a replicatable battery drain problem?
20:18ddurstwhat was that bug #?
20:18ddurstlooking like 1% per minute
20:19ddurstmind you, not the newest machine...
20:19froydnjddurst: bug 1404042
20:19firebot NEW, Poor battery life on OSX
20:19froydnjat least, that appears to be the latest incarnation
20:20ddurstsounds like what I&#39;m seeing. 1% drop every 1-2 minutes.
20:20ddurstI&#39;m running 10.11.6 on a mid-2010 MBP, 8GB
20:21smaugwhat is &quot;vibrancy&quot; that the bug is talking about
20:24ddurstit... seems to be a slight translucency in the UI, introduced in Yosemite
20:24* ddurst calling it &quot;vibrancy&quot; seems lame
20:26smaugOne day I&#39;ll update the old macbook laying around. Have I booted it this year? probably not.
20:26qDotOof. I really hope we aren&#39;t interviewing people in the bay area today.
20:27qDotsmaug: Massive amounts of air pollution due to wildfires. Breathing sucks right now, and I&#39;m learning how important oxygen is to coding. :|
20:28smaugoh, I see. The smoke comes from LA area to the Bay area?
20:28qDotSo we&#39;d basically be whiteboarding people in oxygen debt. XD
20:29smaugddurst: do you do anything special with the twitter tab?
20:29smaugI could try to reproduce in a debug build
20:29qDotsmaug: No, there&#39;s fires in northern california now, near Napa, blowing stuff south.
20:30ddurstsmaug: no. In one case, I left one open for a while because twitter seemed to suffer from this faster than other sites. But I&#39;ve since closed that tab.
20:30ddurstfroydnj: I just turned off this vibrancy thing to see if there&#39;s an impact.
20:31* bkelly is afraid to discover how bit-rotted these patches are...
20:42* ddurst comments in 1404042
20:45bkellyhmm... conflicts in 23 files
21:02bkellyhey, look... one of those conflicts was because the fix landed upstream
21:18mystorfroydnj: Hey, with the nsstring move constructor patch, the reason for the weird `explicit on the line before` thing was because all of the other constructors in nsString do that too - I could make them on one line, but it would be inconsistent with the other constructors
21:49froydnjmystor: uh. that&#39;s weird, but ok, then, when in rome...
13 Oct 2017
No messages
Last message: 5 days and 46 minutes ago