16:39:38 <RRSAgent> RRSAgent has joined #webdriver
16:39:38 <RRSAgent> logging to https://www.w3.org/2022/03/09-webdriver-irc
16:40:41 <AutomatedTester> present+
16:42:21 <AutomatedTester_> Meeting: WebDriver March 2022
16:43:05 <AutomatedTester_> Agenda: https://www.w3.org/wiki/WebDriver/2022-03-BiDi
16:43:11 <AutomatedTester_> Chair: AutomatedTester
16:43:21 <AutomatedTester_> Scribe: David Burns
16:43:30 <AutomatedTester_> ScribeNick: AutomatedTester
16:52:19 <patrickangle> patrickangle has joined #webdriver
16:58:25 <brwalder> brwalder has joined #webdriver
16:59:47 <jgraham> present+
16:59:59 <whimboo1> present+
17:00:28 <patrickangle> present+
17:00:55 <brwalder> present+
17:01:26 <jdescottes> jdescottes has joined #webdriver
17:02:14 <sadym> present+
17:02:49 <jdescottes> present+
17:03:02 <AutomatedTester> https://www.w3.org/wiki/WebDriver/2022-03-BiDi
17:03:49 <foolip> present+
17:04:24 <AutomatedTester> topic: browsingContext.getTree doesn't include the parent context
17:04:34 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/178
17:05:07 <AutomatedTester> whimboo: I started with the implementation of browsingContext.getTree
17:05:46 <AutomatedTester> ... when working through here I realised that it didn't return the parent just the children
17:06:16 <AutomatedTester> ... I feel like there is some really important info in the parent that we should be returning and with the way the spec is currently there is no way to get the parent
17:06:25 <AutomatedTester> q?
17:07:29 <jgraham> q+
17:07:39 <AutomatedTester> ack jgraham
17:08:07 <AutomatedTester> jgraham: reading the spec I think the way the spec was written that we pass in the contexxt and then get a flat structure for the parent
17:08:22 <AutomatedTester> ... I do think this could be a bug in the spec
17:08:33 <AutomatedTester> ... There are ways to get the info but they are cumbersome
17:08:47 <AutomatedTester> ... but I think we should fix this
17:09:42 <AutomatedTester> ... if whimboo and I do a PR to fix this, are there concerns?
17:10:16 <AutomatedTester> foolip: I don't think that it will be an issue but need to look into it more. So we are going to be adding more info rather than less
17:10:45 <AutomatedTester> jgraham: yes, that is correct [explains in depth]
17:11:02 <AutomatedTester> foolip: sadym do we have any concerns?
17:11:19 <AutomatedTester> sadym: it's not fully implemented
17:11:55 <AutomatedTester> action: Henrik and James to create a PR to correct this.
17:12:23 <AutomatedTester> topic: Are platform object references common across sandboxes
17:12:44 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/176
17:13:08 <AutomatedTester> jgraham: THis is a continuation of a discussion that started in the editorial meeting
17:13:42 <AutomatedTester> ... if I have a scrip that executes in a sandbox and it reutnrs a DOM node you will get an object ID
17:14:11 <AutomatedTester> ... what happens when we try access that object ID in a different sandbox?
17:14:45 <AutomatedTester> ... Implementation wise: the way that is implmented in sanboxes in blink/webkit they create a wrapper object
17:15:03 <AutomatedTester> ... and the object id is linked to a wrapper object
17:15:11 <AutomatedTester> ... gecko is different
17:15:56 <AutomatedTester> ... I don't think that thinking about this in implementation properties is correct, we should focus on what our users want
17:16:24 <AutomatedTester> ... we could have a different wrapper for each object id and just try make it work in gecko
17:16:54 <AutomatedTester> ... [ describes DOM nodes being used across sandboxes in CDP]
17:17:26 <AutomatedTester> ... from a user point of view its a lot work that doesn't match how webdriver tries to support users
17:18:21 <AutomatedTester> ... one proposal: we could return 2 ID, the sandbox ID and a node ID . THe node ID is constant across sandboxes
17:19:27 <foolip> q+
17:19:45 <AutomatedTester> ... I guess... to what extent do we want to expose to our users. [describes sharing NodeID in different ways]
17:20:25 <AutomatedTester> ack foolip
17:20:26 <sadym> q+
17:21:27 <AutomatedTester> foolip: question about wrapper objects in gecko? If you implement serialisation in gecko... do you use the wrapper object id or...
17:22:04 <AutomatedTester> ... in v8 we would need to treat certain objects differently. If a wrapper goes out of scope it will be GCed
17:22:29 <AutomatedTester> jgraham: I am not sure about this in gecko but I don't think it's a problem for us
17:23:21 <AutomatedTester> ... I would be surprised if this was an issue for gecko as we would have hit it with Marionette in the past
17:23:55 <AutomatedTester> foolip: how does it work? e.g. never GC wrapper objects and then just use the underlying object?
17:24:51 <AutomatedTester> jgraham: the relevant point here is that Marionette is written in JS so it's not like we have c++ code that gives us extra info. We only have access to the wrappers
17:25:13 <AutomatedTester> q?
17:25:31 <AutomatedTester> ack sadym
17:25:53 <AutomatedTester> sadym: what happens when the user tries to access an object thats not in the sandboxx? we error?
17:26:09 <AutomatedTester> jgraham: I am not sure how this would work in gecko. It's a great question
17:26:43 <AutomatedTester> ... if it's not a platform object you shouldn't be able to move between JS sandboxes
17:27:17 <AutomatedTester> ... [describes objects that can/can't be shared]
17:27:33 <AutomatedTester> sadym: [describes objects that can/can't be shared]
17:28:39 <AutomatedTester> jgraham: as long as people can understand which different objects, via properties, can be shared and if it's not a platform object then it can't be shared
17:29:23 <AutomatedTester> ... if we were just returning an opaque handle to an object, like CDP, then you can't just share this between objects
17:30:00 <AutomatedTester> sadym: Our suggestion here is to add an exxtra field to explain what type of object is being returned
17:30:56 <AutomatedTester> ... another question: what it make a difference if we use node id that can be shared between all sandboxes while object id would be to that one sandbox
17:31:34 <AutomatedTester> jgraham: I think that would but I think it might create some invariance to users
17:32:06 <foolip> q+
17:32:41 <AutomatedTester> ... [jgraham describes window proxy needing both]
17:33:00 <AutomatedTester> ... and my main concern is that if we only returned opaque handles
17:33:17 <AutomatedTester> ... if we are going to add properties then that would be good
17:33:33 <AutomatedTester> whimboo: I haven't looked at this for a while so would need to check
17:34:01 <AutomatedTester> sadym: so to check to add other properties is what you want?
17:34:05 <patrickangle> q+
17:34:15 <AutomatedTester> jgraham: yes, that way you won't need out of band info
17:34:16 <AutomatedTester> q?
17:34:21 <AutomatedTester> ack foolip
17:34:31 <brwalder> q+
17:34:56 <AutomatedTester> foolip: on the window situation, they are unique as they are global in nature
17:35:53 <AutomatedTester> ... about the 2 fields proposal. That seems good but what guarantees would we want to make sure they are differentiable?
17:36:50 <AutomatedTester> jgraham: we should make it so that are guaranteed to be different. We need to check gecko but at worst case we can have double maps to do this
17:37:00 <AutomatedTester> q?
17:37:09 <jgraham> s/doubble maps/double keyed object maps/
17:37:14 <AutomatedTester> ack patrickangle
17:38:24 <AutomatedTester> patrickangle: I am not sure we need two ideas, we could just have a boolean to say this would survive sandboxes. that way people wouldn't need to try figure out which id is important to them
17:40:25 <AutomatedTester> sadym: We have some fields that ready, e.g. window proxy. In blink it would make it hard for users to see the differences
17:40:31 <AutomatedTester> jgraham: I don't mind either solution or a wrapper id. I think we just need a way to help users
17:41:07 <AutomatedTester> q?
17:41:16 <AutomatedTester> ack brwalder
17:42:00 <AutomatedTester> brwalder: I don't think we have discussed this yet but we have generally agreement about what is moved about
17:42:18 <AutomatedTester> ... how do we then pass the returned object to `executeScript`?
17:42:40 <AutomatedTester> sadym: there are a few approaches
17:42:52 <jgraham> q+
17:42:53 <AutomatedTester> ... we check if the object id  then use it if it is there
17:43:23 <AutomatedTester> foolip: we just pass back the serialised object back
17:44:04 <AutomatedTester> brwalder: so sadym, to make sure that I understand we just check if its in the sandbox and use it if there
17:44:12 <AutomatedTester> sadym: yes
17:44:15 <AutomatedTester> q?
17:44:21 <AutomatedTester> ack jgraham
17:44:49 <AutomatedTester> jgraham: I understood the question differently, e.g. what would the API would look like
17:45:09 <brwalder> q+
17:45:14 <AutomatedTester> ... we have 1) you pass in UUID and check the node/object ID
17:45:47 <AutomatedTester> ... 2) we do what CDP does re: object ID and you pass what you need in
17:46:11 <AutomatedTester> ... for simple objects its good but it can get very complex
17:46:31 <AutomatedTester> ... 3) we have a type field and it describes the node
17:46:48 <AutomatedTester> ... I don't have a preference
17:47:06 <AutomatedTester> q?
17:47:10 <AutomatedTester> ack brwalder
17:47:35 <AutomatedTester> brwalder: I think agree with you. I prefer options 2/3 of what you said
17:47:49 <AutomatedTester> ... 1 has a potential perf hit
17:48:06 <AutomatedTester> ... and option 2 is better than option 3
17:48:42 <sadym> q+
17:48:53 <AutomatedTester> jgraham: the only time would be 3 better than 2 is that matches the rest of the spec
17:48:57 <AutomatedTester> ack sadym
17:49:42 <AutomatedTester> sadym: One of the options between 2/3 is that we make sure what is returned to the user and what they send back can be serialised
17:50:08 <AutomatedTester> jgraham: I think it would work for everything unless it's a node id
17:50:26 <AutomatedTester> ... I think we're always going to need to construct new objects
17:50:40 <AutomatedTester> sadym: if we have a node id return that else a object id
17:50:43 <AutomatedTester> q?
17:51:57 <AutomatedTester> actions: A PR for the spec change on this can be created
17:52:10 <AutomatedTester> topic: Input actions
17:52:21 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/pull/175
17:52:53 <AutomatedTester> jgraham: we have talked before to reuse the actions model from classic in bidi
17:53:03 <AutomatedTester> ... there are some questions that need to be answered
17:53:44 <AutomatedTester> ... state: do we share this across the whole session or do we want it to browsercontext
17:54:10 <AutomatedTester> ... I don't think we can do the latter in gecko?
17:54:26 <AutomatedTester> q+
17:54:44 <brwalder> q+
17:55:00 <AutomatedTester> ... in http you can only do one command at a time
17:55:09 <AutomatedTester> ... but in bidi you can send multiple commands
17:55:42 <AutomatedTester> ... however in http is probably what we want so that we don't have things tramping over each others state
17:55:42 <foolip> q+
17:55:57 <AutomatedTester> ack Automatedtester
17:57:23 <AutomatedTester> automatedtester: the main concept for actions is that we want to maintain "above the glass" so people are unaware of contexts
17:57:32 <AutomatedTester> ack brwalder
17:58:12 <AutomatedTester> brwalder:I think we should queue actions if we received 2 actions in bidi so they don't trample
17:58:23 <AutomatedTester> ack foolip
17:59:14 <AutomatedTester> foolip: we don't want to trample, but is the queue the best solution
17:59:22 <AutomatedTester> jgraham: it's the only one I have thought of
18:00:28 <AutomatedTester> github: end topic
18:00:47 <jgraham> RRSAgent: make minutes public
18:00:47 <RRSAgent> I'm logging. I don't understand 'make minutes public', jgraham.  Try /msg RRSAgent help
18:00:52 <jgraham> RRSAgent: make public
18:00:52 <RRSAgent> I'm logging. I don't understand 'make public', jgraham.  Try /msg RRSAgent help
18:00:58 <jgraham> RRSAgent: make logs public
18:01:05 <jgraham> RRSAgent: make minutes
18:01:05 <RRSAgent> I have made the request to generate https://www.w3.org/2022/03/09-webdriver-minutes.html jgraham
18:02:08 <AutomatedTester> github-bot (IRC): end topic
18:02:15 <AutomatedTester> github-bot: end topic
18:05:07 <github-bot> github-bot has joined #webdriver
20:04:36 <Zakim> Zakim has left #webdriver