Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Explore turning on recording mode as soon as dev tools panel is shown #229

Open
alvarlagerlof opened this issue Aug 13, 2023 · 4 comments
Open

Explore turning on recording mode as soon as dev tools panel is shown #229

alvarlagerlof opened this issue Aug 13, 2023 · 4 comments

Comments

@alvarlagerlof
Copy link
Owner

Problem

#195 added some safety to reduce the risk that the extension blows up any page (by patching fetch potentially incorrectly9), but does so by adding a recording mode. You have to press it after loading your page to start seeing RSC chunk data coming in. This makes it hard to see prefetching responses.

Proposed solution

The extension could start recording automatically as soon as it is shown to the user. See https://twitter.com/nickemccurdy/status/1690111061142155264
@0xdevalias
Copy link

0xdevalias commented May 23, 2024 •
edited
Loading

I just came here to raise a similar issue; but I was wondering if it would make sense to have a similar mode as the Chrome DevTools 'Performance' tab, where it has a 'reload and start recording' button.

image

I haven't looked at the current method of patching fetch too deeply; but I also wonder if there are better 'higher level' extension API's that can be used, rather than monkeypatching fetch?

From memory, I believe it's not possible to get the response body with chrome.webRequest, but I think it might be possible via chrome.debugger.

I haven't deeply validated this, but here's what ChatGPT suggested for it:

chrome.debugger example

Capturing the response body directly with the chrome.webRequest API in a Chrome extension is not straightforward, as the API does not provide direct access to the body of HTTP responses. However, you can achieve this using the chrome.debugger API, which allows you to attach to the browser's debugging protocol and capture network traffic, including response bodies.

Here’s how you can set up a Chrome extension to capture the response body using the chrome.debugger API:

  1. Manifest file (manifest.json):
    Ensure your manifest file includes the necessary permissions and declares the background service worker:

    {
  "manifest_version": 3,
  "name": "Response Body Capturer",
  "version": "1.0",
  "permissions": [
    "debugger",
    "activeTab"
  ],
  "background": {
    "service_worker": "background.js"
  },
  "action": {
    "default_popup": "popup.html"
  }
}

  2. Popup HTML (popup.html):
    Create a simple popup to start capturing:

    <!DOCTYPE html>
<html>
<head>
  <title>Start Capture</title>
</head>
<body>
  <button id="startCapture">Start Capture</button>
  <script src="popup.js"></script>
</body>
</html>

  3. Popup Script (popup.js):
    Add a script to handle the button click and start the debugger:

    document.getElementById('startCapture').addEventListener('click', function() {
  chrome.tabs.query({ active: true, currentWindow: true }, function(tabs) {
    chrome.debugger.attach({ tabId: tabs[0].id }, '1.3', function() {
      chrome.debugger.sendCommand({ tabId: tabs[0].id }, 'Network.enable');
      chrome.debugger.onEvent.addListener(function(debuggeeId, message, params) {
        if (message === 'Network.responseReceived') {
          chrome.debugger.sendCommand(
            { tabId: tabs[0].id },
            'Network.getResponseBody',
            { requestId: params.requestId },
            function(response) {
              console.log('Response body:', response.body);
            }
          );
        }
      });
    });
  });
});

  4. Background Script (background.js):
    No changes needed in the background script for this example.

  5. Loading the extension:

    • Go to chrome://extensions/.
    • Enable "Developer mode".
    • Click "Load unpacked" and select the directory containing your manifest.json, popup.html, and popup.js files.

With this setup, the extension will attach to the browser's debugger protocol when you click the "Start Capture" button in the popup. It will then listen for network responses and capture the response bodies.

Important Notes:

  • Using the chrome.debugger API requires user interaction (e.g., clicking a button in the popup) to start the debugger.
  • The chrome.debugger API has powerful capabilities and should be used carefully, as it can interfere with normal browser operations.
  • Ensure you comply with Chrome Web Store policies and user privacy considerations when capturing network traffic.

There's also chrome.devtools.network, which might be useful?

There might be other useful Chrome extension API's as well, it's been a while since I looked deeply through them.

As a workaround in the meantime, you could try setting a breakpoint in the 'Sources' tab -> Event listener breakpoints -> DOM mutation -> DOMContentLoaded:

Then while the code is paused, click the 'record' button in RSC DevTools, and then unpause the code again.

@alvarlagerlof
Copy link
Owner Author

Copying the behaviour of the Chrome DevTools seems like a good idea UX wise. I like it.

Using chrome.webRequest does not let you get a streaming response. Only the full response, so it's not as featured. I wanted to use that originally, but hit a wall. I believe that the equivalent API does have support for streaming in Firefox. The chrome.devtools.network has the same problem.

The debugger example looks to have the same problem. While I don't understand what Network.getResponseBody' is referring to, it does not seem to be a stream either.

Really the main thing that needs to keep working is streaming support.

@0xdevalias
Copy link

0xdevalias commented May 23, 2024 •
edited
Loading

While I don't understand what Network.getResponseBody' is referring to, it does not seem to be a stream either.

I believe it's referring to the chrome devtools protocol:

Specifically:

Not sure which part emits this; but the description on it certainly reads in a potentially stream friendly way:

It might just be part of this:

And even the description of response on this says 'bytes received so far':

So sounds like there may be some bits worth PoC'ing with/exploring in there at the very least.

@alvarlagerlof
Copy link
Owner Author

Huh, yeah that seems like it might just work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@0xdevalias @alvarlagerlof