Meeting minutes
browsingContext.getTree doesn't include the parent context
github: https://
whimboo: I started with the implementation of browsingContext.getTree
… when working through here I realised that it didn't return the parent just the children
… 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
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
… I do think this could be a bug in the spec
… There are ways to get the info but they are cumbersome
… but I think we should fix this
… if whimboo and I do a PR to fix this, are there concerns?
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
jgraham: yes, that is correct [explains in depth]
foolip: sadym do we have any concerns?
sadym: it's not fully implemented
ACTION: Henrik and James to create a PR to correct this.
Are platform object references common across sandboxes
github: https://
jgraham: THis is a continuation of a discussion that started in the editorial meeting
… if I have a scrip that executes in a sandbox and it reutnrs a DOM node you will get an object ID
… what happens when we try access that object ID in a different sandbox?
… Implementation wise: the way that is implmented in sanboxes in blink/webkit they create a wrapper object
… and the object id is linked to a wrapper object
… gecko is different
… I don't think that thinking about this in implementation properties is correct, we should focus on what our users want
… we could have a different wrapper for each object id and just try make it work in gecko
… [ describes DOM nodes being used across sandboxes in CDP]
… from a user point of view its a lot work that doesn't match how webdriver tries to support users
… one proposal: we could return 2 ID, the sandbox ID and a node ID . THe node ID is constant across sandboxes
… I guess... to what extent do we want to expose to our users. [describes sharing NodeID in different ways]
foolip: question about wrapper objects in gecko? If you implement serialisation in gecko... do you use the wrapper object id or...
… in v8 we would need to treat certain objects differently. If a wrapper goes out of scope it will be GCed
jgraham: I am not sure about this in gecko but I don't think it's a problem for us
… I would be surprised if this was an issue for gecko as we would have hit it with Marionette in the past
foolip: how does it work? e.g. never GC wrapper objects and then just use the underlying object?
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
sadym: what happens when the user tries to access an object thats not in the sandboxx? we error?
jgraham: I am not sure how this would work in gecko. It's a great question
… if it's not a platform object you shouldn't be able to move between JS sandboxes
… [describes objects that can/can't be shared]
sadym: [describes objects that can/can't be shared]
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
… if we were just returning an opaque handle to an object, like CDP, then you can't just share this between objects
sadym: Our suggestion here is to add an exxtra field to explain what type of object is being returned
… 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
jgraham: I think that would but I think it might create some invariance to users
… [jgraham describes window proxy needing both]
… and my main concern is that if we only returned opaque handles
… if we are going to add properties then that would be good
whimboo: I haven't looked at this for a while so would need to check
sadym: so to check to add other properties is what you want?
jgraham: yes, that way you won't need out of band info
foolip: on the window situation, they are unique as they are global in nature
… about the 2 fields proposal. That seems good but what guarantees would we want to make sure they are differentiable?
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
<jgraham> s/doubble maps/double keyed object maps/
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
sadym: We have some fields that ready, e.g. window proxy. In blink it would make it hard for users to see the differences
jgraham: I don't mind either solution or a wrapper id. I think we just need a way to help users
brwalder: I don't think we have discussed this yet but we have generally agreement about what is moved about
… how do we then pass the returned object to `executeScript`?
sadym: there are a few approaches
… we check if the object id then use it if it is there
foolip: we just pass back the serialised object back
brwalder: so sadym, to make sure that I understand we just check if its in the sandbox and use it if there
sadym: yes
jgraham: I understood the question differently, e.g. what would the API would look like
… we have 1) you pass in UUID and check the node/object ID
… 2) we do what CDP does re: object ID and you pass what you need in
… for simple objects its good but it can get very complex
… 3) we have a type field and it describes the node
… I don't have a preference
brwalder: I think agree with you. I prefer options 2/3 of what you said
… 1 has a potential perf hit
… and option 2 is better than option 3
jgraham: the only time would be 3 better than 2 is that matches the rest of the spec
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
jgraham: I think it would work for everything unless it's a node id
… I think we're always going to need to construct new objects
sadym: if we have a node id return that else a object id
actions: A PR for the spec change on this can be created
Input actions
github: https://
jgraham: we have talked before to reuse the actions model from classic in bidi
… there are some questions that need to be answered
… state: do we share this across the whole session or do we want it to browsercontext
… I don't think we can do the latter in gecko?
… in http you can only do one command at a time
… but in bidi you can send multiple commands
… however in http is probably what we want so that we don't have things tramping over each others state
automatedtester: the main concept for actions is that we want to maintain "above the glass" so people are unaware of contexts
brwalder: I think we should queue actions if we received 2 actions in bidi so they don't trample
foolip: we don't want to trample, but is the queue the best solution
jgraham: it's the only one I have thought of
github: end topic
<jgraham> RRSAgent: make minutes public
<jgraham> RRSAgent: make public
<jgraham> RRSAgent: make logs public
<jgraham> RRSAgent: make minutes