public/browser
1
0
Fork 0
mirror of https://github.com/lightpanda-io/browser.git synced 2025-10-29 23:23:28 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Make CDP server more authoritative with respect to IDs

Browse Source 
The TL;DR is that this commit enforces the use of correct IDs, introduces a
BrowserContext, and adds some CDP tests.

These are the ids we need to be aware of when talking about CDP:
- id
- browserContextId
- targetId
- sessionId
- loaderId
- frameId

The `id` is the only one that _should_ originate from the driver. It's attached
to most messages and it's how we maintain a request -> response flow: when
the server responds to a specific message, it echo's back the id from the
requested message. (As opposed to out-of-band events sent from the server which
won't have an `id`). When I say "id" from this point forward, I mean every id
except for this req->res id.

Every other id is created by the browser.

Prior to this commit, we didn't really check incoming ids from the driver. If
the driver said "attachToTarget" and included a targetId, we just assumed that
this was the current targetId. This was aided by the fact that we only used
hard-coded IDS. If _we_ only "create" a frameId of "FRAME-1", then it's tempting
to think the driver will only ever send a frameId of "FRAME-1".

The issue with this approach is that _if_ the browser and driver fall out of sync
and there's only ever 1 browserContextId, 1 sessionId and 1 frameId, it's not
impossible to imagine cases where we behave on the thing.

Imagine this flow:
- Driver asks for a new BrowserContext
- Browser says OK, your browserContextId is 1
- Driver, for whatever reason, says close browserContextId 2
- Browser says, OK, but it doesn't check the id and just closes the only
  BrowserContext it knows about (which is 1)

By both re-using the same hard-coded ids, and not verifying that the ids sent
from the client correspond to the correct ids, any issues are going to be hard
to debug.

Currently LOADER_ID and FRAEM_ID are still hard-coded. Baby steps.
This commit is contained in:
Karl Seguin
2025-02-26 09:33:50 +08:00
committed by Pierre Tachoire
parent ccacac0597
commit a3e2b5246e
17 changed files with 1128 additions and 591 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
src/id.zig
View File

@@ -9,7 +9,7 @@ const std = @import("std");
// - while incrementor is valid
// - until the next call to next()
// On the positive, it's zero allocation
fn Incrementing(comptime T: type, comptime prefix: []const u8) type {
pub fn Incrementing(comptime T: type, comptime prefix: []const u8) type {
// +1 for the '-' separator
const NUMERIC_START = prefix.len + 1;
const MAX_BYTES = NUMERIC_START + switch (T) {
@@ -35,15 +35,15 @@ fn Incrementing(comptime T: type, comptime prefix: []const u8) type {
const PREFIX_INT_CODE: PrefixIntType = @bitCast(buffer[0..NUMERIC_START].*);
return struct {
current: T = 0,
counter: T = 0,
buffer: [MAX_BYTES]u8 = buffer,
const Self = @This();
pub fn next(self: *Self) []const u8 {
const current = self.current;
const n = current +% 1;
defer self.current = n;
const counter = self.counter;
const n = counter +% 1;
defer self.counter = n;
const size = std.fmt.formatIntBuf(self.buffer[NUMERIC_START..], n, 10, .lower, .{});
return self.buffer[0 .. NUMERIC_START + size];
@@ -106,7 +106,7 @@ test "id: Incrementing.next" {
try testing.expectEqualStrings("IDX-3", id.next());
// force a wrap
id.current = 65533;
id.counter = 65533;
try testing.expectEqualStrings("IDX-65534", id.next());
try testing.expectEqualStrings("IDX-65535", id.next());
try testing.expectEqualStrings("IDX-0", id.next());