Closed Bug 1584960 Opened 5 years ago Closed 5 years ago

Netmonitor blocking - remove text offset in text-box when editing request filters

Categories

(DevTools :: Netmonitor, enhancement, P3)

71 Branch
enhancement

Tracking

(firefox70 unaffected, firefox71 verified, firefox72 verified)

RESOLVED FIXED
Tracking Status
firefox70 --- unaffected
firefox71 --- verified
firefox72 --- verified

People

(Reporter: cfogel, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Affected versions

  • 71.0a1 (2019-09-29)

Affected platforms

  • all available

Steps to reproduce

  1. Launch Firefox;
  2. (if not already)Set devtools.netmonitor.features.requestBlocking to true;
  3. Access any webpage, open the DevTools inspector - Network tab;
  4. Block any request so that the Blocking UI is enabled;
  5. In the Request blocking section set any filter and (double) click on it to make it ediable;

Expected result

  1. text should expand over all the available area in the text-box;
  2. another suggestion is to have a [Cancel] button for the edit action that would take up the available space.

Actual result

  • offset from the toggle button is kept leaving an empty space in front of the path/filter;

Regression range

  • not a regression, only visible after implementation of bug 1580728;

Additional notes

  • attached screenshot with the issue;

I kept the left spacing so the text wouldn't jump left and right during editing and submission. Any thought @fvsch

Flags: needinfo?(florens)
Attached image xhr-breakpoints.png

I like David's idea of making the jump from input to display seamless. But there are a few challenges:

  1. I'm not sure it works well with our input design with the edge-to-edge border, because it leaves a ~40px blank on the left and users may think something is wrong or read it as "the input contains spaces".

  2. To be seamless we would have to be a bit more precise with our element sizing and alignment, for instance we would need to create a kind of column track for the checkbox (whose size can vary depending on the OS, e.g. 13px wide on macOS, 14px on Windows and 16px on Linux), make sure line and input height are the same with vertically centered text, and we would need to use the same font (right now we have a monospace font for display and sans-serif in the input).

Because solving the UX issue in #1 and the technical details in #2 can be a bit hard, my recommendation would be to align with the style we have in XHR breakpoints:

  • Entries have 20px of padding-inline-start, and sans-serif text (which has the advantage of being more compact horizontally).
  • Text input stretches edge-to-edge and has 20px of padding-inline-start as well.
Flags: needinfo?(florens)

Hi David. In my patch for bug 1589961 I tweaked the spacing of blocking list rows, and to align with the XHR Breakpoints design I used padding-inline-start: 20px on the text inputs (aligning the start of the text with the start of the checkbox).

I feel that might be a more manageable option, and we gain a bit of space to type text or see more of a URL we pasted, which can be useful in a sidebar.

Can you look at the videos attached in bug 1589961, or try out the patch, and tell me if it feels right?

Flags: needinfo?(dwalsh)
Flags: needinfo?(dwalsh)

Marking verified for 72.0a1 as per checking the patches from bug 1589961.
71.0b3 still has the old design.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

Fix confirmed with 71.0b4 as well.

You need to log in before you can comment on or make changes to this bug.