1277608 - Develop prototype UI for a content process monitoring tool

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect, P3)

Description

[rsurve]

Attachment: A prototype of how the UI is expected to look like

This bug blocks bug 1255843. We wish to develop a tool that measures memory related performance of content processes.

Comment 1

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

Comment on attachment 8759225 [details]
A prototype of how the UI is expected to look like

Hey Rutuja,

Would you mind posting this as a patch instead of the full xhtml file? Instructions for creating a patch are here: https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F

Generally, I think this is the right idea, though I have some visual suggestions:

1) Let's get rid of the "About memory" header.
2) The table should probably show some visual separation between the cells - right now, it looks like numbers floating in space. Check out the way things are organized in about:support to get a sense of what styling we might try to emulate here.
3) I'm not sure that "Name" makes much sense just yet. Currently, we've got a single content process, and over time, we might have a few, but I don't know if we'll ever get to process-per-tab. Maybe someday, but not just yet. So for now, let's drop this column.
4) We'll want units next to each number, I believe.
5) I'm not sure if "RSS" and "USS" are the right terms to display to the user. I think we can assume that the users that visit this page will understand the basics of memory usage, but we might need to make things a bit clearer to them. I'll ask around.
6) Process-Id should probably be Process ID

Comment 2

[rsurve]

Attachment: xhtml Prototype file with changes

Comment 3

[rsurve]

Attachment: Patch of the prototype

Comment 4

[rsurve]

Attachment: Patch: Prototype

Comment 5

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

Comment on attachment 8759968 [details] [diff] [review]
Patch: Prototype

Thanks Rutuja.

1) Let's try to match the styling of about:support for the tabular data. This means colours, fonts, font-sizes, etc.
2) Perhaps for now, let's try to keep the pattern going, and change the section header to "Performance of Processes"
3) Also, let's get rid of that green break between the header and the table.

Comment 6

[rsurve]

Attachment: Patch: similar to aboutSupport styling

Comment 7

[rsurve]

Attachment: Revised Prototype styled according to aboutSupport

Comment 8

[rsurve]

Attachment: Patch final

Comment 9

[rsurve]

I've attached the Revised Prototype that uses styling similar to the aboutSupport table.

Comment 10

[rsurve]

Attachment: Patch with table styled according to aboutSupport

Comment 11

[rsurve]

Attachment: Prototype file : xhtml

Comment 12

[rsurve]

Attachment: Patch where updated text doesn't change color

Comment 13

[rsurve]

I've attached 2 patches, both styled according to aboutSupport. One changes the color of the updated text whenever calculations get updated, the other doesn't. The xhtml file attached corresponds to the latter one (with no color changes)

Comment 14

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

Comment on attachment 8760724 [details]
Prototype file : xhtml

Hey Rutuja, I talked to :bram from the UX team in IRC, and here's what he suggested:

1) Each row should probably be accompanied by something that describes what the process is. The process ID is useful, but not very descriptive - so maybe a "Process Type" column. I'm thinking something like this:

 ------------------------------------------------------------------------------------
|    Process Type    |    Unique Set Size   |   Resident Set Size   |   Process ID   |
|------------------------------------------------------------------------------------|
|   Content (6 tabs) |         254MB        |         254MB         |     1508       |
|------------------------------------------------------------------------------------|


The Unique Set Size and Resident Set Size table headers should probably show some kind of tooltip explaining what those terms mean on hover. We do the same thing in about:memory for various terms on mouse hover.

2) The about:support table styling looks good - let's go with that for now.

The following bits of feedback are from me:

1) Let's get rid of the extra padding around the table
2) We might want to consider not having the table stretch for the entire width of the display (which can be quite long), but let's keep it as is for now.

Comment 15

[rsurve]

Attachment: Prototype: with hovering enabled to give the user info reg. RSS/USS

Comment 16

[rsurve]

Attachment: Patch: Prototype

Comment 17

[rsurve]

Attachment: Patch with changes

Comment 18

[rsurve]

(In reply to Mike Conley (:mconley) - (needinfo me!) from comment #14)
> Comment on attachment 8760724 [details]
> Prototype file : xhtml
> 
> Hey Rutuja, I talked to :bram from the UX team in IRC, and here's what he
> suggested:
> 
> 1) Each row should probably be accompanied by something that describes what
> the process is. The process ID is useful, but not very descriptive - so
> maybe a "Process Type" column. I'm thinking something like this:
> 
>  ----------------------------------------------------------------------------
> --------
> |    Process Type    |    Unique Set Size   |   Resident Set Size   |  
> Process ID   |
> |----------------------------------------------------------------------------
> --------|
> |   Content (6 tabs) |         254MB        |         254MB         |    
> 1508       |
> |----------------------------------------------------------------------------
> --------|
> 
> 
> The Unique Set Size and Resident Set Size table headers should probably show
> some kind of tooltip explaining what those terms mean on hover. We do the
> same thing in about:memory for various terms on mouse hover.
> 
> 2) The about:support table styling looks good - let's go with that for now.
> 
> The following bits of feedback are from me:
> 
> 1) Let's get rid of the extra padding around the table
> 2) We might want to consider not having the table stretch for the entire
> width of the display (which can be quite long), but let's keep it as is for
> now.

I've attached the patch with the changes suggested above ^. I've taken inspiration from aboutmemory for styling the text that becomes visible on hovering.

Comment 19

[Blake Kaplan (:mrbkap) (inactive)]

This looks really cool!

I wonder if it would be possible to give the users the opportunity to hard kill a given content process from this UI as well eventually. I'm not sure if other people think that would be useful though.

Comment 20

[Rutuja]

Attachment: Diff file with getReportsforSubprocesses attached

Comment 21

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

The prototype has been created, so we have a design to work off of. Closing this one out.

Comment 22

[Rutuja]

Attachment: Patch for getReportsForSubprocesses - 1 (Built successfully)

Comment 23

[rsurve]

Attachment: Linux Patch

This is the Linux patch for our tool

Comment 24

[rsurve]

Attachment: Table(without hovering).png

Comment 25

[rsurve]

Attachment: Table(Hover over RSS).png

Comment 26

[rsurve]

Attachment: Table (After Hovering over USS).png

Comment 27

[rsurve]

I've also attached screenshots of the tool looks like

Comment 28

[rsurve]

I've also attached screenshots of the tool (Without the user hovering over to know more about what RSS/USS is and with the user hovering over it). The styling is similar to about:support, as used in the prototype. The data changes every 5 seconds.

Comment 29

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

Comment on attachment 8778885 [details] [diff] [review]
Linux Patch

Moving this to bug 1255843.