Open Bug 1300411 Opened 5 years ago Updated 1 year ago
user reports excessive load spinning when switching tabs with e10s in 48
.0 .2 release
611.21 KB, text/plain
6.14 KB, text/plain
28.38 KB, text/plain
2.39 KB, text/plain
86.07 KB, text/plain
50.71 KB, text/plain
76.80 KB, image/png
User reports that media sites seem most troublesome: "Facebook or sites containing youtube embed videos give me more problems."
we got similar reports about this issue on sumo as well. i filed bug 1297496 for this.
See Also: → 1297496
Mike, can you dig into this?
Looked at some of our Telemetry data. Here's the probe on the spinner: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2016-09-01&keys=__none__!__none__!__none__&max_channel_version=beta%252F49&measure=FX_TAB_SWITCH_SPINNER_VISIBLE_MS&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-08-02&table=0&trim=1&use_submission_date=0 My interpretation of this is that, when we _do_ show the spinner, we tend to show it for a long, long time. :/ That's not great. I've opened communications with the reporter to get more data. My plan is to hopefully give the reporter an instrumented build with some logging that'll help me determine what's happening.
Assignee: nobody → mconley
I'm in contact with the original reporter. One interesting finding is that if the user force-disables e10s, everything becomes a lot smoother. No performance problems whatsoever. I've given detailed instructions to the reporter on how to give us a performance profile. I hope to have that soonish.
My preliminary investigation of beta shows nothing obvious on the gfx adapter manufacturer angle: https://sql.telemetry.mozilla.org/queries/1142/source Of the population reporting spinners, I compared the population reporting >1s spinners to the population not reporting spinners > 1s and saw that they were within variance of each other (Intel 5.3%, NVIDIA 3.5%, AMD 4.0%) If one chipset manufacturer were to blame, I'd expect a much larger difference.
Is there any correlation with 32-bit windows builds here? For example, if switching tabs triggers IPC runnables to be fired which then trigger GC because we're close to a small OOM?
(In reply to Ben Kelly [:bkelly] from comment #7) > Is there any correlation with 32-bit windows builds here? For example, if > switching tabs triggers IPC runnables to be fired which then trigger GC > because we're close to a small OOM? The situation is slightly worse on 32bit vs 64bit based on the data we have (26% vs 20% of samples are in the last bucket), but I don't think this is exclusively a 32bit problem. https://telemetry.mozilla.org/new-pipeline/dist.html#!compare=architecture&cumulative=0&end_date=2016-09-01&keys=__none__!__none__!__none__&max_channel_version=beta%252F49&measure=FX_TAB_SWITCH_SPINNER_VISIBLE_MS&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-08-02&table=0&trim=1&use_submission_date=0 That said, untimely GC is an interesting theory. Bill has been thinking about GC anc CC scheduling lately, NI'ing him
:blassey wanted to know what distribution egregious (>1s) stalls took. How many clients are experiencing how many stalls over time? How bad is this experience? Here's a query about Beta 49 test-branch: https://sql.telemetry.mozilla.org/queries/1147/source In the Good News column, 97.5% of all clients reported fewer than 0.95 egregious spinners per hour. 73.5% reported essentially none (< 0.05 per hour). In the Bad News column, 2.5% reported at least one per hour. And roughly 0.2% are seeing five or more _per hour_. Maybe this query can act as a starting point for identifying the unlucky ones and seeing if they have commonalities.
I can fairly easily reproduce a >4s spinner (e.g., FX_TAB_SWITCH_SPINNER_VISIBLE_MS average 4665.7) How can I help?
Thought, Brad mentions bug 1279086, so I will wait for that to land and retest.
Is it also possible to do a correlation analysis to see if users with long tab switch times tend to have large numbers of tabs open? (browser.engagement.max_concurrent_tab_count scalar probe)
(In reply to Mike Conley (:mconley) - (Digging through needinfos and reviews) from comment #13) > Is it also possible to do a correlation analysis to see if users with long > tab switch times tend to have large numbers of tabs open? In my Google Docs workflow, the number of tabs is 4-5.
I also do often see the spinner. - very-very often 6-y-old notebook - very often 6-y-old notebook (i5-450m, 8Gb RAM, SSD) notebook - pretty rare AMD Phenom II X4 955, 8Gb RAM, SSD - rare i5-6600, 16Gb RAM, SSD The less powerful the PC is, the often the spinner comes.
Sorry, forgot to add the specs: - very-very often 6-y-old notebook - some dual core Pentium 1.3, 4Gb, SSD
Can the spinner be disabled? It would help to decide whether the appearance of the spinner itself aggravates the situation or not.
(In reply to Eugene Savitsky from comment #16) > - very-very often 6-y-old notebook - some dual core Pentium 1.3, 4Gb, SSD This might help disprove the "low RAM triggering long GCs" theory. 4GB seems a reasonable amount of memory. Our correlation with spinners to low memory could have covariance with cpu power. Machines with lower end CPUs probably have less memory as well.
Eugene, is there any chance you could take a profile using your "very-very often 6yo notebook"? Mike wrote up some instructions here: https://github.com/mikeconley/getting-profiles-from-users/blob/master/48.0.2.md I'm sorry, I know its rather involved. It would be extremely helpful to us, though. Thanks!
OK. For that notebook I can do this on Monday. Now I'm on the "- very often 6-y-old notebook (i5-450m, 8Gb RAM, SSD) notebook" had opened 3 tabs of http://www.bmwblog.com stories and see the spinner during page loadings. Actually I just saw the spinner opening a tab with static "Connection timeout" content, so it may tell, that the problem occurs not on the opened tab, but in the background tabs. I do the profile for this notebook now as well. It may help to understand the issue. BTW Should I set the dom.ipc.processCount to 1 process? Currently I have set it to 2.
And BTW, I'm using the Aurora branch.
Reproduced with bmwblog.com (last seconds) https://cleopatra.io/#report=13987af3385127e92a2b45ebb8a3fa15138a7c42
Thanks for the profile, Eugene. I've zoomed in the relevant portion of the profile here: https://cleopatra.io/#report=13987af3385127e92a2b45ebb8a3fa15138a7c42&invertCallback=true&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A1382665,%22end%22%3A1407433%7D,%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A1388799,%22end%22%3A1406283%7D%5D&selection=%22(total)%22,175 Two things stand out to me from the profile in comment 23 1) Eugene is running with at least one add-on, and so I see sync IPC messages occurring over the add-on shim layer. 2) It also looks like Firefox is desperately trying to clear memory here. I see a major cycle collection and garbage collection going on - each one taking over a second to complete. That'll definitely cause the spinner. 3) There are a bunch of these WindowDestroyedEvent runnables that are firing, one after the other, and they're taking their sweet time in js::NukeCrossCompartmentWrapper. That's similar to bug 818296, I guess. A caveats: Eugene is running with a non-standard configuration (dom.ipc.processCount = 2) on DevEdition with at least one add-on enabled - so whether or not the issues he's seeing here are reflective of what users on 48.0.2 might be seeing is unclear.
dom.ipc.processCount = 2 has the same issue.
I meant dom.ipc.processCount = 1
If needed, I could do a new log with = 1. Do you see the spinner opening multiple tabs with bmwblog.com articles?
(In reply to Eugene Savitsky from comment #27) > If needed, I could do a new log with = 1. Do you see the spinner opening > multiple tabs with bmwblog.com articles? What addons do you have and do things improve if you disable them?
(In reply to Mike Conley (:mconley) - (Digging through needinfos and reviews) from comment #24) > Thanks for the profile, Eugene. I've zoomed in the relevant portion of the > profile here: > > https://cleopatra.io/ > #report=13987af3385127e92a2b45ebb8a3fa15138a7c42&invertCallback=true&filter=% > 5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A1382665, > %22end%22%3A1407433%7D,%7B%22type%22%3A%22RangeSampleFilter%22, > %22start%22%3A1388799,%22end%22%3A1406283%7D%5D&selection=%22(total)%22,175 Another interesting thing about this profile is that the main process seems to be spending all of its time in sync.
https://www.dropbox.com/s/sz5zia98kb7xrjt/%D0%A1%D0%BA%D1%80%D0%B8%D0%BD%D1%88%D0%BE%D1%82%202016-09-12%2002.10.27.png?dl=0 Those addons. Will try to disable all of them.
Disabled all of them. Same problem.
Actually it seems smoother now. But maybe due I had to restart FF. Will try again tomorrow, now have to sleep (I live in EEST, UTC+3).
This might be irrelevant, but I'm posting this here just in case. I just got a "forever spinner" (> 60 seconds) on my Nightly just a few minutes after having updated it. I was switching away from an Etherpad tab to a MozReview tab. The process appeared to be slowly consuming more and more memory. I took a process sample before I killed it - see attached.
I have some profiles from a user that reported seeing the spinner periodically: https://cleopatra.io/#report=28daa9ff0fef372c8cb91244dd4746eca0a90a43 https://cleopatra.io/#report=f6824c239e5a91bc44100822446f57450a32fc14 https://cleopatra.io/#report=8527edddd7a1b1e5aaaf19de41674be78cfb2a86
Wow, those are some huge gaps where the content process is so unresponsive we're not even getting profiler samples.
(In reply to Ben Kelly [:bkelly] from comment #35) > Wow, those are some huge gaps where the content process is so unresponsive > we're not even getting profiler samples. The gaps at the start and the end of the content process profile are not because of unresponsiveness, they are because the profile buffer filled up. Each process has its own buffer, and JS stacks take up more space in the buffer, and the content process is running more JS than the parent process, so the content process can store fewer samples in the buffer. Only the third of those profiles has gaps, and they're very small gaps.
I had a look at the profiles and couldn't find an answer to why these slowdowns would be e10s specific. The content process is doing valid work during the hang times, and it's work that it would have been doing in non-e10s, too, it would just have appeared as a real hang instead of as a spinner. The only explanations for this being caused by e10s that I can think of are: (1) We're not prioritizing user input processing the same as we'd be in the parent process, (2) we're not throttling background tabs as well as we'd in the parent process, (3) we're not doing per-tab GCs as well as we would in the parent process, or (4) the content process gets executed with a lower priority so everything just takes longer. All of these are pure guesses. I really file like this is hitting the limits of what our current profiler can show us. What we really need is something like TaskTracer that shows us the state of our event queues at each point, who scheduled a runnable, and what tab each runnable is for. That would grant us a lot more insight into what's going on.
Anecdotally, I've seen the spinner more often when using AdBlock Plus (perhaps because of some of the bugs blocking bug 930787). I know this bug is about 48, where e10s wasn't enabled for users with addons, but in 49 it will be. Have we measured if the presence of addons can affect FX_TAB_SWITCH_SPINNER_VISIBLE_MS?
Seems likely that 49 will be affected. I'll go ahead and track it for 49 for now. Would it help to ask QE to do more manual testing of tab switching with e10s and maybe some of the whitelisted addons?
Hi guys, Not sure if this is related but may be helpful. I observed that having e10s enabled on latest Nightly (09.16.2016) while navigating to an nonexistent page (eg: about:addon) in a "New Tab" page will display the loading spinner for ever. Even after the browser tells you that the address isn't valid. Disabling e10s makes this no longer reproducible. The "warning" yellow favicon is displayed. Tried to narrow down the regression window for this but I've encountered another problem. All builds under 08.26.2015 are unusable for testing this. So I did some manual regression and here are my results: - last good build was on 03.29.2015 and had e10s disabled by default. Starting with 03.30.2015 build the page cannot be loaded and e10s is enabled by default. - first bad e10s build on which I can test this is from 08.26.2015, and it reproduces like on latest Nightly from today (09.16.2016). So a pretty long period between that I cannot verify. One more thing. Someone mentioned in one of the posts that he reproduced the issue on low end PC's. I managed to reproduce the above issue on high end PC's with AMD octacore and Intel i5 processors with 16gb of RAM and one of the even has an nVidia 210 dedicated video card.
After reading a bit more on the issue, it seams that what I encounter is a totally different issue. I will probably log this separately.
We investigated this issue on the following environments:  AMD FX 8320 CPU, 16 GB RAM, NVidia GeForce GT 920 GPU - Windows 10 x64  Microsoft Surface Pro 2: Intel Core i5-4300U CPU, 4 GB RAM, Intel HD 4400 GPU - Windows 10 x64  AMD FX 8320 CPU, 8 GB RAM, AMD Radeon 7700 GPU - Windows 10 x86  HP ProBook 470 G3: Intel Core i5-6200U CPU, 8 GB RAM, Intel HD 520 and AMD Radeon R7 M340 GPUs - Windows 10 x86 These are the results: * On  and  - we didn't manage to reproduce the issue * We managed to get at most 1 sec of load spinning on  * We succeeded in properly reproducing a load spinning of 3 to 90 sec only on , using Firefox 49.0 build3 (20160912134115). The load spinning was followed by a tab crash (https://crash-stats.mozilla.com/report/index/33815ddc-5c9c-49f2-be7e-d04b02160916). The issue took place i) in the following conditions: - e10s on - at least 1 hour of web browsing - more than 20 open tabs (see the list https://docs.google.com/document/d/1g6e5HSbQmUTtbmzxPo1CvheuzseU5zjRzZmEa0H_29c/edit?usp=sharing) - no add-ons installed, no additional configuration / changes made (see the about:support content https://docs.google.com/document/d/1iXyVZrtvWOuVtZxe0e4uKVXhMvzMlVYjyzwL8dK47QQ/edit?usp=sharing) ii) with the following STR: 1. Launch Firefox 2. Open as many tabs as possible, focusing on audio/video content 3. Browse each of the open tabs 4. Go to https://www.facebook.com/ and open a chat - spend some time sending and receiving messages - at a given moment, some short hangs can be noticed 5. Switch to other open tabs - short load spinning (1-2 sec) are encountered on some random tabs 6. Repeat steps 3, 4 and 5 - longer load spinning (>10 sec) occurs (initially on some random tabs, and then on all open tabs) - in this time, Firefox hangs for short periods Please let me know if there's something else I can help here with.
(In reply to Paul Oiegas [:pauloiegasSV] from comment #40) > Hi guys, > > Not sure if this is related but may be helpful. I observed that having e10s > enabled on latest Nightly (09.16.2016) while navigating to an nonexistent > page (eg: about:addon) in a "New Tab" page will display the loading spinner > for ever. Even after the browser tells you that the address isn't valid. > Disabling e10s makes this no longer reproducible. The "warning" yellow > favicon is displayed. This sounds like bug 1239886.
A reddit user with default settings on release is seeing this issue. https://www.reddit.com/r/firefox/comments/531lci/technical_issues/ They helpfully provided the text of their about:support which I'm attaching and indicated they could be contacted if more help was needed.
(In reply to Caspy7 from comment #44) > Created attachment 8792100 [details] > User submitted about:support > > A reddit user with default settings on release is seeing this issue. > https://www.reddit.com/r/firefox/comments/531lci/technical_issues/ > > They helpfully provided the text of their about:support which I'm attaching > and indicated they could be contacted if more help was needed. Thanks, Caspy7. What, above all, would be useful here is a profile. If you're in touch with the user, can you have them try to follow the steps at https://github.com/mikeconley/getting-profiles-from-users/blob/master/48.0.2.md to help us gather a profile?
In that post I linked, a Moz dev has actually already queried them for a profile (including your link). I will check later if that has been produced as I don't want to badger them.
http://www.motorsport.com/f1/news/ - one more site that causes spinner, when loading 5+ tabs of news.
More profiles from a user that contacted me by e-mail. https://cleopatra.io/#report=9203d4167984caaeab1a8c45cc1d321b1e91110b&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A1087216,%22end%22%3A1095534%7D%5D&selection=0,5471,8104,301,308,200,752,8156,8157,7199,7961,7962,7963,443,444,445,447,451,452,465,466,467,889,890,891,1202,1203,1204,1205,1206,1207,1208,1209,1210,1211,1209,1210,1211,1212,1213,1202,1203,1204,1205,2259,2260,2261,2262,2263,2264,1220,2966,2967,2968,2969,2030,7597,7599,8182,498,499 https://cleopatra.io/#report=264b4ae60ee4003bd9c4a94f6cf8ab9ed70e4782&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A3115395,%22end%22%3A3119944%7D%5D&selection=0,1,2,3,4,5,6443,6170,6171,14,15,6444,6445,12,13,14,15,6444,16,17,18,90,858,859,5532,5533,5534,5535,5536,5537,5538,5566,5567,5568 https://cleopatra.io/#report=d376c9232fc78e345de8b5e6c81d316c12bf881d&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A3761995,%22end%22%3A3774246%7D%5D&selection=0,5653,211,234,11720,11721,11722,11453,11454,11455,11456,11457,11458,11454,11455,11456,11457,11466,11467,11467,11833,2960,2961,607,608 https://cleopatra.io/#report=f5b707a60362dc8b92811fb93d795cae91a59375&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A4353925,%22end%22%3A4358798%7D%5D&selection=0,1,2,3,4,5,7100,6647,6648,14,15,7101,7102,12,13,14,15,7101,16,18,401,402,403,464,652,7103,7104,7105,7106,7107,37,38,39,40,41,42,43,122,1803,8531,8532,8533 https://cleopatra.io/#report=2c38548e2f921b8637d3ce309c41700875c35fb5&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A5425996,%22end%22%3A5432648%7D%5D&selection=0,1,2,3,4,5,5982,5983,5984,14,15,5985,5986,12,13,14,15,5985,16,17,373,374,375,7071,7072,7073,7074,7087,7075,7088,7105,7106,7107,3388 https://cleopatra.io/#report=f9f17bc8c6ba8567dc289e4730ddce84326a7461&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A1957138,%22end%22%3A1963434%7D%5D https://cleopatra.io/#report=cfe88aa3798b062d136b42903cfe48989a8a725a&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A3618869,%22end%22%3A3630441%7D%5D At least in this one, it looks like GC / CC account for a large number of the spinners. This is a user running with 8GB DDR3 (1600MHz), with apparently only 6 tabs open.
Clearing the needinfo that was a reminder for me. I've contacted the user previously referenced and awaiting a reply (to see if they're willing to do a performance profile).
I also want to point out that in bug 1303075, chutten looked for cases where we saw a long spinner (>5s) but where the content process _did not_ report a long GC or CC pause. Apparently, a third of the pings that saw >5s spinners from last Friday's release channel did not have long GC or CC. This evidence supports the hypothesis that while long GC or CC might account for a bunch of the problem here, that it's not the only problem to solve.
Looking carefully over this log, it's a little scary. Here's what I see: There's an incremental GC that takes a reasonable amount of time (70ms max pause). It collects only 5 of 74 zones. Then (after a bunch of OOM notifications) there's a non-incremental shrinking GC that collects all 74 zones. That GC takes forever--1.7 seconds. After it, there's another similar GC that takes 1.3 seconds. However, we only have 25 zones at that time. So the first non-incremental GC eliminated 49 zones. What I'm worried about is that maybe doing more zone GCs and fewer full GCs is causing us to miss zones for a long time and maybe OOM later. One thing that makes it seem less important is that we don't actually reclaim that much memory when collecting those 49 zones. So maybe the user would have OOMed anyway. But I wanted to call this out as something we should collect more data on. CCing some GC people so they see this.
The second log shows a 2.2 second non-incremental GC. But there's only one GC there, so it's hard to say much else.
(In reply to Bill McCloskey (:billm) from comment #29) > Another interesting thing about this profile is that the main process seems > to be spending all of its time in sync. This calls to mind bug 1199880, which was a weird sync GC issue that we never solved.
The max pause in the latest log is 101ms, which is not so bad.
Maybe also want to investigate if plugin container (flash) has any link. (I was wondering if I could trigger a different crash using kill -STOP to hang it; didn't succeed but ended up after a while with bad spinner and thought of this bug.)
Here's a video that a user posted of themselves experiencing the spinner: https://www.youtube.com/watch?v=YAjFP3Mt36I&feature=youtu.be They note that they're on older / weaker hardware. It looks like the spinner is triggered by doing a page load, and then switching tabs immediately. Worth noting is that in this video, the tab that loads the page starts out at about:newtab, which means we're doing a remoteness flip when the user starts the page load.
That sounds about right. Although "older and weaker", in my case includes an early 2013 MacBook Pro.
(In reply to Milan Sreckovic [:milan] from comment #64) > That sounds about right. Although "older and weaker", in my case includes > an early 2013 MacBook Pro. Hey milan, have you noticed any improvement here over the past few weeks on Nightly? billm landed bug 1279086 mid-Sept which should help paint when the content process is doing busy JS. As I recall from looking at the profile you sent me privately, busy JS was a dominant factor in your spinners.
Can't say nightly got better on 2010 MacBook Air; the 2013 MacBook Pro didn't get better (might have gotten worse) on Aurora; perhaps we should consider uplifting bug 1279086 to Aurora?
(In reply to Milan Sreckovic [:milan] from comment #66) > Can't say nightly got better on 2010 MacBook Air; the 2013 MacBook Pro > didn't get better (might have gotten worse) on Aurora; perhaps we should > consider uplifting bug 1279086 to Aurora? Interesting. That patch actually made it into central before the most recent uplift, so it _should_ be in Aurora. Would you mind gathering another profile and sending it to me? Perhaps busy JS isn't the only explanation here, _or_, there's a busy JS case we failed to consider.
Depends on: 1308039
Got their permission to share this.
AMD E-300 is an Atom-like processor. It really seems that the CPU power lack causes the spinner. It correlates with my own experience: - very-very often 6-y-old notebook (Pentium SU4100, 8 Gb RAM, SSD) - very often 6-y-old notebook (i5-450m, 8Gb RAM, SSD) notebook - pretty rare AMD Phenom II X4 955, 8Gb RAM, SSD - rare i5-6600, 16Gb RAM, SSD
¡Hola Mike! FWIW I have a question in the Spanish SuMo forum at https://support.mozilla.org/es/questions/1142079 that looks a lot like this bug. I don't know if you have a SuMo account, but just in case if you feel like brushing up your "español" =) Is there an effective "cure" for these that I can suggest so this bug doesn't cost us users while it gets fixed? ¡Gracias! Alex
(In reply to alex_mayorga from comment #70) > Is there an effective "cure" for these that I can suggest so this bug > doesn't cost us users while it gets fixed? This issue will not occur if e10s is disabled. These are the instructions I gave someone (on reddit) who reported back that it fixed their issue: > Go to about:config in your location bar. Search for browser.tabs.remote.autostart > There may be multiple results. Set them all to false and restart the browser. If someone has any corrections or enhancements on this, let me know. (I did ask them if they would do a performance profile first but they were not interested.)
(In reply to Caspy7 from comment #71) > (In reply to alex_mayorga from comment #70) > > > Is there an effective "cure" for these that I can suggest so this bug > > doesn't cost us users while it gets fixed? > > This issue will not occur if e10s is disabled. Insofar as the spinner is not made visible for !e10s. However, if the user is seeing the spinner, it is likely that in switching off e10s you are now replacing spinners with unresponsive browser chrome. This is a bigger issue that's somewhat less "visible" (because it's Firefox just "being slow") that e10s actually helps with. I don't think recommending users turn off e10s is going to help here.
FWIW, I've been getting the big spinner fairly frequently in FF50 recently. AFAICT, it occurs when: 1) My content process is using greater than 1.5GB of memory. Typically this is just because twitter, gmail, and irccloud have load a bunch of dynamic content. 2) Try to open a largish page like html.spec.whatwg.org or nsGlobalWindow.cpp in dxr. 3) Get the big spinner for 30+ seconds while the content process spins a CPU If I refresh twitter, gmail, and irccloud to release stuff and then minimize memory I can avoid this spinning. The weird thing I haven't really changed my work flow or set of sites at all. Yet I am seeing the big spinner a lot more than I have in the past.
Interesting. I'm experiencing quite the opposite of what :bkelly sees in comment 73. I used to experience the spinner *a lot*. Like, every 20 minutes. I usually have 10-15 tabs open and sure, irccloud, gmail, fastmail, google docs there. Over last week or two it became so infrequent that I don't know if I even still experience them (I can't remember if I saw one in the last 5 days).
I encourage the folks in this bug who are still experiencing this bug on Firefox 50 release to try Firefox 51 Beta (https://www.mozilla.org/en-US/firefox/beta/all/), as a number of performance improvements for tab switch have landed in that build.
To add to this, for those who are a bit wary about using Beta. It is very stable and you can use the exact same profile (bookmarks, history, etc) as you have now.
(In reply to Caspy7 from comment #76) > To add to this, for those who are a bit wary about using Beta. It is very > stable and you can use the exact same profile (bookmarks, history, etc) as > you have now. Please do not share profiles between beta and release. Use sync to share this information. Using the same profile may break when you open it in release depending on the changes in beta.
Thought it worthwhile to add I'm experiencing this bug to a vexing extent on 50, and not on "old or weak" hardware. Firefox is nowhere near the memory limit, and not using any more or less memory than it ever did.
Is this still an issue or we can close this one? It seems to me that you managed to fix all the tab switch spinner problems...
Whiteboard: e10s-multi:? → [e10s-multi:-]
Still experiencing this. Just opened 3 new tabs from my single Yahoo mail tab. I opened 1 new tab messenger (by Facebook), then 2 more facebook sites of videos posted by a friend of me. When switching between them, I just had another 3-5 second tab spinner. Just fyi ;)
(In reply to Daniel from comment #81) > Still experiencing this. Just opened 3 new tabs from my single Yahoo mail > tab. I opened 1 new tab messenger (by Facebook), then 2 more facebook sites > of videos posted by a friend of me. When switching between them, I just had > another 3-5 second tab spinner. Just fyi ;) Hi Daniel! If you're able to reproduce this reliably, would you be willing to capture and post a performance profile to this bug? See https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem for instructions.
Flags: needinfo?(mconley) → needinfo?(danielboontje)
I'd be interested to know if people seeing this still see it on 57. (Any patches to fix it would only land on that anyway.)
Well Caspy I'd gladly run this on my Beta but for some reason I can't manage to get 56 to use FF profile A (example name) and FF Beta use profile B... (they still interfere inside same profile)
(In reply to Daniel from comment #85) > Well Caspy I'd gladly run this on my Beta but for some reason I can't manage > to get 56 to use FF profile A (example name) and FF Beta use profile B... > (they still interfere inside same profile) You might find this documentation helpful: https://developer.mozilla.org/en-US/Firefox/Multiple_profiles
It say "Windows 8/8.1", is Windows 10 same there? (Can you add /Win10 there too please on that website?)
(In reply to Daniel from comment #87) > It say "Windows 8/8.1", is Windows 10 same there? (Can you add /Win10 there > too please on that website?) Probably - I'm afraid I don't have a Windows 10 machine with me right now to test. Try it and let me know if it works, and if it does, I'll update the documentation.
yes it ("firefox -ProfileManager") is working on my Win 10 flawless, Mike, but the thing is I can not tell my Firefox Beta installation to always start using my "beta" profile and also to tell my stable FF to always use my "stable" profile... both FF versions will always use same profile (both use the "default" profile OR both use my "beta" profile)... Or should I rename my Firefox Beta exe from "Firefox.exe" into sth. like "FirefoxBeta.exe" so the Beta will always use the "beta" profile? Or is this not possible currently?
Also have clicked around a lot amongst 10 tabs or so and no tab spinner occured in FF Beta yet! :) good sign!
(In reply to Daniel from comment #90) > yes it ("firefox -ProfileManager") is working on my Win 10 flawless, Mike, > but the thing is I can not tell my Firefox Beta installation to always start > using my "beta" profile and also to tell my stable FF to always use my > "stable" profile... both FF versions will always use same profile (both use > the "default" profile OR both use my "beta" profile)... I have this setup on my win10 machine. I create separate shortcuts on my desktop named "release" or "beta". I then edit the shortcut properties to pass the "-p <profilename>" flag to firefox.exe. If you click the shortcut the right profile should be opened automatically. Note, we have a separate effort in progress to provide separate profiles per channel by default.
(In reply to Daniel from comment #90) > yes it ("firefox -ProfileManager") is working on my Win 10 flawless, Mike, > but the thing is I can not tell my Firefox Beta installation to always start > using my "beta" profile and also to tell my stable FF to always use my > "stable" profile... both FF versions will always use same profile (both use > the "default" profile OR both use my "beta" profile)... I you use -p or -ProfileManager you choose the profile not FF. > > Or should I rename my Firefox Beta exe from "Firefox.exe" into sth. like > "FirefoxBeta.exe" so the Beta will always use the "beta" profile? Or is this > not possible currently? You should never do that. (In reply to Ben Kelly [:bkelly] from comment #92) > I then edit the shortcut properties to > pass the "-p <profilename>" flag to firefox.exe. If you click the shortcut > the right profile should be opened automatically. Note: You also need tho use quotes for the profile name if it has a space in it.
Thx but Ben's guide already helped me! Great!
I'm glad a new profile helped for you, Daniel. I'd like to understand why your old profile still behaves poorly though. Can you please post a performance profile from that user profile using the instructions at https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem ?
Ok haven't had any spinners yet in Dev edition now (ran the profile in Dev edition). Here the result of my random switching between tabs test: https://perfht.ml/2h48okN
Are people still seeing this? We've made a lot of inroads on improving tab switch times... if people are still often seeing things like this though, I'd still like to work with them. If I don't hear from anybody in the next few days, I'll close this bug out as INCOMPLETE.
(In reply to Mike Conley (:mconley) (:⚙️) from comment #97) > Are people still seeing this? We've made a lot of inroads on improving tab > switch times... if people are still often seeing things like this though, > I'd still like to work with them. > > If I don't hear from anybody in the next few days, I'll close this bug out > as INCOMPLETE. Still seeing it every day
Not often, but I still see the throbber.
Okay, for the people who are seeing it still, I'd love an up-to-date performance profile. The profiler has been enhanced with a bunch of new instrumentation that might shed more light on this. Instructions for submitting a profile are here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem
(In reply to Mike Conley (:mconley) (:⚙️) from comment #100) > Okay, for the people who are seeing it still, I'd love an up-to-date > performance profile. The profiler has been enhanced with a bunch of new > instrumentation that might shed more light on this. > > Instructions for submitting a profile are here: > https://developer.mozilla.org/en-US/docs/Mozilla/Performance/ > Reporting_a_Performance_Problem As ever before, Gecko Profiler will not respond either when the issue presents
(In reply to professorchaos66 from comment #101) > (In reply to Mike Conley (:mconley) (:⚙️) from comment #100) > > Okay, for the people who are seeing it still, I'd love an up-to-date > > performance profile. The profiler has been enhanced with a bunch of new > > instrumentation that might shed more light on this. > > > > Instructions for submitting a profile are here: > > https://developer.mozilla.org/en-US/docs/Mozilla/Performance/ > > Reporting_a_Performance_Problem > > As ever before, Gecko Profiler will not respond either when the issue > presents If you use the keyboard shortcut to dump the profile (Ctrl-Shift-2), does the profile _eventually_ display?
Ok I just had it again, but for only 50-500 ms I'd say: Firefox 62.0.3, installed on my slow C: HDD drive, but the FF profile I'm using is on a fast PCI-e SSD (K:). I was doing something (strong C: i/o operations from another program) while FF was in background, "inactive". I Alt-tab back into FF (instantly, fine), then click another tab, then spinner came. My guess: FF is waiting for some I/O operation on the Firefox installation drive (slow C: HDD for me), because my active FF profile is on the superfast PCIe SSD K: .
(In reply to Mike Conley (:mconley) (:⚙️) from comment #102) > (In reply to professorchaos66 from comment #101) > > (In reply to Mike Conley (:mconley) (:⚙️) from comment #100) > > > Okay, for the people who are seeing it still, I'd love an up-to-date > > > performance profile. The profiler has been enhanced with a bunch of new > > > instrumentation that might shed more light on this. > > > > > > Instructions for submitting a profile are here: > > > https://developer.mozilla.org/en-US/docs/Mozilla/Performance/ > > > Reporting_a_Performance_Problem > > > > As ever before, Gecko Profiler will not respond either when the issue > > presents > > If you use the keyboard shortcut to dump the profile (Ctrl-Shift-2), does > the profile _eventually_ display? no
So we can't even get the issue logged in a profiler currently?
You need to log in before you can comment on or make changes to this bug.