Netmonitor blocking - remove text offset in text-box when editing request filters
Categories
(DevTools :: Netmonitor, enhancement, P3)
Tracking
(firefox70 unaffected, firefox71 verified, firefox72 verified)
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
- Launch Firefox;
- (if not already)Set devtools.netmonitor.features.requestBlocking to true;
- Access any webpage, open the DevTools inspector - Network tab;
- Block any request so that the Blocking UI is enabled;
- In the Request blocking section set any filter and (double) click on it to make it ediable;
Expected result
- text should expand over all the available area in the text-box;
- 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;
Updated•5 years ago
|
Comment 1•5 years ago
|
||
I kept the left spacing so the text wouldn't jump left and right during editing and submission. Any thought @fvsch
Comment 2•5 years ago
|
||
I like David's idea of making the jump from input to display seamless. But there are a few challenges:
-
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".
-
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.
Comment 3•5 years ago
|
||
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?
Updated•5 years ago
|
Reporter | ||
Comment 4•5 years ago
|
||
Marking verified for 72.0a1 as per checking the patches from bug 1589961.
71.0b3 still has the old design.
Reporter | ||
Comment 5•5 years ago
|
||
Fix confirmed with 71.0b4 as well.
Description
•