Participants

Yoav Weiss, Nic Jansma, Alex Christensen, Annie Sullivan, Benjamin De Kosnik, Carine Bournez, Dan Shappir, Michal Mocny, Patrick Meenan, Scott Gifford, Katie Sylor-Miller, Paul Calvano, Sean Feng

Minutes

Misc

CFCs

• Yoav: CfCs have been sent out, please have AC reps review
• Scott: How does voting process work?
• Yoav: Assuming AC reps don’t have objections, +1 on issue or comment
• … If AC has concerns around adopting work, please provide a more formal comment on objections
• Carine: We also had 2 new CR snapshots out today (User Timing and Performance Timeline)
• … Call for exclusions should follow, AFAIK

Next Meeting

• Yoav: Do we want to meet on the week of the 13th?  Conflicts on regular 16th day?  Or just meet in 2022?
• Nic: January 13th 2022 would be the next meeting

Cross-frame performance timeline proposal (Ian Clelland)

• Ian: PerformanceTimeline API has a glaring problem, we spoke with a few analytics providers
• … Web pages are made with frames, we don’t allow crossing that boundary for cross-origins
• … Huge blindspot for this API
• … Don’t know if IFRAME is causing a stall in loading, failing to load, bad UX
• … Can work around this with custom script, but you need to control the frames on all origins
• … Possible way to improve this if the child frame agrees
• … Report events up to main frame if so
• … Opt-in is critical
• … Can we do this in a standard way that doesn’t require custom script on child frame
• … Doc shared: https://docs.google.com/document/u/1/d/1LbXafcZMHagLReSkEkjhQdOIzeA9RS8_2e0_g5QLgY0/edit?resourcekey=0-n9hTSQXGoyboIssA4wSGGw
• … Proposes a solution to this
• … Embedded site has to opt in, sufficient to allow sharing
• … Embedding site has to request entries from child frames so we don’t break existing code
• … Can distinguish subframes from the main page
• … Would like to allow a header to do this.  Don’t want to extend Timing-Allow-Origin to frames
• … Could have Performance-Allow-Origin to opt-in origins
• … To avoid minting a new header, use Document-Policy, “share-performance-timeline-with=*”
• … Opt-in specific origins or all with wildcard
• … Extend PerformanceObserver methods to have a “includeFrames” boolean
• … You’d start getting PerformanceTimeline events from all child frames that have opted in
• … In response, when you start getting these events, get a reference to the frame
• … Could include index for frame from top, but two are equivalent
• … Could postMessage to it
• … “source” object in PerformanceEntry IDL
• … End of presentation
• Discussion:
• Yoav: Window reference would be a weak reference that wouldn’t hold it alive
• Ian: Agreed.  Shouldn’t keep it alive.
• Yoav: To not maintain frames forever
• Dan: Weak reference or only created when object is requested?
• Ian: what would be the practical effect?
• Dan: Similar to the LCP entries, where the attribute is null when the element is not longer there.
• Ian: What happens if you query it, but then keep that reference?
• Dan: Not sure. Windows are heavy so preventing them from GC would be problematic
• … Comment - something to consider about the terms you use in the header. They lack the semantics of indicating it’s an iframe container relationship
• … You say you’re share with an origin, but not saying that it’s the embedder
• … Another thought - can we indicate this in the HTML itself (e.g. for the CDN case)
• Ian: Might be possible. Document Policy doesn’t currently support it, but maybe we should
• … Need to make sure that it’s not a privacy issue that would result in script access being able to share the iframes timing. At the same time, a script in the frame can already coordinate exfiltration of the data, so not a big risk
• Dan: So an embedded script that can modify the meta tag can also communicate the same with the parent?
• Ian: Yeah
• Yoav: Client Hints is looking into a similar option, since Document Policy doesn’t support it.  Has to be markup over the wire
• … Could be middle ground vs enabling for dynamic scripts
• Ian: Initial privacy issue around this, where sub-frame and top-frame see with timeOrigin
• … Entries may need to be transformed along the way w/ parent
• … timeOrigin and maybe coordinates (LayoutShift)
• Dan: timeOrigin you need to sync, coordinates maybe not
• Ian: Thinking about LayoutShift entries, reporting from child frame, reports on where it is in the frame
• Dan: timeOrigin you wouldn’t be able to figure it out
• Nic: From our request for this, this would be helpful for RUM in many ways. Excited for this
• … Time origin would be critical, because we’d want to coordinate resources on the performance timeline with the top-level origin
• … Haven’t considered coordinates
• Scott: What’s the behavior if we don’t have permissions. Can we have an entry that tells us there’s a frame which doesn’t expose the entries
• Ian: You’d be able to know by not having an entry
• Scott: How can we know that 3P frames haven’t opted in?
• Ian: I think it’s technically possible, but may be worthwhile to add that as a more ergonomic option
• Katie: A lot of times with 3P code, it’s a marketing person that adds a tag without understanding performance, etc. So ergonomically it’d be difficult as we’d run into problems with 3P not willing to expose their timings, to avoid embedders that know their perf characteristics
• Ian: We could have a permission policy that requires an opt in, but that may not be an easy sell
• Alex: This definitely reveals new information that has a use, but has anyone looked into ways this could be abused/misused and expose information we didn’t want to reveal
• … e.g. ad vendor that would expose their information, but can reveal info about the user
• … tempting to use the * config, which would be revealing info to any origin
• … have we considered mis-use?
• Ian: Anyone adding the header should think about it. Should we enumerate concerns in the spec?
• Alex: We might have a reason to say: “*” is not allowed, so you can expose this to specific origins
• Dan: The issue with not allowing “*” it means that it becomes useless for things like marketing pixels, as it’s unlikely they’d add specific origins. But they may not opt-in at all.
• Ian: The “*” is there as an equivalent to TAO
• Scott: We always use “*” for TAO, mostly with static assets, because of caching.
• … Because of the CDN, if we don’t support *, we need to make sure the responses can be cached
• Ian: We’d need some negotiation mechanism where JS has to make this decision
• Scott: If a major use case is for embedded iframes by a third party (e.g. advertiser), we should makes sure the mechanism where the embedder can enforce instrumentation on the child frames is clear, either explicitly (e.g. tell the browser “don’t load this if it doesn’t have instrumentation”) or by data gathering (e.g. a clear signal that the child iframe has not added timing headers, so the parent could emit that in a metric and later decide to take some action (de-prioritize putting it onto page, send an alarm/notification, etc.)).
• Ian: I think that not having * would likely significantly reduce the applicability of this.

