1493931 - Edit and Resend should use proper styling for input fields

Status: RESOLVED FIXED

(DevTools :: Netmonitor, enhancement, P3)

Description

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Edit and resend side panel (in Network panel) should use the same nice styling as Fonts side panel (in the Inspector panel).

The styling should support both Light and Dark themes.

Colors for input boxes in the Fonts panel are defined here:

Light theme:
https://searchfox.org/mozilla-central/rev/881a3c5664ede5e08ee986d76433bc5c4b5680e6/devtools/client/themes/fonts.css#8-10

Dark theme:
https://searchfox.org/mozilla-central/rev/881a3c5664ede5e08ee986d76433bc5c4b5680e6/devtools/client/themes/fonts.css#18-20

These CSS variables should be moved into shared location, so the Network panel can use it - into variables.css file:

https://searchfox.org/mozilla-central/source/devtools/client/themes/variables.css

I am attaching a screenshot that compares the Edit and Resend side-panel with Fonts side panel.

Honza

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Attachment: edit-and-resend.jpg

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Matt: how does that sound to you? Perhaps we could make the 'Send' and 'Cancel' buttons more visible?

Honza

Comment 3

[mcroud]

Attachment: Developer tools button example

Yes totally agree, I completely missed those buttons at the top. Maybe we could use the "clearly-a-button" styling present in the Accessibility and Memory panels. It is designed to mimic a form so my brain expects obvious buttons below the form fields.
Out of curisoity, Is it likely that a developer would want to edit all of the fields, would they typically start from "New Request" at the top and edit all the way down to "Request Body"? Trying to determine whether the bottom is a logical place if we were to make them more obvious.

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Attachment: button.jpg

Thanks Matt for quick reply!

