Participants: Philippe Le Hegaret, Yoav Weiss, Philip Walton, Annie Sullivan, Steven Bougon, Andrew Comminos, Ryosuke Niwa
Next call: Feb 13th, 10am PST
Andrew: Continuing from last week. Talked about the security implications of differences between hit tests, and the approach different UAs take towards it
Yoav: Can’t we perform hit-testing once, or mandate that both hit tests match? Chrome security folks don’t think the information is highly-exploitable, but blocking the race condition sounds like a better option.
Andrew: locking event to origin may leak information in itself, The frame that received the initial isInputPending and no event could infer the event was dispatched to another frame
Yoav: That’s the leak in the current implementation. In the single hit-test case, you’d get the event even in case your iframe moved. In the other option, you’d get isInputPending but no event, in which case you know you have an event that was supposed to arrive, but someone moved your frame.
Andrew: Is “event should have been dispatched?” cross-origin information that we don’t want to leak
Yoav: The information “leaks” to same-origin in which the event should have been dispatched
Andrew: depends on how you define “should have”
Yoav: Agree
AI - discuss 3 options as part of a TAG review
Ryosuke: discarding the event in case of a mismatch sounds risky.
Andrew: changes hit testing expectations, so agree
Ryosuke: what about doing hit testing once? That sounds low risk. If anything, improves the synchronization between user click and event. Seems preferable
Andrew: now to spec changes.
… Using DOM event types wasn’t ideal.
Initially provided a list of DOM events, because we wanted to provide UAs a way to avoid continuous events (mouse move, etc).
… That turned out hard to spec out, because implementations don’t really match and spec that,
… Tried to solve this problem by picking the right set of events, which works other than a few edge cases
… Primary objective was to focus on discrete events rather than continuous
… So we need to define what is “continuous events”, and expect most users to not be interested, but want to continue to expose this information
Philippe: there’s work that the pointer events folks do on that front. Need to be aware of getCoalescedEvents/getPredictedEvents In Pointer Events 3.
Yoav: Also Event Timing
Andrew: working with Nicolás and want to unify the definition between this and EventTiming.
Yoav: will also unify with other WG if makes sense
Andrew: Moving on to IDL. IDL uses an Options struct which is more efficient to call this frequently.
… The original implementation resulted in many string comparisons so it was expensive.
… The idea is that if you want to track continuous events you add that as a boolean.
Yoav: Makes sense.
Ryosuke: why support continuous events at all?
Andrew: use case could be a game that reacts to mouse moves. Won’t oppose shipping just UI events if that’s better.
Ryosuke: definition of continuous events should be in HTML or UI events spec. Would be better to define it elsewhere. There could also be sub-categories (e.g. touch events, mouse events).
Andrew: starting from a small set of options makes sense
Ryosuke: also need to make sure it’s implementable so it's easier to start small.
Philippe: sounds like there’s overlap with Pointer Events
Andrew: will file an issue on GH to track that (https://github.com/WICG/is-input-pending/issues/24)
Philip: There are many use cases where developers want a reliable signal that a user is about to leave the page (switching tabs, switching apps, etc).
… There are a lot of situations where you’re trying to run some idle code, which is not urgent but needs to run before the user leaves.
… Unload, pagehide and beforeunload are not reliable, especially on mobile. Visibility change has been *the* event to solve this for a while.
… More recently I’ve been working with people at Google on that use case. But there are a bunch of issues in different OSes and the issue is around ambiguity in the spec, resulting in missed cases.
… So the main cases are cases involving the tab and app switchers in mobile OSes.
… As soon as the user moves to the switcher, they can dismiss the tab or app, and only firefox fires the event in this case.
… On iOS, it’s not clear if firing the event is at all feasible.
… So it would be easier to say that as soon as the user moves to the switcher, the page can be considered “in the background” and visibilitychange should fire.
… But the spec says that if a part of the page is visible, the page is “visible”.
Some questions:
Ryosuke: Confused about the distinction between switching and closing in the switcher
Philip: Not sure what the distinction is, and why iOS does different things. I think that when the app is dismissed, Safari can’t run.
Ryosuke: What is the difference in your testing between those cases?
Philip: Tested in iPhone X. swipe gesture from the bottom gives you the app switcher. Then a swipe sideways switches to a different tab, swipe up closes applications.
… So switching app is swipe from bottom then swipe sideways to pick a different app.
… Closing app is swipe from bottom then swipe up to close the Safari app.
… So want to change the model to fire before entering the app switcher, not after taking an action there.
Ryosuke: I think we know when we go into the app switcher, so probably possible to change.
Philip: I believe the blur event fires so there’s opportunity to fire an event.
Yoav: If we assume that it's feasible, would you agree with the definition? From my perspective, the main problem is the name “hidden”, but otherwise the page is hidden. All those switcher should trigger the hidden state.
Philip: On desktop, a browser could implement a UI that shows a screenshot of all tabs. But it’d be ridiculous to fire events for all those tabs in that case.
Philippe: When you say screenshot, would a video on that page play?
Philip: No
Philippe: So we’re not really seeing the viewport
Philip: I agree but need to clarify the spec. Also, do we want to change to “active”/”inactive”?
Yoav: Won’t be able to change the names for compat, but don’t think it’s a major source of confusion. So need to clarify the spec, and it probably won’t trip up a lot of people
Philip: Agree
Ryosuke: Sounds reasonable, assuming it’s implementable. I agree that if rendering is not updated, it’s not “visible”. In Windows you could see the preview of apps, but wouldn’t consider it visible. Same in Safari’s “select tabs” view, but it’s just screenshots.
Philip: Anyone from Mozilla on the call? They would need to change their implementation if we change the definition, as they now fire the event after the tab switcher action happened.
Yoav: Not on the call (between FOSSDEM and their all-hands). But we can tag them on the GH issue.
Changing the spe sounds relatively easy, and then the question is how hard it would be for implementations to follow.
Philip: There was another issue where someone was complaining about information leak in the “hidden” state. We can clarify that “hidden” doesn’t mean that the user can’t see a screenshot
Yoav: So we have agreement. Philip - would you be able to summarize the discussion on the issue?
Philip: Yup.
Philippe: Open PR on 54
Yoav: Last comment from Marcos says “don’t merge yet”. Should we give it more time?
Philippe: I’ll look into it
Philippe: long standing issue - do we classify an iframe the same as its parent or not.
Yoav: So if the window is occluded and that covers an entire iframe, what should the iframe state be.
… But before concluding what we should do, is this blocking? According to the current spec, iframes just inherit from their parent. So any occlusion behavior that does interact with iframes sounds like a feature request.
Philippe: and in the past we said we won’t change that behavior. I’ll find a pointer to past-issues.
Yoav: In the meantime, we can set it as a feature request and bump it to L3.
Philippe: I’d be surprised if we’d change behavior.
Yoav: Using mark and measure in a tight loop results in performance costs.
Annie: People also complained about the spamming of the perf timeline. Console.time and timeEnd are too constrained compared to User Timing L3
Yoav: Where is the console specified?
Ryosuke: https://console.spec.whatwg.org/
Yoav: I would split the ask into 2 different parts
… But I don’t think we want a UT option to not fire user timing entries.
Annie: They don’t want it in the console, but in the performance tab
Ryosuke: still a developer tooling feature. The tab in which it shows up is UA dependent
Yoav: Tend to say that they should send a feature request for the console spec. Maybe they want a console function that doesn’t print to console, which is admittedly weird
… Otherwise, the Chrome slowness is on me and I should fix it
Philip: The spamming is only a problem because some analytics vendors collect all the entries, and they should ask them to do the filtering.
Yoav: Yup. Andy Davies commented the same on the bug. Some RUM products support it. I’ll sum it up on the issue.
Yoav: Since Ryosuke won’t have time to review in the near future, we can look for other reviewers. Boris, Anne and/or Domenic come to mind.
Yoav: Can we use the “performance timeline task source”
Ryosuke: Sure.
Yoav: Assigning to myself
Ryosuke: After pageVisibility fires Safari never updates the rendering.
… They are updating the DOM as part of the pageVisibility event to hide sensitive information. … But the rendering will never get updated.
Yoav: Maybe the first step would be to clarify what they meant on the issue. How does page visibility related to rendering opportunities?
Ryosuke: Switching tabs fires the event, but rendering is not updated. Question to the WG: Is there an expectation in the spec that rendering will happen?
Philip: “hidden” state doesn’t mean the user can’t see the page, and is not a security feature.
Ryosuke: Banking app can want to hide the content when going to the app switcher.
… When the app is inactive, they want to hide that content.
… Does the spec have that expectation right now?
… It’s not implementable in Safari
Philip: doesn’t seem like it’s in violation of the spec. We need to clarify that to set expectations.
Ryosuke: can add a note saying that there can not be rendering opportunities after the event runs.
Philip: We could clarify that when updating the definition of hidden: updates to rendering may not fire until the page becomes visible again
Yoav: Makes sense, don’t think we want to provide guarantees that the page is “hidden from view” and gets rendering updates.
AI - Philip to sum up #58 as well.