Bugzilla

Some more analysis of the APIs:

> - `browser.devtools.panels.network.select(...).then((selectedHARRequest) => {...})`

Another question is related to arguments passed to the `select` function. It should be flexible enough, so it can be used to identify the request to be selected using various metrics.

- URL (but there can be more requests with the same URL)
- startDateTime
- HTTP header
- etc. (anything from HAR)

Since it can be basically anything that is collected in HAR - the structure could follow the HAR spec. So, if the user passes directly a HAR entry [1] it should select the right request in the list.

[1] http://janodvarko.cz/blog/har-12-spec/#entries

What Tony sketched in comment #4 - already corresponds to the HAR spec (I just removed the `select` prop).

Some examples:


#1) Select a request by URL
```js
devtools.network.inspect('https://www.mozilla.org');
```

#2) Select a request by URL and startDateTime
```js
devtools.network.inspect('https://www.mozilla.org', {
    startedDateTime: '2019-05-09T12:26:26.672-05:00'
});
```

#3) Select a request by URL and HTTP header
```js
devtools.network.inspect('https://www.mozilla.org', {
    response: {
        headers: [{
          "name": "my-header",
          "value": "specific value"
        }]
    }
});
```

Notes:
- In case there are more requests matching the provided props - the first one would be selected.
- If there is no matching request, the panel should still be selected and there might be an optional UI feedback (an error/warning message) informing the user that specified request doesn't exist. 
- The first argument is a bit redundant, since the URL is also presented in HAR and could be passed in through the second argument. But, it feels like URL will mostly be used and it simplify the API.
- If HTTP header is used - the Network panel can optionally select the right side panel and perhaps even highlight the right header. The same applies on Cookies, URL Query parameters, etc.

As a future step, we could also support an existing JSON query language that could allow e.g.: selecting all requests that started in specific time range. Such thing would be possible without changing the API design itself.

Honza

Some more analysis of the APIs:

> - `browser.devtools.panels.network.select(...).then((selectedHARRequest) => {...})`

Another question is related to arguments passed to the `select` function. It should be flexible enough, so it can be used to identify the request to be selected using various metrics.

- URL (but there can be more requests with the same URL)
- startDateTime
- HTTP header
- etc. (anything from HAR)

Since it can be basically anything that is collected in HAR - the structure could follow the HAR spec. So, if the user passes directly a HAR entry [1] it should select the right request in the list.

[1] http://janodvarko.cz/blog/har-12-spec/#entries

What Tony sketched in comment #4 - already corresponds to the HAR spec (I just removed the `select` prop).

Some examples:


#1) Select a request by URL
```js
devtools.network.inspect('https://www.mozilla.org');
```

#2) Select a request by URL and startDateTime
```js
devtools.network.inspect('https://www.mozilla.org', {
    startedDateTime: '2019-05-09T12:26:26.672-05:00'
});
```

#3) Select a request by URL and HTTP header
```js
devtools.network.inspect('https://www.mozilla.org', {
    response: {
        headers: [{
          "name": "my-header",
          "value": "specific value"
        }]
    }
});
```

Notes:
- In case there are more requests matching the provided props - the first one would be selected. Or all of them if multiselection is supported.
- If there is no matching request, the panel should still be selected and there might be an optional UI feedback (an error/warning message) informing the user that specified request doesn't exist. 
- The first argument is a bit redundant, since the URL is also presented in HAR and could be passed in through the second argument. But, it feels like URL will mostly be used and it simplify the API.
- If HTTP header is used - the Network panel can optionally select the right side panel and perhaps even highlight the right header. The same applies on Cookies, URL Query parameters, etc.

As a future step, we could also support an existing JSON query language that could allow e.g.: selecting all requests that started in specific time range. Such thing would be possible without changing the API design itself.

Honza

Some more analysis of the APIs:

> - `browser.devtools.panels.network.select(...).then((selectedHARRequest) => {...})`

Another question is related to arguments passed to the `select` function. It should be flexible enough, so it can be used to identify the request to be selected using various metrics.

- URL (but there can be more requests with the same URL)
- startDateTime
- HTTP header
- etc. (anything from HAR)

Since it can be basically anything that is collected in HAR - the structure could follow the HAR spec. So, if the user passes directly a HAR entry [1] it should select the right request in the list.

[1] http://janodvarko.cz/blog/har-12-spec/#entries

What Tony sketched in comment #4 - already corresponds to the HAR spec (I just removed the `select` prop).

Some examples:


#1) Select a request by URL
```js
devtools.network.select('https://www.mozilla.org');
```

#2) Select a request by URL and startDateTime
```js
devtools.network.select('https://www.mozilla.org', {
    startedDateTime: '2019-05-09T12:26:26.672-05:00'
});
```

#3) Select a request by URL and HTTP header
```js
devtools.network.select('https://www.mozilla.org', {
    response: {
        headers: [{
          "name": "my-header",
          "value": "specific value"
        }]
    }
});
```

Notes:
- In case there are more requests matching the provided props - the first one would be selected. Or all of them if multiselection is supported.
- If there is no matching request, the panel should still be selected and there might be an optional UI feedback (an error/warning message) informing the user that specified request doesn't exist. 
- The first argument is a bit redundant, since the URL is also presented in HAR and could be passed in through the second argument. But, it feels like URL will mostly be used and it simplify the API.
- If HTTP header is used - the Network panel can optionally select the right side panel and perhaps even highlight the right header. The same applies on Cookies, URL Query parameters, etc.

As a future step, we could also support an existing JSON query language that could allow e.g.: selecting all requests that started in specific time range. Such thing would be possible without changing the API design itself.

Honza