1111020 - UP/DOWN keys don't work to navigate the call tree in the new performance tool

Status: RESOLVED FIXED

(DevTools :: Performance Tools (Profiler/Timeline), defect)

Comment 1

[Victor Porof [:vporof][:vp]]

This is more annoying that beetlejuice, damn it.

Comment 2

[Jordan Santell [:jsantell] [@jsantell]]

Attachment: 1111020-fix-key-events.patch

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3c461e087c02

Comment 3

[Victor Porof [:vporof][:vp]]

Comment on attachment 8560692 [details] [diff] [review]
1111020-fix-key-events.patch

Review of attachment 8560692 [details] [diff] [review]:
-----------------------------------------------------------------

Wow

::: browser/devtools/performance/test/browser_perf-events-calltree.js
@@ +34,5 @@
> +  fireKey("VK_DOWN");
> +
> +  JsCallTreeView.off("focus", focusEvent);
> +
> +  ok(focus > 1, "several focus events are fired for the js calltree.");

Shouldn't we check for an exact number here?

@@ +52,5 @@
> +  fireKey("VK_UP");
> +  fireKey("VK_DOWN");
> +
> +  MemoryCallTreeView.off("focus", focusEvent);
> +  ok(focus > 1, "several focus events are fired for the memory calltree.");

Ditto.

::: browser/devtools/shared/widgets/AbstractTreeItem.jsm
@@ +447,5 @@
>  
>      switch (e.keyCode) {
>        case e.DOM_VK_UP:
>          this._focusPrevNode();
> +        e.preventDefault();

Huh? Why?

Comment 4

[Jordan Santell [:jsantell] [@jsantell]]

Comment on attachment 8560692 [details] [diff] [review]
1111020-fix-key-events.patch

Review of attachment 8560692 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/devtools/performance/test/browser_perf-events-calltree.js
@@ +34,5 @@
> +  fireKey("VK_DOWN");
> +
> +  JsCallTreeView.off("focus", focusEvent);
> +
> +  ok(focus > 1, "several focus events are fired for the js calltree.");

Will we always have sufficient enough call tree items? That's my concern as the stack generated isn't deterministic, I believe

::: browser/devtools/shared/widgets/AbstractTreeItem.jsm
@@ +447,5 @@
>  
>      switch (e.keyCode) {
>        case e.DOM_VK_UP:
>          this._focusPrevNode();
> +        e.preventDefault();

Not necessary for this patch, but to prevent sideeffects in other views from occuring possibly -- want me to remove?

Comment 5

[Victor Porof [:vporof][:vp]]

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #4)
> Comment on attachment 8560692 [details] [diff] [review]
> 1111020-fix-key-events.patch
> 
> Review of attachment 8560692 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/devtools/performance/test/browser_perf-events-calltree.js
> @@ +34,5 @@
> > +  fireKey("VK_DOWN");
> > +
> > +  JsCallTreeView.off("focus", focusEvent);
> > +
> > +  ok(focus > 1, "several focus events are fired for the js calltree.");
> 
> Will we always have sufficient enough call tree items? That's my concern as
> the stack generated isn't deterministic, I believe
> 

Sounds like we should populate the tree manually.

> ::: browser/devtools/shared/widgets/AbstractTreeItem.jsm
> @@ +447,5 @@
> >  
> >      switch (e.keyCode) {
> >        case e.DOM_VK_UP:
> >          this._focusPrevNode();
> > +        e.preventDefault();
> 
> Not necessary for this patch, but to prevent sideeffects in other views from
> occuring possibly -- want me to remove?

"possibly" is a weird reason. I'd steer clear from changes like these, but it's up to you.

Comment 6

[Jordan Santell [:jsantell] [@jsantell]]

Attachment: 1111020-fix-key-events.patch

Manually populating the call tree view, and removed the preventDefaults

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/fx-team/rev/0dab1771c9b7

Comment 8

[[Back August 16] Ryan VanderMeulen]

https://hg.mozilla.org/mozilla-central/rev/0dab1771c9b7