1417210 - new tab animation is janky when open about:preferences from hamburger menu

Status: RESOLVED DUPLICATE of bug 1425398

(Firefox :: Settings UI, defect, P3)

Description

[Ben Kelly [:bkelly, not reviewing]]

I'm dogfooding FF57 a bit today.  I noticed when click "options" in the hamburger menu that the new tab animation is janky opening about:preferences.  Here is a profile:

https://perfht.ml/2juI7go

Seems like there may be a few issues:

1. There is a long rasterize.
2. The XUL document loading seems to be taking a long time.
3. It seems like another page started to load and was canceled before loading about:preferences.

Mike, does any of this look familiar to you?

Comment 1

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

This sounds a bit like bug 1383531, which was closed WORKSFORME.

Hey timdream, anything actionable in here?

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I couldn't think of things actionable from the profile. The page takes 290ms from oncommand to paint, not fast, but around the worse case when I WFM bug 1383531.

I don't know how to address 1.
For 2, the General pane gets a lot longer with the new design. Unless we want to do some kind of lazily load of the DOM in XUL (which complicates bug 1407568 greatly), it's not actionable.
I couldn't find (3) in the profile. I don't think we load about:newtab when a tab is opened for Preferences (unless I was wrong with that).

Another possibility would be moving about:preferences to content process. I don't know if that's feasible with XUL.

Comment 3

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

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #2)
> Another possibility would be moving about:preferences to content process. I
> don't know if that's feasible with XUL.

I do know that there's an effort in bug 1379338 to remove XBL from Preferences, but it'd be a longer (but probably well-worth it!) project to migrate it to HTML.

Getting it to run in the content process will be tricky from a security perspective - by necessity, we'd be opening up some kind of IPC API for manipulating all of the prefs in about:preferences, and that could be abused by a compromised content process.

We could potential preload about:preferences like we do with about:newtab when the user is idle, but I'm not sure it's worth it to be honest.

A hackier solution might be to special-case the about:preferences tab, and just not animate it when it's opening.

Honestly, the sanest approach is probably to just try to optimize about:preferences first load. Here are some things I've found:

Synchronous layout flush: https://perf-html.io/public/d84e1a38c37cc034479e701875f7be9a3eb7d444/calltree/?hiddenThreads=&range=2.9649_3.5354&thread=0&threadOrder=0-2-3-4-5-6-7-1-8&transforms=f-combined-0stuvx0x11x2x3x4x5x6x7x8A7xaxbxHmxHnxJaxK3xMpxMqxz0_hAqArWjxMrEeEfVdyQ96g2xMsxT9&v=2

Synchronous style flush: https://perf-html.io/public/d84e1a38c37cc034479e701875f7be9a3eb7d444/calltree/?hiddenThreads=&range=2.9649_3.5354&thread=0&threadOrder=0-2-3-4-5-6-7-1-8&transforms=f-combined-0stuvx0x11x2x3x4x5x6x7x8A7xaxbxHmxHnxJaxK3xMpxMqxz0_hAqArWjxMrEeEfVdyQ96g2xMs&v=2

If we can't simplify what's being painted, perhaps WebRender will help with the slow rasterization.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

The sync reflow in init_dynamic_padding was addressed in bug 1389550.

For the scrollTop, it was mentioned in bug 1389550. I am not sure if it has been addressed in Fx58 already. If not we should address it too.

Ricky, could you follow this up and maybe verify our status in Fx58/59? Thanks.

Comment 5

[Ricky Chien [:rickychien] (inactive)]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #4)
> For the scrollTop, it was mentioned in bug 1389550. I am not sure if it has
> been addressed in Fx58 already. If not we should address it too.

scrollTop [1] hasn't been addressed in Fx58 yet, which is using for ensuring content scroll at the top after preferences reload. But it's definitely unnecessary to be invoked when first time preferences page open.

One thing at least we can try is that avoid calling mainContent.scrollTop = 0 when it's the first time preferences page being opened. I'm not sure that changes would cause conflicts with preferences-spotlight in bug 1407568.

Evan, we need to be aware of using any sync reflow APIs in preferences. Not sure whether bug 1407568 has tackled this already.

[1] https://searchfox.org/mozilla-central/source/browser/components/preferences/in-content/preferences.js#180

Comment 6

[Evan Tseng [:evanxd]]

(In reply to Ricky Chien [:rickychien] from comment #5)
> (In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment
> #4)
> One thing at least we can try is that avoid calling mainContent.scrollTop =
> 0 when it's the first time preferences page being opened. I'm not sure that
> changes would cause conflicts with preferences-spotlight in bug 1407568.
I think it won't cause conflicts if we want to avoid calling `mainContent.scrollTop = 0`. (opening about:preferences from hamburger menu won't trigger preferences-spotlight.)

> Evan, we need to be aware of using any sync reflow APIs in preferences. Not
> sure whether bug 1407568 has tackled this already.
Yes, I will take care of this issue in the bug.

> [1]
> https://searchfox.org/mozilla-central/source/browser/components/preferences/
> in-content/preferences.js#180

Comment 7

[Chris Peterson [:cpeterson]]

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #3)
> Synchronous style flush:
> https://perf-html.io/public/d84e1a38c37cc034479e701875f7be9a3eb7d444/
> calltree/?hiddenThreads=&range=2.9649_3.5354&thread=0&threadOrder=0-2-3-4-5-
> 6-7-1-8&transforms=f-combined-
> 0stuvx0x11x2x3x4x5x6x7x8A7xaxbxHmxHnxJaxK3xMpxMqxz0_hAqArWjxMrEeEfVdyQ96g2xMs
> &v=2

Does enabling Stylo for chrome ("layout.css.servo.chrome.enabled" pref) make any difference in the style time? Regardless, we should try to avoid style flushes. :)

Comment 8

[Florian Quèze [:florian]]

Several different issues have been discussed in this bug, which makes it hard to follow. I'm duping this to the newer meta bug I filed to cover the preferences being slow to open: bug 1425398.