I took a WR capture from a 32-bit android/geckoview build and then tried to replay it with wrench built on my Linux (64-bit) host. In the capture, there is a clip_id: Clip(4294967295, (0, 0)) where that number is the 32-bit value of !0 (because usize is 32 bits). When I load it, it gets checked against the 64-bit value of !0 here (because usize is 64 bits now) and so it gets treated as "valid" instead of "invalid" and then panics later.

Currently (non-chain)ClipId's and SpatialIds are both usizes, and this seems like an error to me. We should either mandate u64 (safe) or drop them down to u32 (compact).

Since I'm refactoring all this code in Bug 1544979 anyway, I'm just going to go forward with making them u64's, but also making it a type alias so we can change to u32 in the future if we ever find it compelling to do so.

not working on this anymore, see https://bugzilla.mozilla.org/show_bug.cgi?id=1544979#c7