Participants

Patrick Meenan, Noam Helfman, Adrian de la Rosa, Barry Pollard, Michael Wilson, Bas Schouten, Jacob Groß, Robin Marx, Nic Jansma, Yoav Weiss, Gouhei Deng, Michal Mocny,  Andy Luhrs, Philip Tellis, Joone Hur, Carine Bournez, Michelle Vu, Victor Huang,

Admin

• Feedback form on WG participation - https://docs.google.com/forms/d/e/1FAIpQLSeEZOM3txDvSN9mMR_7dMNfmhKw0imMnmgX3OlJCnloqxuwjQ/viewform?usp=header 

• How are we doing as chairs, can we make participation easier/better, etc

• TPAC is approaching!! Add topics to the agenda: https://bit.ly/webperf-tpac25 

Minutes

Expose Performance interface to AudioWorklet - PR:hr-time#169

Michael: Working on the Web Audio API which has an audio worklet.

… Seen requests for performance.now() inside the audio worklet.

… Want to discuss to see if it can be done safely and efficiently

… The Audio WG thinks it should happen, but looking for feedback

Nic: Beyond performance.now() are there other performance APIs that could be useful in Audio worklets?

Michael: Seems like developers are trying to get performance information and get timing inside the worklet

… Trying to get timing for signal processing code and how it runs

Nic: How would developers would surface this timings? Through the main page?

Michael: I’m pretty sure they want to use it inside the worklet itself

Bas: I assume that all the stuff that goes through the worklet is cross origin safe, right?

Michael: I should double check. Need to be in a secure context and there are cross origin restrictions

Bas: If you can have your signal processing code process bytes from another origin, that would be bad

… I assume that’s already the case, as there are other ways to exfiltrate

Yoav: Said developers want to use this in worklet itself

… I that they want to measure code to adapt it to machine or to some other thing, or to measure code to report measurements to server to make sure code is optimized

… For the second one, it may make sense to expose this info to main window rather than they have to postMessage to report it, or to beacon directly from the worklet

Michael: Possible they’d want to use this timing information, if processing is taking too long, switch to other version.  Or higher quality version.

… It’s not just one request for this

… From a cross-origin isolation perspective, performance.now() has different granularities when inside COI environment vs. not, what would AudioWorklet be?  Attached to document that may not be COI?

Michael: SharedArray buffer can only be used in COI context.  Some audio apps can do it, others cannot.

Yoav: For documents, depends on COI bit, but I don’t know if that exists in AudioWorklets or not.

… Something we’ll need to figure out in order to properly specify this.

NoamH: I’m not aware of a way to communicate back to main thread.  Can you postMessage() back to main thread or not?

Yoav: If current communication is not allowed, how can we make sure this isn’t a backchannel?

NoamH: If there’s a threat or vuln, that depends on timing attack, how could it be used?

Yoav: I don’t know why there isn’t a comm mechanism, I just wouldn’t want the first comm mechanism worklets could use

Bas: Certain if you have an accurate timer available, you could time CPU work and measure contention on main thread and create a backchannel.

… w/ high resolution timer, you could create a backchannel.  But there’s also existing ones.

NoamH: Is proposal to share .performance from main thread, or isolated to AudioWorklet?

Michael: Just .now(), doesn’t need to be same .performance interface as main thread.

Yoav: I think it would be useful to gather at TPAC as a breakout or joint session and talk through use-cases, get a better understanding of what they’re trying to do, so we can do it safely

… Exposing performance.now() is step 1

… Make sure whatever we build wouldn’t be inherently different between interfaces

Compression Dictionaries Error Reporting - Robin Marx / Pat Meenan

Robin: compression dictionaries allow you to compress one file relative to another

… Implementing it at Akamai and broke my setup several times

… It was unclear why it was breaking and how

… Typically only see devtools error message and no user visible error

… Some issues I ran into: add a magic header, not part of the libs

… If you dictionary compress your whole site, the whole site will go down if you have these error.

… also all JS telemetry won’t run

… NEL helps in such cases, but compression errors aren’t part of it

… Should this be part of NEL? I couldn’t find anything about this in the specs nor in Chromium code

… It’s possible that some errors (HTTP response invalid) are sent, but wanted to discuss

… Is this something we need to worry about and how can we fix it?

… Unclear if these problems are worth caring about, as they should only occur in the initial implementation phase

… Plus if all your RUM beacons go to zero, that’s an indication

… Looking into this, I found it hard to understand how NEL is implemented. Documentation would help

Pat: Haven;t looked at the spec, but MDN claims HTTP_RESPONSE_INVALID should cover improper encoding. So the browser should spit that out when there are invalid compression dictionaries

… Planning to add tests to that effect

… Original goals for NEL was to get visibility into intermittent issue. This feels borderline on that

… It’s not a middle box doing that, it’s the server messing up their deployment