(In reply to mcroud from comment #3)
> Yes totally agree, I completely missed those buttons at the top. Maybe we
> could use the "clearly-a-button" styling present in the Accessibility and
> Memory panels. It is designed to mimic a form so my brain expects obvious
> buttons below the form fields.
Yes, I like that. I am also attaching a screenshot of the Memory panel with the button in Light theme.

> Out of curiosity, Is it likely that a developer would want to edit all of
> the fields, would they typically start from "New Request" at the top and
> edit all the way down to "Request Body"? Trying to determine whether the
> bottom is a logical place if we were to make them more obvious.
I don't have any data, but I think that the use case might often be "just resend the request again", i.e. the user is not changing any data. And changing the request-body also doesn't have to be always done.

So, I tend to think that keeping the buttons at the top is better since they are visible all the time (user is not required to scroll down).

Honza

Comment 5

[Adam Holm]

Hi, 

I can't tell, is Matt working on this bug, or does it still need someone to work on it?

Comment 6

[mcroud]

Hi Adam, I planned on making a quick mockup of this but I'm a little way off moving onto this bug at the moment.

Comment 7

[Deepashree]

Hi, is this bug still unassigned? If it is, I would like to work on it as my first contribution.

Comment 8

[Adam Holm]

(In reply to mcroud from comment #6)
> Hi Adam, I planned on making a quick mockup of this but I'm a little way off
> moving onto this bug at the moment.

Thanks for the reply! I was curious about taking a crack at this, but then got busy with other things. If it's still up for grabs, I'd still be interested in taking a crack at it.

Comment 9

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Adam: assigned to you.

But, let's wait on Matt's input on this first.

Honza

Comment 10

[Adam Holm]

(In reply to Jan Honza Odvarko [:Honza] from comment #9)
> @Adam: assigned to you.
> 
> But, let's wait on Matt's input on this first.
> 
> Honza

Thanks! Sounds good.

Comment 11

[mcroud]

Attachment: New UI design for Edit and Resend panel

Please find the new UI attached.

Adam, let me know what extra information you need. I was hoping that Invision would allow me to share a link with Inspector mode enabled but alas no :/

Information on what colors to use: https://design.firefox.com/photon/visuals/color.html#grey and spacing amounts (generally a 4px grid, so think multiples of 4): https://design.firefox.com/photon/visuals/grid.html can be found in the Photon docs.   

If you would like me to annotate it with specific measures and color codes let me know.

Comment 12

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks Matt, this is great spec!
Honza

Comment 13

[mcroud]

@Honza I received some feedback from the latest designs from Harald and fvsch which discuss making some structural changes to the panel:

- Could “New Request” be more of a panel header, as it is not really a label for the first line of inputs?

- For the form design, `Send` could be a primary style button and on the right

- Having "Method" and "URL" labels could help with accessibility too.

- The method input could also use a datalist for autocompleting method keywords

Would these amends belong in this bug (and I provide an updated design), or should these changes be a new bug to file?

Comment 14

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to mcroud from comment #13)
> - Could “New Request” be more of a panel header, as it is not really a label
> for the first line of inputs?
> 
> - For the form design, `Send` could be a primary style button and on the
> right
> 
> - Having "Method" and "URL" labels could help with accessibility too.
This should be done as part of this bug.


> - The method input could also use a datalist for autocompleting method
> keywords
I created a follow up for this - bug 1496038

Thanks!
Honza

Comment 15

[Adam Holm]

(In reply to mcroud from comment #11)
> Created attachment 9013557 [details]
> New UI design for Edit and Resend panel
> 
> Please find the new UI attached.
> 
> Adam, let me know what extra information you need. I was hoping that
> Invision would allow me to share a link with Inspector mode enabled but alas
> no :/
> 
> Information on what colors to use:
> https://design.firefox.com/photon/visuals/color.html#grey and spacing
> amounts (generally a 4px grid, so think multiples of 4):
> https://design.firefox.com/photon/visuals/grid.html can be found in the
> Photon docs.   
> 
> If you would like me to annotate it with specific measures and color codes
> let me know.

This is very helpful, thank you very much!

Comment 16

[Adam Holm]

@Honza Are there any guides for best practices and workflows for use when editing the Firefox UI? I've found most of the basic style guides, I'm looking for guides specific to editing UI. I've been looking through the available documentation but have been having trouble finding anything. For example, I found this article on Coding style: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style, but it doesn't mention CSS selectors; the articles for new developers (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Articles_for_new_developers) found in the Developers Guide aren't specific enough for what I'm looking for.

I ask because I've been working on implementing the UI Matt gave me, through editing dark-theme.css (https://searchfox.org/mozilla-central/source/devtools/client/themes/dark-theme.css) and variables.css (https://searchfox.org/mozilla-central/source/devtools/client/themes/variables.css). I want to make sure that's the correct way to go about implementing the changes. I also want to make sure I'm following any Mozilla conventions for things like CSS selectors used to style elements, and any organization in style sheets.

Let me know if my question isn't clear, I'll do my best to make it clearer. Thanks for your help!

Comment 17

[Adam Holm]

(In reply to mcroud from comment #11)
> Created attachment 9013557 [details]
> New UI design for Edit and Resend panel
> 
> Please find the new UI attached.
> 
> Adam, let me know what extra information you need. I was hoping that
> Invision would allow me to share a link with Inspector mode enabled but alas
> no :/
> 
> Information on what colors to use:
> https://design.firefox.com/photon/visuals/color.html#grey and spacing
> amounts (generally a 4px grid, so think multiples of 4):
> https://design.firefox.com/photon/visuals/grid.html can be found in the
> Photon docs.   
> 
> If you would like me to annotate it with specific measures and color codes
> let me know.

I think I may need those annotations. I'm having difficulty with determining which of several greys the correct grey is for elements in the dark theme.

Comment 18

[mcroud]

Attachment: edit-resend-ui-v3-2x.png

Taking on feedback from the previous version, here is the latest iteration (which is currently out for feedback).
We're using a primary "micro" Photon button for send and we now provide proper labels for method and URL along with the incusion of a header bar to hold the form title.

@Adam No problem, if the latest iteration gets positive feedback I will provide a new visual with Photon color names for you.

Comment 19

[Florens Verschelde :fvsch]

Since I was not sure about the button placement, I made 3 demos with sticky buttons (buttons that remain visible even if the main content area is scrolled):

Bottom: https://codepen.io/fvsch/full/NObMNp/
Top right, below header: https://codepen.io/fvsch/full/PybBYX/
Top right, inside header: https://codepen.io/fvsch/full/pxNZbg/

Comment 20

[Florens Verschelde :fvsch]

(Demos are responsive; resize the browser window or use the RDM to see how they behave in a smaller viewport.)

Comment 21

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to mcroud from comment #18)
> Created attachment 9015201 [details]
> edit-resend-ui-v3-2x.png
Fabulous!

(In reply to Adam Holm from comment #16)
> I ask because I've been working on implementing the UI Matt gave me, through
> editing dark-theme.css
> (https://searchfox.org/mozilla-central/source/devtools/client/themes/dark-
> theme.css) and variables.css
> (https://searchfox.org/mozilla-central/source/devtools/client/themes/
> variables.css). I want to make sure that's the correct way to go about
> implementing the changes. I also want to make sure I'm following any Mozilla
> conventions for things like CSS selectors used to style elements, and any
> organization in style sheets.

I am not sure if I understand the question, but some notes:

1) Using CSS variables from variables.css is the right way to go
2) All the new styles related to the Edit and Resend form should go to a new CSS file:

devtools/client/netmonitor/src/assets/styles/CustomRequestPanel.js

That file should be included in netmonitor.css file 

Don't forget to also add the file into:
devtools\client\jar.mn


(In reply to Florens Verschelde from comment #19)
> Since I was not sure about the button placement, I made 3 demos with sticky
> buttons (buttons that remain visible even if the main content area is
> scrolled):
I think that the buttons should be at the top, so visible all the time.
Just like Matt indicated on his mockups.

Honza

Comment 22

[Adam Holm]

(In reply to mcroud from comment #18)
> Created attachment 9015201 [details]
> edit-resend-ui-v3-2x.png
> 
> Taking on feedback from the previous version, here is the latest iteration
> (which is currently out for feedback).
> We're using a primary "micro" Photon button for send and we now provide
> proper labels for method and URL along with the incusion of a header bar to
> hold the form title.
> 
> @Adam No problem, if the latest iteration gets positive feedback I will
> provide a new visual with Photon color names for you.

Awesome, thanks!


(In reply to Jan Honza Odvarko [:Honza] from comment #21)
> I am not sure if I understand the question, but some notes:
> 
> 1) Using CSS variables from variables.css is the right way to go
> 2) All the new styles related to the Edit and Resend form should go to a new
> CSS file:
> 
> devtools/client/netmonitor/src/assets/styles/CustomRequestPanel.js
> 
> That file should be included in netmonitor.css file 
> 
> Don't forget to also add the file into:
> devtools\client\jar.mn
> 

This is exactly what I was looking for, thank you!

Comment 23

[mcroud]

Attachment: New request v3 annotations.png

@Adam,

I have created an annotated version of the new design.
I have labelled the photon colours used, though as Honza pointed out you’ll want to be using CSS variables from variables.css.

I hope it points you in the right direction at least!
Let me know if you need anything else.

Comment 24

[Adam Holm]

(In reply to mcroud from comment #23)
> Created attachment 9017108 [details]
> New request v3 annotations.png
> 
> @Adam,
> 
> I have created an annotated version of the new design.
> I have labelled the photon colours used, though as Honza pointed out you’ll
> want to be using CSS variables from variables.css.
> 
> I hope it points you in the right direction at least!
> Let me know if you need anything else.

This is great, thank you very much!

(In reply to Jan Honza Odvarko [:Honza] from comment #21)
> 1) Using CSS variables from variables.css is the right way to go

One question that occurred to me: may I add new varibles to variables.css, if I'm unable to find the color I need, or should I just work with the closest available color that exists as a variable in variables.css?

Comment 25

[Florens Verschelde :fvsch]

>  may I add new varibles to variables.css, if I'm unable to find the color I need,
> or should I just work with the closest available color that exists as a variable in variables.css?

If you want to use a color from the Photon palette (https://design.firefox.com/photon/visuals/color.html) and it doesn't already have a matching variable in `variables.css`, you can add that variable. We don't define Photon colors that are not yet used because we have a linting rule in place to prevent orphan or unused CSS variables. So some Photon blues, magentas etc. are not defined in `variables.css`

If you need a color that is not in the Photon palette, can you try to find the closest one in the palette?
You can ask here if you're not sure what would work.

Comment 26

[Adam Holm]

Attachment: edit-and-resend-progress-dark.jpg

Comment 27

[Adam Holm]

Attachment: edit-and-resend-progress-light.jpg

Comment 28

[Adam Holm]

Attachment: edit-and-resend-progress-dark-w-scroll.jpg

Comment 29

[Adam Holm]

Comment on attachment 9019208 [details]
edit-and-resend-progress-dark.jpg

@Honza 

I've attached images of what my changes look like at this point. Not sure if I did it quite right, but hopefully they're visible.

I've generated some questions about the fixes:

1) In Matt's examples of the new design, are the labels on the method and url text inputs important?

  a) If so, I implemented this with CSS grid. I tried doing so with flex, but it was tricky. I couldn't find anything about using grid in the style guides, though, so I'm not sure about using it. To do so I edited files:
      
      * devtools/client/locales/en-US/netmonitor.properties
      * devtools/client/netmonitor/src/components/CustomRequestPanel.js
    
    Is this okay, or is there a different way that I should be implementing these labels (I tried to implement the labels with ::before pseudo elements, but that proved to be rather difficult as well).

2) Related to the above: the labels for the other textarea elements are div elements, and not label elements. Should that be changed?

3) mozilla-central/devtools/client/netmonitor/src/components/CustomRequestPanel.js generates .custom-header and the send and cancel buttons in the order: .custom-header 1st, 2nd send button, 3rd cancel button. This causes the buttons to show up out of order relative to Matt's design. I rearranged the buttons with flexbox to match Matt's design, but I can edit CustomRequestPanel.js if that would be a better solution, if the order matching matters at all.

4) For devtools' dark theme, the "New Response" bottom border color, --accordion-header-background, in Matt's design is undefined, I decided on using grey-80 for now.

5) I can't find any style guides for scrollbars in the documentation for the Photon Design System. Should I just make them match Matt's example as best I can?

Comment 30

[Florens Verschelde :fvsch]

> 1) and 2) [Labels]

