1400739 - Bad close animation on Linux (empty space upon tab close, slow shift from next tab) with Violentmonkey installed

Status: RESOLVED WORKSFORME

(WebExtensions :: General, defect, P5)

Description

[Asif Youssuff]

Attachment: slow-bad animation on tab close.mp4

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170917100334

Steps to reproduce:

1. Open three tabs
2. Close second tab in stack


Actual results:

The animation when closing the tab is slow and looks odd. The animation removes the tab immediately, but keeps a blank space in the tabbar for a fairly long time. 


Expected results:

Tab closes quickly, but the amount time an empty space exists should be minimized. Chrome seems to solve this by animating the tab close instead of making the tab disappear immediately (and leaving an empty space).

Also, Chrome begins to animate the tab move (taking the place of the closing tab) immediately instead of waiting for the closed tab to disappear. 

See attached video for a sample of how it looks on my machine.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Thanks for the report, Asif.

Are you able to reproduce this behaviour with your add-ons disabled? (Help > Restart with Add-ons Disabled).

Comment 2

[Asif Youssuff]

Mike, thanks for looking into this. 

It's a lot better (likely the designed behavior) when I restart with add-ons disabled. 

I had removed some add-ons that I suspected were causing performance issues after I opened this bug, but I still had Violentmonkey installed; disabling this add-on made the issue a lot more like the disabled add-on state. 

I can reproduce the jankiness in a fresh profile (copied my sessionrestore file to a new profile and did a refresh, then installed Violentmonkey) when Violentmonkey is installed.

I hope it's not *too* acceptable that Violentmonkey can cause this issue. :)

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(In reply to Asif Youssuff from comment #2)
> I hope it's not *too* acceptable that Violentmonkey can cause this issue. :)

Thanks for narrowing down the issue to Violentmonkey! Do you need to have any scripts running in Violentmonkey to reproduce the behaviour, or does just having it running cause the issue?

Would you be able to gather a performance profile when reproducing the slow behaviour using these steps?: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Tentatively moving this over to Tech Evangelism :: Add-ons, though this might end up being a WebExtension API bug. We'll see.

Comment 4

[Asif Youssuff]

>Do you need to have any scripts running in Violentmonkey to reproduce the behaviour, or does just having it running cause the issue?

No, I just installed Violentmonkey in the fresh profile and was able to reproduce. I'll follow up with a profile once I get home later today.

Comment 5

[Asif Youssuff]

Mike,

Hope this profile can be understood easily, I'm happy to take a new profile as needed. 

This is what I did:

1. Took my existing profile and copied it to a new one
2. Opened the new profile and ensured that each window was opened to about:newtab
3. refreshed the profile, restored all windows
4. installed Violentmonkey and the Gecko Profiler
5. Restored a tab in the middle of one of the windows which had a large tab stack
6. Started the profile
7. Proceeded to close a few windows, waiting until each page loaded completely before closing a new one. I *think* I closed 4 or 5 tabs in total

Hope this helps!

Comment 6

[Mike Conley (:mconley) (:⚙️)]

(In reply to Asif Youssuff from comment #5)

Hey Asif, I think you forgot to provide the perf-html.io profile link. Can you please attach it?

Comment 7

[Asif Youssuff]

Mike,

That's embarrassing. Here you go: https://perfht.ml/2hdv9m0

Thanks!

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Hm. I'm seeing quite a few Activity Stream-related samples in the main thread in the parent process. If you set browser.newtabpage.activity-stream.enabled to false and restart your computer, do you find that performance improves?

Comment 9

[Asif Youssuff]

It is better, but not really "perfect" -- still seeing some jank, but it's not as bad as with browser.newtabpage.activity-stream.enabled set to true. 

Fresh profile with that setting and Violentmonkey enabled: https://perfht.ml/2hmIR2d

Comment 10

[Florian Quèze [:florian]]

Hi Asif,

Do you still see this in a current Nightly? If so, could you please attach a new profile, and set the thread filter of the Gecko Profiler back to the original "GeckoMain,Compositor" value? (the two profiles you attached contain all threads, and the memory buffer allocated to the profiler wasn't big enough, causing information to be lost)

Comment 11

[Asif Youssuff]

I retried the STR in Comment 5 in the latest Nightly, and I can't tell the difference between when Violentmonkey is enabled vs. disabled anymore. 

I think we can consider this fixed. Is it worth searching for the fix via mozregression? I am happy to try.

Comment 12

[Florian Quèze [:florian]]

(In reply to Asif Youssuff from comment #11)

> I think we can consider this fixed. Is it worth searching for the fix via
> mozregression? I am happy to try.

Not really useful to find the exact fix, as long as we know things are now working as expected :-). Thanks for replying!