User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170402030202 Steps to reproduce: Open about:performance tab. Actual results: It only shows web page performance of currently open tabs. Expected results: It should also show addon performance.

An update was pushed on April 1st that broke uBlock Origin and uMatrix. The about:performance was showing addons but not all of them. Today's Nightly won't display any addons.

It register just new tabs, only these ones after opening about:performance, old ones aren't shown.

This isn't caused by the hidden window changes, it's caused by me removing add-on perf monitoring. (In reply to smartfon.reddit from comment #1) > An update was pushed on April 1st that broke uBlock Origin and uMatrix. The hidden window changes did break uBO and uMatrix, but fwiw, I put up patches for uBO and they are already merged into the development version ( https://addons.mozilla.org/en-us/firefox/addon/ublock-origin/versions/beta ). I believe the developer has also integrated those patches into uMatrix. Add-ons no longer appearing in about:performance is expected. It was using the same monitoring infrastructure that the "This add-on is making Firefox slow" notification was using, and I removed all of that code. See bug 1309946 comment 22 for some of the reasoning. (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #2) > It register just new tabs, only these ones after opening about:performance, > old ones aren't shown. I'm not sure off-hand what you mean by "old tabs". I'm trying to reproduce the problem and tabs loaded before about:performance do show up for me. Tabs that haven't been session-restored yet (so no window/docshell/whatever) don't show up, which seems like the right thing? Can you be more specific what you mean by "old tabs" and check if that's really a recent regression? It might be that that change is caused by changes in how the tabbrowser does session restores - I know Dão is working with some folks who are trying to make session restore better for people with lots of tabs.

(In reply to :Gijs from comment #3) > This isn't caused by the hidden window changes, it's caused by me removing > add-on perf monitoring. Oh, sorry, my bad, I was basing on comment #2 (In reply to :Gijs from comment #3) > (In reply to smartfon.reddit from comment #1) > > An update was pushed on April 1st that broke uBlock Origin and uMatrix. > > The hidden window changes did break uBO and uMatrix, but fwiw, I put up > patches for uBO and they are already merged into the development version ( > https://addons.mozilla.org/en-us/firefox/addon/ublock-origin/versions/beta > ). I believe the developer has also integrated those patches into uMatrix. Yes, it's already fixed in uBlock Origin 1.11.5rc6. Thank you very much for this! > (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see > your comment/reply/question/etc.) from comment #2) > > It register just new tabs, only these ones after opening about:performance, > > old ones aren't shown. > > I'm not sure off-hand what you mean by "old tabs". I'm trying to reproduce > the problem and tabs loaded before about:performance do show up for me. Tabs > that haven't been session-restored yet (so no window/docshell/whatever) > don't show up, which seems like the right thing? Can you be more specific > what you mean by "old tabs" and check if that's really a recent regression? > It might be that that change is caused by changes in how the tabbrowser does > session restores - I know Dão is working with some folks who are trying to > make session restore better for people with lots of tabs. STR: 1. Start Mozilla Firefox Nightly 55.0a1 2. When Firefox starting, open some amount of tabs, ex.: - http://forums.mozillazine.org/viewforum.php?f=23 - https://bugzilla.mozilla.org/ - https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Bugs%20Filed%20Today&sharer_id=159758&list_id=13328177 - https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=FROM&tochange=TO - https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=FROM&tochange=TO 3. and in the end about:performance 4. to see that not every tab is seen in about:performance (see screenshot)

(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #4) > STR: > 1. Start Mozilla Firefox Nightly 55.0a1 > 2. When Firefox starting, open some amount of tabs, ex.: > - http://forums.mozillazine.org/viewforum.php?f=23 > - https://bugzilla.mozilla.org/ > - > https://bugzilla.mozilla.org/buglist. > cgi?cmdtype=dorem&remaction=run&namedcmd=Bugs%20Filed%20Today&sharer_id=15975 > 8&list_id=13328177 > - > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=FROM&tochange=TO > - > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=FROM&tochange=TO > 3. and in the end about:performance > 4. to see that not every tab is seen in about:performance (see screenshot) Aha, OK. So, I think I know why this is... we will only display pages for which samples have been collected (so for which some amount of JS has run at some point, more or less). It used to be that we started collecting these samples from Firefox startup. Now this only happens when you actually open about:performance. When I follow your steps (but with a different set of pages), at one point I did manage to see fewer-than-expected pages show up... but a few seconds later, more pages showed up. In your test set, especially the hg pages (and maybe others) don't actually run JS themselves at all once they've loaded. It seems the hg pages load a JS file (mercurial.js), but it seems to be unused on most pages, AFAICT. So nothing will show up. (about:performance is, to the best of my knowledge, purely based on JS measurements, not on things like how expensive reflows are, or media that's playing, or other stuff that might be slow - which is generally fine because JS is usually the slowest thing anyway.) We could potentially teach about:performance to iterate over tabs itself and display "no data" or "no JS performance impact" or something for those tabs... but given that about:performance is still a hidden page etc., I don't think that's super high priority right now. I definitely don't think that we should add back the monitoring to all pages, all the time, from startup, just for this bug. :-)

Gijs, should we track this as a regression? Comment #3 sounds like this is intentional. Thanks!

(In reply to Mike Taylor [:miketaylr] from comment #6) > Gijs, should we track this as a regression? Comment #3 sounds like this is > intentional. Thanks! I mean, it is technically a regression, and I didn't foresee this consequence, so I struggle to call it "intentional"... but equally, I don't think the current state is *harmful* - it is merely confusing, especially if you were used to the previous state. But it's also not inaccurate, given that the invisible tabs just really aren't creating any performance impact at all. So I don't think this needs to be prioritized as a serious regression. Does that answer your question?

OK, yes! Given the nature of the bug (and your explanation) I think we don't want to consider this a 55-blocking regression, so I'll set it to "fix-optional".

about:performance is being redesigned; mass closing the bugs related to parts of the current about:performance page that we are not keeping. Our goals with the redesign are to reduce the overhead caused by having the page opened, increase the reliability of the displayed information, and make the offered information actionable for most users. The back-end work is being tracked in bug 1419681.