[remote-dbg-next] old performance panel charts are not displayed in about:devtools-toolbox

VERIFIED FIXED in Firefox 68

Status

defect
P1
normal
VERIFIED FIXED
4 months ago
2 months ago

People

(Reporter: hani.yacoub, Assigned: jdescottes)

Tracking

(Blocks 2 bugs)

67 Branch
Firefox 68
Dependency tree / graph

Firefox Tracking Flags

(firefox65 unaffected, firefox66 unaffected, firefox67 wontfix, firefox68 verified)

Details

(Whiteboard: [remote-debugging-reserve])

Attachments

(5 attachments)

Reporter

Description

4 months ago
Posted image performance.png

[Affected versions]:
Nightly 67.0a1

[Affected platforms]:
Platforms: Windows 10 x 64, Mac OS X 10.14, and Ubuntu 16.04 x64.

[Preconditions]:
In about:config set:

  • devtools.aboutdebugging.network -> true
  • devtools.aboutdebugging.new-enabled -> true

[Steps to reproduce]:

  1. Launch Firefox and go to "about:debugging" after you set all the preconditions or go to "about:debugging-new" without the need to set preconditions.
  2. Click on "This Firefox" tab.
    From "Tabs" section, click on "Inspect" button for any of the open tabs.
  3. Click on "Performance" tab.
  4. Click on "Start Recording Performance".

[ Expected result]:
Performance recording visual progress should be displayed.

[Actual result]:
Performance recording visual progress isn't displayed.

[Note]:
It's not reproducible when the toolbox is displayed in a new tab.

Priority: -- → P3
Assignee

Comment 1

3 months ago

It seems all the charts of the Performance tab are not working when displayed in about:devtools-toolbox. Even after you finish recording the profile, there is just a blank area on top of the table.

Assignee

Updated

3 months ago
Summary: Performance recording visual progress isn't displayed → [remote-dbg-next] old performance panel charts are not displayed in about:devtools-toolbox

Comment 3

3 months ago

Tested the part of "Performance" on Mac OS X - In about:devtools-toolbox ->after a performance test is performed, on the 3rd option, "JS Flame Chart" - no info's are displayed. See the latest screenshot attached

Assignee

Updated

3 months ago
Blocks: 1539979
Assignee

Comment 4

3 months ago

This is blocking ongoing work for fission, taking the bug.

Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
Priority: P3 → P1
Whiteboard: [remote-debugging-reserve]
Assignee

Comment 5

3 months ago

Depends on D26900
Fixes the blank chart and load issues for the old perf panel in about:devtools-toolbox (or type=content)

Assignee

Updated

3 months ago
Depends on: 1538731
Assignee

Comment 6

3 months ago

Depends on D26919

This test also needs the fixes from Bug 1538731

Comment 8

3 months ago
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f1615630af59
Use DOMHelpers to wait for iframe load in widgets/Graphs.js;r=ochameau
https://hg.mozilla.org/integration/autoland/rev/f7050f15a28d
Add test for perfomance panel when devtools are in frame type=content r=ochameau
Assignee

Comment 10

2 months ago

Same comment as on the other bug, this test is already intermittent.

Flags: needinfo?(jdescottes)
Assignee

Comment 12

2 months ago

Added some logs on try, it seems that during this test an extra rendering of the WaterfallView is triggered by a "resize" event fired by its MarkerDetails widget. MarkerDetails can fire resize for 3 reasons:

  • click on splitter
  • calling the hidden setter
  • window resize

This "resize" event seems to be fired when the JsFlameGraph is rendered. This FlameGraph relies on the Graphs.js file modified in my patch. A new try push is ongoing to determine which one of them is responsible for the extra event. Possible explanation would be that using DOMHelpers to load the FlameGraph is slightly slower than the previous approach and might trigger a window resize.

If that's the case, I think it would be valid valid to accept both 4 or 3 renderings of WaterfallView.

new try at https://treeherder.mozilla.org/#/jobs?repo=try&revision=b0de1a68231bab9e26fe5b772c426cb82a919520

Assignee

Comment 13

2 months ago

Try confirms that a window resize is responsible for the extra rendering here.

Assignee

Comment 14

2 months ago

Depends on D26920

See Bug 1532993#c12 for the analysis. The extra rendering is due to a window resize that
seems to always happen on ASAN but not on other platforms.

Comment 15

2 months ago
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7bd34721fb35
Use DOMHelpers to wait for iframe load in widgets/Graphs.js;r=ochameau
https://hg.mozilla.org/integration/autoland/rev/5e86cf625b54
Add test for perfomance panel when devtools are in frame type=content r=ochameau
https://hg.mozilla.org/integration/autoland/rev/fc8e9758009c
Accept extra renders of WaterfallView in old perf panel test;r=julienw

Comment 17

2 months ago
bugherder
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

Julian, this is a P1 and the patch doesn't look big, do you want to request uplift to beta or do you think it is better to let it ride the trains? Thanks

Flags: needinfo?(jdescottes)
Assignee

Comment 19

2 months ago

It can ride the trains, it is mostly relevant for the new remote debugging which will be enabled only in 68. Thanks!

Flags: needinfo?(jdescottes)

Thanks, adjusting flags.

Regressions: 1544040
Reporter

Comment 21

2 months ago

Verified as fixed on Firefox Nightly 68.0a1 (2019-04-17) on Windows 10 x 64, Mac OS X 10.14 and on Ubuntu 16.04 x64.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.