If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Facebook home navigation start: navigate to home page after viewing a user profile




4 months ago
23 days ago


(Reporter: Alin Rus, Unassigned)


(Blocks: 2 bugs)

55 Branch
Windows 10
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [QRC][QRC_Analyzed], URL)



4 months ago
Name: Firefox
Version: 55.0a1
Windows 10 64 bit
buildID: 20170508030204

Steps to reproduce:
1. Launch browser.
2. Fill Facebook.com in Navigation Start, then press enter.
3. Login with credentials.
4. Tap on a user photo profile from first post you have displayed.
5. Record with Gecko Profile:
   Click the facebook home button.
6. Share the profile.

Gecko profile:


Comment 1

4 months ago
Here's the Gecko profile obtained on Acer Aspire e15.
Version: 55.0a1
Windows 10 64 bit
buildID: 20170518030213
Assignee: nihsanullah → nobody
Blocks: 1370336
Summary: STR Facebook navigate to home page after viewing a user profile → Facebook home navigation start: navigate to home page after viewing a user profile
Whiteboard: [QRC][QRC_NeedAnalysis]

Comment 2

3 months ago
Bas, please take a look on the profile in comment 1.
Assignee: nobody → bas
There does not appear to be any significant cost in this profile that is related to graphics.

There is a little bit of layout. But this is not unexpectedly high and in the portions of layout that we're already working on improving performance in.

By far the largest cost appears to be inside restyle and reflow for the long duration frames, with for a 'long' frame (in this case 100ms), 32% being in ProcessPendingRestyles and 17% being in ProcessRestyleCommands, I don't know much about that and I doubt there is anything in this bug I can add.

ni?jean to make sure this doesn't get lost.
Assignee: bas → nobody
Flags: needinfo?(jgong)
Fwiw, I should probably note on the 'reasonable' frames that are still longer than I would like (i.e. 18ms-ish), layout (DisplayListBuilding+FrameLayerBuilding) is a considerable portion of the time (often well over 50% of the frame). As stated in my previous comment though, this is something we're aware of and that is being worked on.

Comment 5

3 months ago
Mats, could you help to follow Bas's investigation? Thanks.
Assignee: nobody → mats
Flags: needinfo?(jgong) → needinfo?(mats)

Comment 6

3 months ago
I won't get to this before my vacation, sorry.
BTW, the performance profiles here are rather old, so I don't think they
accurately reflect current Nightly.
Flags: needinfo?(mats)
Alin, could you provide new profile per Mats' request in comment 6? Thanks.
Flags: needinfo?(arus)

Comment 8

a month ago
sure, here is the new profile obtained on latest build: 20170808114032

profile link: 

Acer Aspire e15
Windows 10 64 bit


a month ago
Flags: needinfo?(mats)


a month ago
Flags: needinfo?(arus)
Thanks for the new perf profile.  It looks mostly dominated by running JS.
I don't see anything related to Layout that looks particularly bad, so it's
probably better if someone else takes a look (if the use case is still
perceived as slow compared to other UAs).
Assignee: mats → nobody
Flags: needinfo?(mats)
Worksforme per comment 4 and comment 9.
Last Resolved: 23 days ago
Resolution: --- → WORKSFORME
Whiteboard: [QRC][QRC_NeedAnalysis] → [QRC][QRC_Analyzed]
You need to log in before you can comment on or make changes to this bug.