Michal: No experience on compression dictionaries. I assume that if you get it wrong, it would be suboptimal

Pat: It’s like sending a binary as a response to HTML. You’d get a failure

Michal: Are there discussions on getting it more resilient?

Pat: You can’t guarantee that the requests are idempotent so you don’t want to automatically retry

… It’s like sending zstd to a browser that doesn’t support it

… It’s a problem if the browser announces it has a dictionary and the fails to use it (e.g. corruption)

NoamH: It’s easy to get it wrong so it’s important to get these errors after deployment (e.g. if someone messes up the pipeline)

… Devtools is great, but there’s still missing visibility

… So don’t know if the new NEL proposal will include something specific about the dictionaries, but it would be good.

Pat: Not sure NEL reports have a description beyond the event type

… right now improper encoding is INVALID_HTTP_RESPONSE

… We could break it out to specify different types of “invalid” failures

… But there’s no field that would enable the browser to provide more detail

Robin: can request other fields with the reports, but not sure how to get better description with the type

Barry: If you send a borked gzip file would it be reported differently? Why would this be different?

… On better resiliency, can we drop dictionaries when users reload?

Pat: INVALID should already be sent, if it’s not it’s a bug

… Chromium implementation already has more detailed code, maybe we should add encoding specific errors

… Otherwise, don’t know we want to specify force reload. Makes sense to bypass dictionary cache when the user bypasses their cache

… Needed to make sure regular reload doesn’t bypass cache. We want to align dictionaries to that

Barry: Only if you got this error.

Pat: For a local failure, it makes sense. If the origin sent a malformed response, not sure we want to throw the dictionary from the cache. You’d be hiding a problem from the origin.

Barry: full load is a recovery method

Pat: As is brotli vs. identity. You don’t turn off brotli if you get an encoding error. If the origin screwed up the implementation, not sure browsers need to work around that

… For H2,H3 we fouhgt against silent recovery mechanisms

Bas: Firefox actually never returns INVALID, but returns “error unknown”. So in Firefox you can actually get that information

… I’m not sure if the spec allows this implementation-dependant magic error codes, but I see value in it

NoamH: Is there a way to detect if there was an error without NEL?

Robin: If the HTML fails, the page just doesn’t load, so you get no signal

Barry: There seem to be mismatches between the implementations and the spec

Yoav: If we have two different implementations, we need to find a point in the middle and align the spec to that

Bas: Or a better option

Patrick: A little concerned about backwards compatibility as well, since there’s a number of endpoints receiving these already

… Would all http.reponse.invalid get grouped together or get grouped in http, or is string matching what it’s looking for

Yoav: On my end, it’s been a while since I read the NEL spec.  Worthwhile for us to set aside some time at TPAC to review.

… Encoding failures can be bad, need a way to report and be invaluable

Barry: Can we open an issue on the Github repo?

… I’ll volunteer^[a]

Bas: Firefox can trivially change, but that would lose useful info for people

Nic: Started a NEL task force and TPAC would be a good opportunity for us to move this forward

LCP #134: Intrinsic size calculation includes areas of images that are cropped out using object-fit:cover

Michal: <demo> all the images are the same size, but the blue one is LCP because of object-fit: cover and it’s larger than the others (but scaled down)

… Image that’s scaled up gets penalized by the LCP algorithm, so it takes the minimum between the intrinsic size and the visible area

… But here, the blue image has more pixels but they are not helping the user

… So maybe the intrinsic size doesn’t make sense here

… Any kind of cropping/downscaling does the same, not just object-fit

… so should we update the spec to “crop” the intrinsic size? Or is it adequate to do what we do here?

… Main issue is inconsistency

Bas: /testing in Firefox..

Michal: Looked into Chromium’s implementation. The blue square is considered 50% contentful, but the other ones are 25% contentful, but we don’t “see” that the blue square is cropped due to aspect ratio

… Another case is related to a scaled image and viewport intersection. The part of the image that’s intersecting with the viewport could be 100% contentful, but the rest of the image is scaled TODO

Barry: If we do change the behavior, we’d need to raise a change request to Interop

Michal: current test suite was forked

Barry: We can still ask for it to be considered, if we all agree

Bas: The test case here doesn’t report an LCP at all in firefox. Investigating..

NoamH: Is this specific to images in LCP? What about canvas elements?

Michal: Canvas is not considered for LCP

Yoav: I think they’re not considered

… Even images just inside of a canvas

Michal: I think this is just for images, we have issues defining sizes for vector content

… Visual size of those things and trust them to be fully contentful

… Need to investigate and see if we care enough to resolve this. Should the blue always be the LCP?

Barry: More complicated it would be if the blue is actually smaller, but calculates as bigger.

Michal: If all the squares were 1x1, the blue would have been the LCP candidate and that would be the right call

Philip: should image entropy be considered?

Michal: It’s currently a filter, but not considered for picking a candidate.