This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I don't understand how to interpret the blob: origin definition. It seems infinitely recursive. You have a URL, A. You want its origin. So you parse (Ap) it to get its scheme, then you go down the blob: path (by the way "switching" as used here isn't really English. But whatever). That tells you to take the parsed URL Ap, and get the original data, the URL A, then parse it, to get the parsed URL Ap', which is identical to Ap, and put that parsed URL object in a variable called "url". Then, it checks if that successfully parsed or not. If it didn't I don't know how you could have gotten this far, but ok. If it does, then it tells you that the origin of A is the origin of "url", that is, the origin of Ap'. Which, unless I'm missing something critical, is just the origin of A, which is what you're trying to find in the first place. I'm confused. It seems like something in this definition should defer to the File API spec's definition of the origin of the Blob object or something.
No, a URL's scheme data is what follows the scheme component (when there's no host/port/path). It's not the input string.
Then I have no idea what "Let url be the result of parsing URL's scheme data" means.
Blob URLs will start looking like this per a long debate on public-webapps: blob:http://example.org/uuid So they will always contain their origin. All of scheme data is used as a key, including the origin bit.
I think you need a note or something explaining this then. Because as written, I can't work out what the spec is trying to say.
https://github.com/whatwg/url/commit/c6cbe30f3e7d4c57850b0f4fa4ff6fd7fe22c750