1466069 - tab scroll stalls/sticks when tabs are still loading/rendering, but not when fully rendered/displayed

Status: UNCONFIRMED

(Firefox :: Tabbed Browser, defect, P5)

Description

[ayden]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 Safari/605.1.15

Steps to reproduce:

In nightly I have 117 tabs set to load on opening.
When I scroll right, or left two things are observed.



Actual results:

1) I can get to the end of the 117 tabs very quickly/easily, it looks like it jumps over/doesnt show a large number of tabs in the middle. This behaviour doesnt happen in FF60 main, it can take a lot of clicking to get to the end of 117 tabs and while it moves one at a time or can jump several tabs at once (unsure why it randomly jumps a few at once, may be click speed causes that) it definitely doesnt have the big jump/cant see the majority of tabs in the middle sections like what I am seeing in nightly.

2) when clicking the scroll tab right or left, one click at a time, the tab can become stuck for one or two clicks and doesnt move the tabs along. then starts moving again or does a random jump few tabs.. I havent tested this in FF60 main.


Expected results:

as above

Comment 1

[Daniel Bodea [:danibodea]]

Hello ayden,

Could you try to disable the tab warming preference and then try to reproduce the issue again?

To do this, go a new tab, write "about"config" in the adress bar and press Enter, search for the "browser.tabs.remote.warmup.enabled" preferencece using the search field and double-click it to mark it as "false" and retry reproducing the original issue again.

Thank you for your contribution!

Comment 2

[ayden]

Attachment: browser.tabs.remote.warmup.disabled profile.sps.json.gz

Still hung. seemed much longer than the usual 10 second.
profile attached.

Comment 3

[ayden]

Attachment: browser.tabs.remote.warmup.disabled.png

Just png to show I changed it to disabled.

Comment 4

[ayden]

Hi There,
Made changes, still hung. much longer than usual.
odd: The profiler also wouldnt display initially, i.e. I had to mouse over the content to make it show.nite.

I attached both the profile and a png to show the config I changed.

Started profile.
closed first 12 tabs
13th tab was ignite page
closed tab, tab dissappeared but the 14th tab hung for much longer than usual i.e. 14th tab was wanting to slide left to fill the space of the 13th tab.
I then closed a few more tabs after it started working again to demo that it is just the ignite tab playing up.


I repeated test.
ignite hung again. for est. 1 minute. so much longer hanging with the browser.tabs.remote.warmup disabled.
I set the profiler to the finest granularity as well, .01ms. unfortunately while testing after about the third closed tab the browser minimised (happens when tabs cannot move left/keep up with closing them too quickly) so will see a gap there to open back up again. when looking at the output there was a lof of timeouts with the profiler so unsure if thats why there is a bunch of nothing at the beginning or not...
I will try to attach this profile but may have file size issues. Update: Wont let me attach, file @ 37Mb

Let me know if you want me to do any other tests etc.

Comment 5

[ayden]

Test 3.

Closed 11 tabs.
Started Profiler
Closed 12th tab
Closed 13th Tab - ignite. Hung for a longer time than usual.
Closed 14th tab etc
Stopped profiler.

Browser wont allow me to upload. connection reset error. so cannot upload either fine grained profiles I captured.

Comment 6

[ayden]

uploaded test 2 an test 3 fine grain profile to drop box if you want them.

https://www.dropbox.com/l/scl/AACIywyxgl_uCpUj5u4Iq3bW64njr9JlMiI

Comment 7

[Alex Thayer [:alexical] (she/her)]

ayden if you have the time, would you mind finding a regression window with mozregression:

https://mozilla.github.io/mozregression/install.html

Comment 8

[ayden]

I can, but need a few pointers as im not a coder, and im using OSX which means command line.
Looking at url you gave, assume install goes ok..

First problem. Currently I am running nightly (FF62 I believe it is referred to as) as well as main public branch (FF60 I believe it is referred to as). I don't have the issue on FF60. So to clarify, are you wanting me to confirm where between 60 and 62 it became a bug? or you just want me to confirm it was a bug somewhere in nightly (62) only..? I ask because I haven't seen/used FF61 so if it is just nightly FF62 range only, I prob really should eliminate the regression in FF61 first..
Note: If someone can point me to 61 branch I can try that to at least run it local and see if issue is there or not. I can at least halve the range straight away.

So I assume when I enter in the nightly range I need to put in 60 through to 62? i.e. it can/will download/install as far back as 60, and im not just limited to 62 branch only?



Also,

"This will guide you through a bisection, automatically downloading and opening nightly builds from various dates (on new, clean profiles) and asking you whether the bug exists in them. After doing this a few times you’ll get the regression range, something like this:"

The above implies I have no control over the selection process.. i'd imagine a lot of builds between 60 to 62 or even 61 to 62 etc. Can I select which builds between 60 and 62 I want it to install/run?? I.e. I will pick the mid point each time and halve it and so forth. I don't want to install each nightly build between 60 and 62 thats all as each open takles about 7 minutes approximate.. so hoping I can pick..?
I guess the work around would be to restart mozregression and specify a new range each time and just run once and see if still there, if so, close, re-open and pick a new range again that way.

I will do this tonight, and see how far I get with install and using it. but if someone could reply to the above that would be appreciated as well to save me a chunk of time with FF60 and 61 testing etc.

Comment 9

[Alex Thayer [:alexical] (she/her)]

> I.e. I will pick the mid point each time and halve it and so forth.

I think a lot of your questions here are answered by the fact that this (picking the mid point each time etc. etc.) is exactly what mozregression does for you.

I would use March 12th 2018 as the start of the range, and today as the end of the range. It should only take ~8 different builds to find the build ID from that range, as far as I can math out off the cuff?

