Closed
Bug 1363706
Opened 7 years ago
Closed 6 years ago
Facebook home navigation start: navigate to home page after viewing a user profile
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: arus, Unassigned)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [QRC][QRC_Analyzed])
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: https://perfht.ml/2q5x8cb Notes: https://docs.google.com/spreadsheets/d/1Kxn850VasyaG_WfRg3pMInW0hbIT8LP7pRPBYTIpdbM/edit?pli=1#gid=679575660
https://perfht.ml/2ryTa7I Here's the Gecko profile obtained on Acer Aspire e15. Version: 55.0a1 Windows 10 64 bit buildID: 20170518030213
Updated•6 years ago
|
Assignee: nihsanullah → nobody
Blocks: QRC_FX57
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 3•6 years ago
|
||
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)
Comment 4•6 years ago
|
||
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•6 years ago
|
||
Mats, could you help to follow Bas's investigation? Thanks.
Assignee: nobody → mats
Flags: needinfo?(jgong) → needinfo?(mats)
Comment 6•6 years 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)
Comment 7•6 years ago
|
||
Alin, could you provide new profile per Mats' request in comment 6? Thanks.
Flags: needinfo?(arus)
sure, here is the new profile obtained on latest build: 20170808114032 profile link: https://perfht.ml/2hJbyKa Acer Aspire e15 Windows 10 64 bit
Updated•6 years ago
|
Flags: needinfo?(mats)
Comment 9•6 years ago
|
||
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)
Comment 10•6 years ago
|
||
Worksforme per comment 4 and comment 9.
Status: NEW → RESOLVED
Closed: 6 years 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.
Description
•