Meeting minutes
<bajones> +present
<cwervo> +present
<atsushi> date: 26 May, 2020
<atsushi> yonet: please present+ again; bajones, cwervo: use present+ instead of +present
administrivia#96 Virtual TPAC
ada: there is no tpac
cwilso: w3c made tpac virtual
ada: we were thinking so we hold a weeklong of one hour meetings?
… or just ignore it and just have our regular meeting
… or have a video chat all day long?
… does anyone have any suggestions?
… please drop us an email and we'll try to work something out
Leonard: I've been in several meeting. Let's restirct to 2-3 hours and no weekends
… maybe tuesday-thursday
… just give us enough notive
… 4+ hours is too long
bajones: I agree with Leonard
… more beneficial to break it into smaller meetings
… we also have time zone issues
… it also depends on the agenda items
<Leonard> My statement wasn't recorded correctly: It should be no meetings on weekends, but the meeting could run on multiple weeks.
ada: replicating the TPAC is a non-goal for me. Very stressful
… so something less intense would be nice
… but having shared meetings with other groups is nice
… does anyone thing we should meet with other groups
avadacatavra: I did TPAC virtually last year and it was painful because of time zone and family issues
… it can be rough if it's one hour each day especially if it's the middle of the night
… it's better if it's one full day
<bajones> +1 for hubs!
avadacatavra: also, mozilla hubs is great for this. I've used it before and it works really well
… the social part is great
<yonet> +1 and hearts for hubs
ada: if any group should use hubs, it's us!
avadacatavra: hubs is mozilla's social vr experience
… work in vr but also in 2d
… it has spatialized audio
ada: that's a great idea
Manishearth: if we want to do more than 2 hour of meetings, we should split it out
… sometimes people want to step back and have a small meeting
dino: the css group had a virtual meeting
… which worked out great. it went over several weeks
Leonard: I agree with the timing of the meetings. ??? started meetings earlier to accomodate other time zone
… if it's US and Europe, do it early in the day
… it's good to have social and hallway meeeting
ada: one thing that would work well. Over a week we'd have meetings over 3 days
<Leonard> +1 to Ada's suggestion
ada: and we'd group people in meetings that they care about in the right time zones
<yonet> +1
<avadacatavra> +1
ada: I'll make a strawman proposal and then we'll see it from there
… I'll do that this coming week but please email suggestions
webxr#1036 "Ensure an immersive device" cannot be run in parallel
Manishearth: this is a tricky issue because we've shipped a broken API
… right now we support device selection
… but we're relying on a synchronous mechanism
… this is bad because the main thread is blocked
… there are a couple of paths forward
… the xrcompatible flag is there but not used by any UA
… ??? but this will break existing content
<Manishearth> https://github.com/immersive-web/webxr/issues/1036#issuecomment-629598102
Manishearth: the other option is to leave it as is
… (see agenda description for all the options)
… I'm leaning towards option 4 but I want to consider option 2
… because I don't like the patching of this in the webxr spec
RafaelCintron: there are cl in the works to use the xrcompatible flag for use in hybrid devices
… right now it completely doesn't work on their hardware
… so the more we can solve this without breaking content, I'll prefer
… I agree that all options are less than ideal
Manishearth: the tag and people from mozilla are opposed to slow synchronous
… with the change devices that works should keep working
RafaelCintron: maybe we should require the xrcompatible flag.
Manishearth: that is my suggestion
bajones: I don't like that since we're not CR, we can break things
… we should have recognition that this was something we preferred
… this is already in place for webgl and canvas 2d
… when you call getcontext you could force a context loss
… but that is not a good option. it harms usability of the API
… so what we picked avoided the worst path
… the other thing was that we made the page xrcompatible
… so that every context on that page would be xr compatible
… we don't want slow and synchronous
… we're backed into a corner because of the existing webgl behavior
<Zakim> kip, you wanted to mention that we should also consult with the WebGL group for their feedback.
kip: given that we have some options, I got some feedback from the webgl group
… we should fix it from the beginning
Manishearth: I don't agree that we should make breaking changes since we're not in CR
… I don't like slow and synchround
… but if we already have run device selection, we can give you the right devices right away
… so the only time to get the context loss event is if you already run issessionsupported
… if you haven't run issessionsupported
RafaelCintron: there was an option where the webxr runtime gives you a context
<ada> sorry I fell off the internet
RafaelCintron: in that case, we'd have to care about context loss
<ada> cwilso: could you chair?
bajones: I wanted to point out that the context loss option is a terrible option for users
… since they never expect this to option. some frameworks might handle it
… in webgpu, the equivalent hook is asynchronous. so moving forward this problem will go away
… it's not great to be synchronous, it's a result of legacy APIs
webxr#1041 Reporting pose data depends on the state of the document?
Manishearth: I will focus on this one since it's security related
… we have a check in the spec about the hidden state of the document
… so we don't return poses if the user is not interacting with the page
… this might have unintended UX experiences
… also we should never throw during unexpected things
… so we should return a null pose instead
<Zakim> alexturn, you wanted to talk about XR topmost vs. 2D focus
alexturn: we hit this on wmr and we ended a spit option on focus
… there's the one traditional focus such as keyboard input
… the way we handle xr stuff, it's more xr topmost
… the thing that is on top of an xr scene gets the input
… I don't have we can put this in spec text
… if the user agent has logically switch away, everything should be going away
… definitely exceptions shouldn't happen if the user switches away
bajones: yes, throwing exceptions is a bad thing. a pose of null is much better
… I
… I don't remember exactly where the original security spect text came from since John Pallet is no longer on the team
… personally, clicking on devtools while in vr stops the scene which is a bit annoying
avadacatavra: what I'm hearing, that the usability here is problematic
… I'm unsure that the security angle is handled by null poses so we should go that route
bajones: can you expand that?
avadacatavra: what we don't want that if you're not in focus, that the non-focused page gets input
… what we're having, is if you're going away, you freeze
… we shouldn't be errorring on that. We want null poses
Manishearth: should we always have no poses when the document is hidden?
avadacatavra: I have to think about it
Manishearth: there seems consensus that there is no exception thrown
mounir: usually devices don't expose changes when the document is not visible
… originally I was surprised about the focus usage in webxr
… most pages still work while not in focus
<avadacatavra> a+
mounir: the related API show if the page is visible
… so maybe delaying until the page is visible again is an option
alexturn: I wanted to note that the spec is using document visibility
… since we have the xr visibility state which was intended to work around this
<Zakim> alexturn, you wanted to talk about how we already have XRVisibilityState to represent this discussion in a more nuanced way
alexturn: when you switch to a different tab
… the middle state of visible blurred is to keep rendering but not get focus
… so maybe this is legacy content in the spec that needs to be updated
avadacatavra: we're using visible blurred for simple yes/no but not for keyboard input
… I'd say that in my opinion, there's no reason to throw a security error unless we can find the original issue that John Pallet was trying to fix
webxr#1058 Various changes around null and emulated poses
Manishearth: this handles a bunch of things around null poses
… right now, poses are never null except if there have never been any poses during a session
… it makes sense for getviewerpose
… but this makes getpose return null
<Zakim> alexturn, you wanted to ask if input sources would just deenumerate
Manishearth: it also fixes the 674 change, to get a reference space until it is trackable
alexturn: for something like a controller, it might go out of tracking fov
… so is this for example when hands go out of space?
… my model is during those times the hands are no longer enumerated
Manishearth: for input that works ok
… but not for anchors and fingers
bialpio: we should allow that null poses can be returned
… since it fixes a number of issues
bajones: +1 to those. If the controller goes away for a long time, it should go away
… ideally controller should never return null but it's not a restriction we can put on the space level
… for anchor it makes sense to have pose values if it's far away
alexturn: I agree with all this. Anywhere we remove edge cases we can more consistencies
… if we carve it out and remove it from input source space, ???
Manishearth: specifically for hand input, if it disappeard and comes back, the order in the array might have changed
… this could lead to content missing things up
… for controllers we don't have this issue because even if they're out of fov, they are still in communication
alexturn: pages might get confused if your hands input goes away and comes back
<Zakim> kip, you wanted to mention that things like vive tracker's should probably not de-enumerate
kip: vive trackers. you might have a bunch of them
… if they disappeared and reappeared, the mapping would be lost each time
Manishearth: true. that's an issue
bialpio: a quick notice, we are giving sites raw camera access
avadacatavra: we are also experimenting with immersive navigation on hubs
… and we're experimenting with immersive trusted UI
<atsushi> s/(see agenda)/... (see agenda)/
<atsushi> s/... I$//
<atsushi> s|s/(see agenda)/... (see agenda)/||