Edit and Resend should use proper styling for input fields

RESOLVED FIXED in Firefox 65

Status

P3
normal
RESOLVED FIXED
4 months ago
3 months ago

People

(Reporter: Honza, Assigned: asorholm, Mentored)

Tracking

(Blocks: 1 bug, {good-first-bug})

unspecified
Firefox 65
good-first-bug

Firefox Tracking Flags

(firefox65 fixed)

Details

(Whiteboard: good-first-bug)

Attachments

(11 attachments, 1 obsolete attachment)

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
Created attachment 9011744 [details]
edit-and-resend.jpg
@Matt: how does that sound to you? Perhaps we could make the 'Send' and 'Cancel' buttons more visible?

Honza
Flags: needinfo?(mcroud)
Mentor: odvarko
Keywords: good-first-bug
Priority: -- → P3
Whiteboard: good-first-bug
Blocks: 1475161

Comment 3

4 months ago
Created attachment 9011747 [details]
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.
Created attachment 9011750 [details]
button.jpg

Thanks Matt for quick reply!

(In reply to Matthew Croud 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
(Assignee)

Comment 5

4 months ago
Hi, 

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

Comment 6

4 months ago
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

4 months ago
Hi, is this bug still unassigned? If it is, I would like to work on it as my first contribution.
(Assignee)

Comment 8

4 months ago
(In reply to Matthew Croud 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.
@Adam: assigned to you.

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

Honza
Assignee: nobody → asorholm
Status: NEW → ASSIGNED
(Assignee)

Comment 10

4 months ago
(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

4 months ago
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.
Thanks Matt, this is great spec!
Honza

Updated

4 months ago
Flags: needinfo?(mcroud)

Comment 13

4 months ago
@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?
Flags: needinfo?(mcroud)
(In reply to Matthew Croud 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
(Assignee)

Comment 15

4 months ago
(In reply to Matthew Croud 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!
(Assignee)

Comment 16

4 months ago
@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!
(Assignee)

Comment 17

4 months ago
(In reply to Matthew Croud 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

4 months ago
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.
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/
(Demos are responsive; resize the browser window or use the RDM to see how they behave in a smaller viewport.)
(In reply to Matthew Croud 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
(Assignee)

Comment 22

3 months ago
(In reply to Matthew Croud 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

3 months ago
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.
Flags: needinfo?(mcroud)
(Assignee)

Comment 24

3 months ago
(In reply to Matthew Croud 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?
>  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.
(Assignee)

Comment 26

3 months ago
Created attachment 9019208 [details]
edit-and-resend-progress-dark.jpg
(Assignee)

Comment 27

3 months ago
Created attachment 9019209 [details]
edit-and-resend-progress-light.jpg
(Assignee)

Comment 28

3 months ago
Created attachment 9019210 [details]
edit-and-resend-progress-dark-w-scroll.jpg
(Assignee)

Comment 29

3 months ago
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?
> 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.
(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
(Assignee)

Comment 32

3 months ago
Created attachment 9019554 [details] [diff] [review]
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.
Flags: needinfo?(odvarko)
Attachment #9019554 - Flags: feedback?(odvarko)
Attachment #9019554 - Flags: feedback?(mcroud)
Attachment #9019554 - Flags: feedback?(florens)
> 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 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
Attachment #9019554 - Flags: feedback?(odvarko) → feedback+
Created attachment 9019586 [details]
Height of input fields should be unified.png

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

Honza
Flags: needinfo?(odvarko)
@Matt: Please see my previous comment & screenshot.

Honza
Flags: needinfo?(mcroud)
> 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

3 months ago
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.
Flags: needinfo?(mcroud)
(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
(Assignee)

Comment 40

3 months ago
(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?
I think Jan meant the colon character (":").
Attachment #9019554 - Flags: feedback?(florens)
(In reply to Florens Verschelde [:fvsch] from comment #41)
> I think Jan meant the colon character (":").
yeah, correct 'colon' is what I meant :-)

Honza
(Assignee)

Comment 43

3 months ago
(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!
> 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 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.
(Assignee)

Comment 46

3 months ago
Created attachment 9022346 [details] [diff] [review]
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.
Flags: needinfo?(odvarko)
Attachment #9019554 - Attachment is obsolete: true
Flags: needinfo?(odvarko)
Attachment #9019554 - Flags: feedback?(mcroud)
Comment on attachment 9022346 [details] [diff] [review]
bug1493931.patch

Looks great now!

Honza
Attachment #9022346 - Flags: review+
Keywords: checkin-needed

Comment 48

3 months ago
Pushed by csabou@mozilla.com:
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
Keywords: checkin-needed

Comment 49

3 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/cab406acd52e
Status: ASSIGNED → RESOLVED
Last Resolved: 3 months ago
status-firefox65: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65
You need to log in before you can comment on or make changes to this bug.