#1400259 [Firefox:Toolbars and Customization]-Last used submenu/item is visible/highlighted in "Hamburger" (and page action, and other photon panel) menu(s) after landing patch from bug #1374749 [Win][[reserve-photon-structure]]

That's right. The Dev Channel receives the new version (58) almost a week before Beta does.

Friday the 3rd a copy of Nightly (58.0a1) was captured and modifications were made before that modified code landed in the Dev Channel last Tuesday the 7th as 58.0b1.

Between last Tuesday and this coming Monday the Beta Channel has had its 57 beta code tweaked to become "57.0" that we mere mortals would think of as the Release Candidate. There was an additional RC and there might be more. But on Monday the 13th that comes to an end because on Monday the 13th the Beta Channel is scheduled to receive 58 code designed to become Beta 58. It should be quite similar to Dev 58 but lacks the tweaks that make Dev friendlier to developers, but from that point, on, Dev and Beta should be receiving the same maintenance.

Then on Tuesday the 14th the Release Channel is scheduled to receive the most recent Release Candidate "57.0" that was formerly in Beta but now is the official Release. Typically Mozilla releases the new version to a portion of Release Channel users first and monitor for problems before opening up the 57 upgrade to more users. So the actual rollout may be over the course of several days.

Nightly? While it is scheduled to become 59.0a1 on Monday the 13th, the actual version number change isn't that significant since it will be receiving code that makes 59 be 59 throughout the life of the version, though during the last two weeks or so it seems that major changes aren't made so the code could be tested before the code is cloned to become the next Dev/Beta.

It looks like there are a lot of paints happening in the new profile you linked to. The average refresh driver tick time is ~16ms-25ms. Of that rasterization (capture with OMTP) is ~6-8ms, and the rest is display list and layer building.

We don't have great markers for OMTP, so I can't tell how long the actual rasterization is, but I can see that the following refresh ticks aren't being delayed much. Estimating from paint thread samples, I'd say rasterization is ~6-8ms.

I do notice that the content threads sometimes are actually running scripts and doing other things while we rasterize so that's a win for OMTP.

Overall I don't see OMTP misbehaving here with blocking or other async weirdness.

It looks like this page has a lot of work to do with display list building (it's essentially a giant table). I also noticed that as you scroll, images will transition in for table entries. My guess is there is a script doing this, and that's what's causing us to paint so much.

Omega X wrote:OMTP just got more patches. Not sure what they do, the bug has no description.

Give a man a fish, and he eats for a day. Teach a man to fish, and he eats for a lifetime.I like poetry, long walks on the beach and poking dead things with a stick.Please do not PM me for personal support. Keep posts here in the Forums instead and we all learn.