Affected versions

• 71.0a1 (2019-10-21)

Affected platforms

• all

Steps to reproduce

1. Launch Firefox, access any webpage, open Netmonitor - blocking tab;
2. Block any request;
3. Repeat the previous step until the input box reaches the bottom of the area;
4. Block 1more request;

Actual result

• the input area for "Block resource when URL contains" is pushed down, out of view when more requests are added or the section is resized;

Enhancement suggestion

• the input area for "Block resource when URL contains" should become clamped to bottom and always remain visible;

Additional notes

• reviewing 1585621, 1589961 as linked to the suggestion would seem beneficial as it would be displayed, but that would mean that there would be -1 blocking pattern displayed in the list;

Good catch, thanks for the report!

Honza

Some information for anyone interested in fixing this bug:

1. The input box is rendered here:
   https://searchfox.org/mozilla-central/rev/11d9c7b7fa82fdfb8ac2a8f0864e9d8d5fe2b926/devtools/client/netmonitor/src/components/request-blocking/RequestBlockingPanel.js#194

2. Related CSS is here:
   https://searchfox.org/mozilla-central/rev/11d9c7b7fa82fdfb8ac2a8f0864e9d8d5fe2b926/devtools/client/netmonitor/src/assets/styles/RequestBlockingPanel.css#147,152,156

Honza

@Nicolas, I know the Console panel is doing the same with the command line input box.
Can you please provide some info how it's done and/or point to the code base where it's done, thanks!

Honza

If we make the input sticky, we're going to run into this use case:

1. There are more items in the list than available space, the list is scrolled to the top and the text input is fixed at the bottom.
2. User types a new pattern in the text input and hits Enter.

The new pattern would be added at the end of the list, out of view, providing no visual feedback to the user. Users may think that it's not working, try a few times, etc.

A workaround would need to automatically scroll to the bottom when adding a new pattern from the text input.

Another possibility is to reverse the list (latest pattern first), and to make the text input fixed at the top. But I don't think we're using that style anywhere.

We can try to use overflow-anchor, but it needs to be "activated" by scrolling at least once.
Could we have the input always at the very bottom of the list (not using sticky) ?

┌──────────────────────────────────┐
│      Search          Blocking    │
├──────────────────────────────────┤
│   ✔️ Enable Request Blocking  +   │
├──────────────────────────────────┤
│               blah               │
├──────────────────────────────────┤
│               bleh               │
├──────────────────────────────────┤
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
├──────────────────────────────────┤
│ Block resource when URL contains │
└──────────────────────────────────┘

or at the very top?

┌──────────────────────────────────┐
│      Search          Blocking    │
├──────────────────────────────────┤
│   ✔️ Enable Request Blocking  +   │
├──────────────────────────────────┤
│ Block resource when URL contains │
├──────────────────────────────────┤
│               blah               │
├──────────────────────────────────┤
│               bleh               │
├──────────────────────────────────┤
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
│                                  │
└──────────────────────────────────┘

IMO this would be much easier that trying to have pin to bottom feature.

(In reply to Florens Verschelde :fvsch from comment #4)

A workaround would need to automatically scroll to the bottom when adding a new pattern from the text input.

I like this and it would be consistent with how the Console panel works.

Honza

Could we have the input always at the very bottom of the list (not using sticky) ?

Personally I'm against it because it's easy to just not see the input when it appears 200-400px away from the blocking panel's content.

I think I have a pure CSS solution using Flexbox.
We don't use it in the Console because the jsterm has a dynamic height, but here the text input has a fixed height so we can use that.

/* RequestBlockingPanel.css | chrome://devtools/content/netmonitor/src/assets/styles/RequestBlockingPanel.css */

.request-blocking-contents {
  /* overflow-y: auto; */
  overflow: hidden;
  display: flex;
  flex-direction: column;
}

.network-monitor .request-blocking-list {
  max-height: calc(100% - 25px);
  overflow-y: auto;
}

We may need to test it more, but it seemed to work well in my quick test.

This also lets us hide the bottom border when the input touches the bottom edge, which is a nice pixel-perfect tweak. :D

Tentatively taking this. Will unassign myself is the CSS solution doesn't pan out.

So this is working nicely with just CSS, yay \o/

My patch doesn't address this:

automatically scroll to the bottom when adding a new pattern from the text input

That seems doable with document.querySelector('.request-blocking-contents li:last-child').scrollIntoView() but we can't do it when submitting the form because we need the component to receive new props and finish rendering first, and I'm not sure how to do that.

We could delay the scrolling for a little while, e.g. 100ms, but that could be error prone?

Unless we have a good solution in mind, I'd split that autoscrolling question to a follow-up bug and not block the layout improvement on that.

We could delay the scrolling for a little while, e.g. 100ms, but that could be error prone?

Tried with a 40ms delay and it seems to work fine. See the patch.

(In reply to Florens Verschelde :fvsch from comment #12)

My patch doesn't address this:

automatically scroll to the bottom when adding a new pattern from the text input

That seems doable with document.querySelector('.request-blocking-contents li:last-child').scrollIntoView() but we can't do it when submitting the form because we need the component to receive new props and finish rendering first, and I'm not sure how to do that.

We could delay the scrolling for a little while, e.g. 100ms, but that could be error prone?

Unless we have a good solution in mind, I'd split that autoscrolling question to a follow-up bug and not block the layout improvement on that.

David, do you have any tips about how to solve this?
Honza

I ended up finding a solution, see scrollToBottom here:
https://phabricator.services.mozilla.com/D51135#change-zFpEJ8FYrXss

https://hg.mozilla.org/mozilla-central/rev/2f2781fe9777

Verified with 75.0a1 (2020-02-24) on Windows 10, macOS 10.15, Ubuntu 19.04.
Awesome work with making this happen!