Ideally we should have accessible labels for all fields (both new and old), using this pattern:

<label for="the-field-id">Label text</label>
<input id="the-field-id"/>

If for some reason a field doesn't have a visible label, we should have add one using ARIA:
<input id="the-field-id" aria-label-"Label text"/>
(But I don't think we have this use case in this design.)

> 5) [Scrollbar styles]

We're using platform-specific scrollbars, so there is no need to style them.

Comment 31

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Adam Holm from comment #29)
> I've attached images of what my changes look like at this point. Not sure if
> I did it quite right, but hopefully they're visible.
Thanks for the update, the screenshots look great!

Can you attach also your patch, so I can try it on my machine?
(I can test on Win 10 and OSX)

> 3)
> mozilla-central/devtools/client/netmonitor/src/components/CustomRequestPanel.
> js generates .custom-header and the send and cancel buttons in the order:
> .custom-header 1st, 2nd send button, 3rd cancel button. This causes the
> buttons to show up out of order relative to Matt's design. I rearranged the
> buttons with flexbox to match Matt's design, but I can edit
> CustomRequestPanel.js if that would be a better solution, if the order
> matching matters at all.
Matt's design is the source of truth here, so rearranging is fine.

> 4) For devtools' dark theme, the "New Response" bottom border color,
> --accordion-header-background, in Matt's design is undefined, I decided on
> using grey-80 for now.
Sounds good to me (we'll ask Matt for final review as soon as all is ready)

> 5) I can't find any style guides for scrollbars in the documentation for the
> Photon Design System. Should I just make them match Matt's example as best I
> can?
Just use native scrollbars (i.e. no extra styling).