Let me know if this doesn't answer your questions though.

Comment 10

[ayden]

Apologies, I didnt correctly read prev comms from you guys earlier and mixed this up with the other defect I raised about hung tabs.
Tonight with luck I will perform both requests above and come back.

Comment 11

[ayden]

Attachment: Firefox 60.02 profile at 0.2ms - 3 tabs stick.gz

Had to change profile to 0.2ms to keep file size down under 10mb.
This is profile from FF 60.02 (was there is 60.01 as well as nightly too)

Comment 12

[ayden]

Hi, So 1 is a bug, the other is user error.

User Error.
Clicking tab scroll twice close together moves across the entire tabs on screen. I have aprox 15-16 tabs shown, so 2 quick taps makes 17-34 show etc.
Since I have about 96 odd tabs.. When i clicked fast 6-10 times in a row it jumped to end pretty quickly.
Seems this is standard behaviour in FF 60, etc.
My bad on that one..
But it does get a bit random towards the end of the tabs, both diretions, as sometimes it does a big jump then moves one by one as if im taping slow but dont think i am.. prob just my dual core under load im guessing.


Tabs Sticking issue:
RCA:
This happens in FF 60.01, the new 60.02 as well as nightly.
Only seems to happen when loading tab.. (I havent tried replicating numerous times when all tabs are loaded, just once or twice and couldnt rep[roduce when tabs were already loaded). So me loading 96 odd tabs prob triggered this.

I get about 8 to 10 tabs will stick when moving the scroll one tab at a time, doesnt matter which direction. Most time it sticks once, but occassionally it will stick twice i.e. 3 taps.
I have attached profile at 0.2 ms of 3 tabs sticking over about 1/3rd to half of my tabs. Had to stop otherwise would exceed 10mb and then couldnt upload.

I tried running quicktime player screen recorder, also while running profiler and independantly, but jumps/jitter and cant see the tab stick, or you record 1 minute but recorder randomly for 7 or 15 seconds and cant see anything so gave up on that.

Didnt run mozregression since it was in main branch of FF60


Profiler Defect:
I also noticed profiler for a few second will say it is recording, when I had freshly opened the window, and its trying to open 96 odd tabs.
Usually I can click on profiler once, may be two times max and it will say it is recording.. after 10 seconds or so it will show the start button.

Comment 13

[ayden]

sorry, also ignore comment 4 and 5 too, relates to other defect.. but it wont allow me to edit or remove them.
But I have RCA'd that defect to be the pdf not ignite website, go there for more detail.

Comment 14

[ayden]

Also, by sticking, what I mean is..
When normally scrolling to the right, the tabs move left.. except when they stick. Then they appear to actually move to the right (not left) a fraction, and then bounce back to their previous position.

Comment 15

[Daniel Bodea [:danibodea]]

Hi Ayden,

I just want to add here that you may have misunderstood the functionality of scrolling through tabs. It appears that the functionality is as follows:
Let's suppose you have 100 tabs open.
1. If you have the very first tab selected and you click the right arrow once, it will put the second tab in first view.
2. If you have the very first tab selected and you click the right arrow twice, it will put the 23rd tab in first view. (So it basically jumps through the first 22 tabs)
3. If you have the very first tab selected, and you click the right arrow three times, it will scroll to the very end of the tab list. (So it jumps through all of them to the very end of the list of tabs)

I am guessing that what causes your confusion is basically performance issues while all the tabs are slowly loading in the background. High volumes of loading makes video rendering stutter and 

On the other hand, it may be an issue after all. If you found an older version of nightly where your issue DOES NOT reproduce, you can perform a mozregression to determine the changelog/bugfix that introduced the issue (and I will try to guide you through the process with clear steps:

1. Firstly, do you have know a version of nightly on which the issue does not reproduce?
You can find older versions here (search them by date and keep the date for later use to use in command):
http://archive.mozilla.org/pub/firefox/nightly/
2. If you found a version on which the issue does not reproduce, you will now run a mozregression test (considering you prefer command line, I will try to accommodate you with this choice:
   a. Installing python or "pip" to be able to use the tool (https://mozilla.github.io/mozregression/install.html):
      - Run command : "sudo easy_install pip" and make sure it gets installed;
   b. Running mozregression with your current profile that has many tabs opened and with "good" and "bad" dates (https://mozilla.github.io/mozregression/documentation/usage.html):
      - You need the disk location of your current profile; go in the browser and write "about:support" in a tab; Observe the Profile Folder section and copy the link displayed to use in the command.
      - Run command: "mozregression --profile="*the link to you current profile:*" --good 2014-12-25 --bad 2015-01-07
      - Make sure that the path to profile, good build date and bad build date are correctly written.
      - The tool will now open different builds with your current profile (many tabs opened and loading in the background), so you can check whether the issue occurs;
      - What you need to do is answer in the command line whether the build was good or bad, until the bisection is over.
   c. After the bisection has finished, a link to the changelog that caused the issue will be displayed in the command line. If we're lucky, you will provide one.

Note: I would have ran the mozregression test myself, but I cannot reproduce this issue myself; You have to do it.

Thank you for your contribution!

Comment 16

[ayden]

Hi,
As mentioned above, yes realise tab jumping was due to my own lack of knowledge of how it works. So ignore that one.

However the tab sticking can be seen in ff60 as well as nightly as i described above.

Thanks,
Ayden

Comment 17

[ayden]

Hi Bodea,
Also, just as a fyi. My macos wont work with mozregression instructions. My os doesnt have supported tls.. so had to google and follow someone elses instructions to maker it work like map path, --user, pip not pip2 etc. The moz site for macos isnt that helpful or correct tbh :)