Cross-frame performance timeline

• Problem: PerformanceTimeline API (for good reasons) does not observe events which occur in other frames, and *cannot* observe events from cross-origin frames. This is a real problem for anyone trying to perform full-page performance analysis.
• Proposed solution: Allow embedded pages to opt in with an HTTP header to having their performance events observed by their embedders. Performance Timeline APIs are modified to allow embedders to request such events.
• Discussion points:

• Would a window reference to a child frame be a weak or strong reference?

• Weak references would allow GC of destroyed windows.

• Is an HTTP header necessary, or can pages opt-in with markup only?

• Need to investigate; markup may be possible, but don't want to create security issues.

• Is it possible to feature-detect this?

• Yes, technically (look for navigation events from child frames loading), but maybe something more explicit is better.

• Do performance entries need to be transformed from child to parent frame, to avoid additional cross-origin leaks?
• Can we enumerate the potential privacy issues so that people opting in fully understand any risks?

• We should do our best here, recognizing that we might not be able to be exhaustive.

• Should we disallow '*' as an option, and require embedded frames to specify which origins can read from them?

• This would probably break major use cases; '*' is a parallel with Timing-Allow-Origin, where it is widely used.

Beaconing Improvement Proposal (Ian Clelland)

• Ian: Early proposal for a new page unload beacon
• … We have beaconing already from navigator.sendBeacon, unload handlers with sync/async XHR
• … All methods are rather unreliable
• … Nic’s gone through reliability of things and figuring out why
• … Unreliable due to crashes, shutdown, unreliable networks
• … Unload is ignored by some browsers, behavior blocked by some
• … Unload makes bfcache ineligible
• … Call for reliable way to send data out at the end of the session
• … Propose a new way to do this on Reporting API
• … Automatically sent out of band from browser
• … Register data, stored by browser up to point where it should go out
• … “End of session” unclear as page-hide or unload or arbitrary marker for when page is done, so at point page is unloaded from browser, that’s when to send beacons
• … Register once and forget
• … Ability to update data in beacon, cancel data if needed, maybe send immediately
• … Using Reporting API as foundation for this means you have a Reporting-Endpoints header
• … Different ways of registering for beacons
• … Marking-based solution
• 
• … Endpoint and payload are specified, possibly timeline types
• … Could be useful to compress because it could be a lot of data
• … Having this link in the HEAD would be enough to register for beacon
• … Data would be stored and sent out when page is tearing down
• … Use DOM APIs to manipulate from script
• … Grab out of DOM to change the payload or remove to cancel it
• … Second proposal is JS-based solution
• 
• … Give it a way to queue up a beacon, register a report with payload
• … Advantages to do this in script, not everyone has access or willing to change markup
• … Could register ReportingObserver
• … This example has a 5 minute timeout, that ReportingObserver would be able to see
• … Can update
• 
• … Last of my slides
• … Still trying to figure out what use-cases are
• … Wondering which shape would be more useful
• ... Would love feedback on that
• [end of presentation]
• Dan: At WIX, we try to send sendBeacon during “unload” (use pagehide etc instead)
• … Seems some of the things you mention, i.e. out-of-band, are desirable for sendBeacon in general and not just this
• … Why not have sendBeacon be out-of-band
• … Another comment is that compression of upload, sendBeacon is restricted to smaller uploads
• … Being able to compress stuff being sent is a general feature, not just for this proposal, why not control compression on upload in general?
• … Can you guarantee on every platform, you’re able to hook into end-of-session, will you be able to hook into that?
• Ian: We should absolutely do what we can to make sendBeacon more reliable, no reason it shouldn’t be out-of-band.  Maybe because it’s defined in terms of Fetch?  If there are things we can do to make sendBeacon more reliable, we should
• … Has fundamental limits that you need script running at the time the beacon goes out, because unload handlers don’t run
• … Advantage of this is it’s an explicitly queued and delayed beacon
• Yoav: One more point is you can update it over time, instead of sending 20 beacons, you could just send one at the end
• Dan: Currently report CLS multiple times because we can’t be sure it’s the end of the session
• … Just that a lot of the things you spec here are desirable in other scenarios as well
• … Can you guarantee that this will be sent?
• Ian: Never an absolute guarantee
• Dan: If guarantee is weak, I might feel safer sending multiple beacons during lifetime of page instead of hoping it’s sent at the end
• Ian: Hopefully that this proposal is just as reliable as that
• Ian: Nic filed an issue with sendBeacon to allow compression (https://github.com/w3c/beacon/issues/72)
• Yoav: Talked to Katie earlier today, mentioned desire to process information from performance APIs in a worker or non-main-thread context, and as you were presenting that JS API has an advantage on that front, is we could expose in workers, and just postMessage() whatever we want from APIs to worker.
• … Register report there instead of marshalling to DOM API
• … Significant advantage
• Katie: Add that we’ve run into a problem over years, that JavaScript measuring the performance of JavaScript, that when we change it, it can change the baseline
• … Hard to know if when something’s changed, whether it’s the feature or the measurements causing the change
• … Thinking if we can move things off the main thread
• … Similar to Dan that working to get rid of all unload beacons, and whatever happens is it’ll be used by things that are not just performance entries
• … Have a bunch of places where we send non-perf data in XHR on unload, because it’s always been the most reliable way to get this data
• … Anything that’s more reliable for any time of beacon may end up solving that problem for unload handlers, not just perf data
• Ian: Would that be an argument for not hanging this off performance API, but maybe navigator.queueBeacon.
• Katie: Yes potentially, about reliability of sendBeacon, it’s been difficult for me to prove there’s value for removing unload handlers, and you can’t experimentally prove that did anything because you have to remove all of them
• … Could go to engineers and say there’s this new browser API that’s more reliable for you
• Ian: For Nic and Yoav then, if we did that, is it under this working group still
• Yoav: From my perspective it wouldn’t affect what we deliver
• Nic: Would really help all the RUM stuff we’re doing. In our case, we’d like the JS API.
• … thinking about the DOM api, one challenge with allowing the DOM to say “include performance entries for restiming, navtiming, etc” is that it would then be up to the OOB process to get that data from the possibly-unloading render process.  Might not work.
• Ian: That would complicate things. Capturing the timeline data OOB would require marshaling constantly
• Nic: Otherwise, queueing up the beacon would require everything to be all set

Beaconing improvement proposal

• Problem: Existing end-of-session beaconing techniques are unreliable, for a number of reasons (Crashes, unreliable networks, or browsers just ignore them) and unload handlers make pages uneligible for bfcache.
• Would like to come up with a reliable end-of-session beacon, caching the data in the browser and using the Reporting API to send it when the page is unloaded.
• Two solutions proposed:

• <link rel="beacon"> in DOM
• Extend window.performance with JS methods to queue, update and send beacons.

• Discussion points:

• Could we improve sendBeacon instead?

• Yes, we should improve sendBeacon, but it's fundamentally a fire-now API. This is a queue-for-later API.

• Can we make real guarantees with this API?

• Probably not, for technical and privacy reasons.

• Can this work from workers?

• We could; this would be support for a JS API over a DOM one

• Could this be navigator.queueBeacon instead?

• Yes.

• Could it automatically include unread performance timeline entries?

• Maybe; that might interfere with the goal of having data queued in the browser process.

ElementTiming Discussion

• Yoav: At TPAC, we talked about ElementTiming as part of discussion on adopting incubations
• … Anne discussed previous concerns from Apple he wanted information on, but we didn’t have on the call
• … Was wondering Alex if we have more information about previous concerns around ElementTiming
• Alex: Not on hand, but I could look them up
• … Can you send more information on exactly what you’re looking for?
• Benjamin: If there are more issues, if they’re confined to just text elements or just image elements, could the objection be partitioned, if there is one
• Yoav: For ElementTiming, which exposes timing information on when certain things are painted to screen, the element could be an image or text element.  Could the feedback be split based on those characteristics?
• Benjamin: If the objections are around text, i.e. we can’t find text bounding box?  Or if you don’t have objections around image size?
• Yoav: I can link to minutes from TPAC discussion, where we talked previously

• https://docs.google.com/document/d/1GQpM8IvL4feXQ0oQdCQIPKhZZkMLNTYJQhBUntMxPkI/edit#heading=h.glex7ka68pwu

• … Maybe take an AI to get back to us when we can discuss further
• Benjamin: Would this be useful to be resolved before CfC deadline
• Yoav: CfC is not about ElementTiming, it’s just for LCP and EventTiming.  ElementTiming wasn’t included

Admin

• Skipping the next call and the 30th, we’ll meet again on January 16th