Honza

Comment 32

[Adam Holm]

Attachment: bug1493931.patch

@fvsch

(In reply to Florens Verschelde [:fvsch] from comment #30)
> > 1) and 2) [Labels]
> 
> Ideally we should have accessible labels for all fields (both new and old),
> using this pattern:
> 
> <label for="the-field-id">Label text</label>
> <input id="the-field-id"/>

I've done this for the labels I added. I can do this for the existing text fields as well (changing <div> labels to <label> labels), but should I start a new bug for that fix, or is making those changes with this bug fix okay?

(In reply to Jan Honza Odvarko [:Honza] from comment #31)
> (In reply to Adam Holm from comment #29)
> > I've attached images of what my changes look like at this point. Not sure if
> > I did it quite right, but hopefully they're visible.
> Thanks for the update, the screenshots look great!
> 
> Can you attach also your patch, so I can try it on my machine?
> (I can test on Win 10 and OSX)

I've attached my patch. I'm fairly certain I did everything correctly, but if you run into any issues, let me know and I'll fix them.


> Matt's design is the source of truth here, so rearranging is fine.
> . . .
> Just use native scrollbars (i.e. no extra styling).

Sounds good.

Comment 33

[Florens Verschelde :fvsch]

> I can do this for the existing text fields as well (changing <div> labels to <label> labels), but should I start a new bug for that fix, or is making those changes with this bug fix okay?

Doing it in this bug should be okay.

One way to test your work is by clicking the labels. If the for and id attributes are matched correctly, clicking the label should put the focus in the corresponding input/textarea.

Comment 34

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Comment on attachment 9019554 [details] [diff] [review]
bug1493931.patch

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

This looks great!

A few comments:
1) I am seeing one minor conflict when applying the patch on latest m-c HEAD
2) Height of the method and URL fields is bigger than fields in the Fonts side panel (in the Inspector panel). I think it should be the same (I'll attach a screenshot)
3) "Request Headers:" and "Request Body:" labels have color character, it should be removed
4) Clicking on "Request Headers:" and "Request Body:" doesn't move the focus to corresponding fields (already mentioned)

Thanks!

Honza

Comment 35

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Attachment: Height of input fields should be unified.png

Height of input fields should be unified across tools/panels.

Honza

Comment 36

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Matt: Please see my previous comment & screenshot.

Honza

Comment 37

[Florens Verschelde :fvsch]

> Height of the method and URL fields is bigger than fields in the Fonts side panel

Personally I find the small text inputs a bit hard to use (I'm not very precise with touchpads on most laptops); that makes sense in the Fonts panel because of the information density, but if we can get away with bigger controls in other places that can be useful IMO.

I'm also wondering if the textareas should wrap lines (white-space:pre-wrap). That would make editing easier, e.g. when pasting a JSON payload for the request body. On the other hand, for the Headers field it might be confusing since line breaks have a precise meaning.

Comment 38

[mcroud]

Yes the input fields height should match those of the fonts panel, as per Honza's attachement.
My mockups are 2x resolution so will appear larger. Looking at the Fonts panel, with 13.5 line-height, 2px top/bottom padding and 1px border you're looking at 20px for height in total.

Comment 39

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Florens Verschelde [:fvsch] from comment #37)
> I'm also wondering if the textareas should wrap lines
> (white-space:pre-wrap). That would make editing easier, e.g. when pasting a
> JSON payload for the request body. On the other hand, for the Headers field
> it might be confusing since line breaks have a precise meaning.

Good question, let's keep this behavior as is and create
a new report where we can discuss it.

Honza

Comment 40

[Adam Holm]

(In reply to Jan Honza Odvarko [:Honza] need-info me from comment #34)
> A few comments:
> 1) I am seeing one minor conflict when applying the patch on latest m-c HEAD

Are these conflicts visible in verbose output from ./mach build?

> 3) "Request Headers:" and "Request Body:" labels have color character, it
> should be removed

I'm not sure what you mean by color character. Do you mean the font color?

Comment 41

[Florens Verschelde :fvsch]

I think Jan meant the colon character (":").

Comment 42

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Florens Verschelde [:fvsch] from comment #41)
> I think Jan meant the colon character (":").
yeah, correct 'colon' is what I meant :-)

Honza

Comment 43

[Adam Holm]

(In reply to Florens Verschelde [:fvsch] from comment #41)
> I think Jan meant the colon character (":").

Ohhh, that makes sense. Thanks for the clarification. 

(In reply to Jan Honza Odvarko [:Honza] need-info me from comment #34)
> A few comments:
> 1) I am seeing one minor conflict when applying the patch on latest m-c HEAD

I have all but this first comment addressed. I'm not sure how to reproduce this conflict, and am having difficulty finding help in the documentation. How do I reproduce and/or see the conflicts generated when applying my patch?

Thanks!

Comment 44

[Florens Verschelde :fvsch]

> I'm not sure how to reproduce this conflict

My workflow for this, using Mercurial, is:

# Get the latest mozilla-central
$ hg pull

# Look at the changeset id for the tip (latest changeset in mozilla-central) and copy it
$ hg heads

# Make sure I'm on the latest changeset of my own work
$ hg update <my-changeset-id>

# Rebase on top of the mozilla-central tip
$ hg rebase --dest <tip-changeset-id>

The conflict should come up when rebasing. By default, Mercurial will pop up a merge tool for each conflicted file. Since you're on Linux, it's likely to be Meld, but you can configure a different one, and even use conflict markers like Git does:
https://www.mercurial-scm.org/wiki/MergeToolConfiguration

Comment 45

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Comment on attachment 9019554 [details] [diff] [review]
bug1493931.patch

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

Here is the conflict I am seeing when applying the patch on latest m-c source.
Make sure you are working with the latest source by:

$hg pull -u

Here is the conflict:

applying edit-and-resend.patch
patching file devtools/client/netmonitor/src/assets/styles/netmonitor.css
Hunk #1 FAILED at 19
1 out of 1 hunks FAILED -- saving rejects to file devtools/client/netmonitor/src/assets/styles/netmonitor.css.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working directory
errors during apply, please fix and qrefresh edit-and-resend.patch


The reason is that another patch added new import statement at the end of the list (in netmonitor.css)

...
@import "chrome://devtools/content/netmonitor/src/assets/styles/StatisticsPanel.css";
@import "chrome://devtools/content/netmonitor/src/assets/styles/StatusCode.css";

So, you just need to rebase.


Also, make sure to adjust height of the "Method" and "URL" input fields.

Thanks!
Honza

::: devtools/client/netmonitor/src/assets/styles/CustomRequestPanel.css
@@ +111,5 @@
> +:root.theme-dark .network-details-panel .custom-request-panel textarea { 
> +  background-color: var(--grey-70);
> +  border: 1px solid var(--grey-85); 
> +  color: white; 
> +}

I am seeing some trailing white space on the rowse above. Please remove

@@ +129,5 @@
> +
> +:root.theme-light .network-details-panel .custom-request-panel input,
> +:root.theme-light .network-details-panel .custom-request-panel textarea { 
> +  background-color: white;
> +  border: 1px solid var(--grey-25); 

Again, couple of trailing whitespaces.

Comment 46

[Adam Holm]

Attachment: bug1493931.patch

(In reply to Florens Verschelde [:fvsch] from comment #44)
> > I'm not sure how to reproduce this conflict
> 
> My workflow for this, using Mercurial, is:
> 
> # Get the latest mozilla-central
> $ hg pull
> 
> # Look at the changeset id for the tip (latest changeset in mozilla-central)
> and copy it
> $ hg heads
> 
> # Make sure I'm on the latest changeset of my own work
> $ hg update <my-changeset-id>
> 
> # Rebase on top of the mozilla-central tip
> $ hg rebase --dest <tip-changeset-id>
> 
> The conflict should come up when rebasing. By default, Mercurial will pop up
> a merge tool for each conflicted file. Since you're on Linux, it's likely to
> be Meld, but you can configure a different one, and even use conflict
> markers like Git does:
> https://www.mercurial-scm.org/wiki/MergeToolConfiguration

Thank you for the explanation, this was very helpful! 

(In reply to Jan Honza Odvarko [:Honza] (need-info? me) from comment #45)
> Comment on attachment 9019554 [details] [diff] [review]
> bug1493931.patch
> 
> Review of attachment 9019554 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Here is the conflict I am seeing when applying the patch on latest m-c
> source.
> Make sure you are working with the latest source by:
> 
> $hg pull -u
> 
> Here is the conflict:
> 
> applying edit-and-resend.patch
> patching file devtools/client/netmonitor/src/assets/styles/netmonitor.css
> Hunk #1 FAILED at 19
> 1 out of 1 hunks FAILED -- saving rejects to file
> devtools/client/netmonitor/src/assets/styles/netmonitor.css.rej
> patch failed, unable to continue (try -v)
> patch failed, rejects left in working directory
> errors during apply, please fix and qrefresh edit-and-resend.patch
> 
> 
> The reason is that another patch added new import statement at the end of
> the list (in netmonitor.css)
> 
> ...
> @import
> "chrome://devtools/content/netmonitor/src/assets/styles/StatisticsPanel.css";
> @import
> "chrome://devtools/content/netmonitor/src/assets/styles/StatusCode.css";
> 
> So, you just need to rebase.
> 
> 
> Also, make sure to adjust height of the "Method" and "URL" input fields.
> 
> Thanks!
> Honza
> 
> ::: devtools/client/netmonitor/src/assets/styles/CustomRequestPanel.css
> @@ +111,5 @@
> > +:root.theme-dark .network-details-panel .custom-request-panel textarea { 
> > +  background-color: var(--grey-70);
> > +  border: 1px solid var(--grey-85); 
> > +  color: white; 
> > +}
> 
> I am seeing some trailing white space on the rowse above. Please remove
> 
> @@ +129,5 @@
> > +
> > +:root.theme-light .network-details-panel .custom-request-panel input,
> > +:root.theme-light .network-details-panel .custom-request-panel textarea { 
> > +  background-color: white;
> > +  border: 1px solid var(--grey-25); 
> 
> Again, couple of trailing whitespaces.

Thanks for the walk-through on finding the conflict, it helped me a lot! 

I've resolve the conflict by rebasing as you suggested. I updated to the tip of mozilla-central around 5:30pm today and there were no conflicts. I've removed the trailing whitespace that you pointed out, and the Browser Toolbox inspector showed the height of the "method" and "url" input fields matching the height of the input fields in DevTool's inspector font panel. 

Let me know if you find any more issues.

Comment 47

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Comment on attachment 9022346 [details] [diff] [review]
bug1493931.patch

Looks great now!

Honza

Comment 48

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cab406acd52e
Changes to styling of custom request panel of Network panel in DevTools. Fixing issues with previous patch. r=Honza

Comment 49

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/cab406acd52e