Meeting minutes
Expose initiatorType and destination on network.Reques
github: w3c/
jgraham: when we first did the networkj request events
… we had network.initiator which ahd a type field to mirror what was in cdp. We never really figured that out and it's not being used
… but now fetch has the same use cases for the initatorType and this PR has all of this
… and there is a plan that we can deprecate the previous way of doing this
… are there any remaining concerns on this proposal?
whimboo: I wanted to mention this is a property that would fully unblock cypress sooner
… Cypress is planning a major release next year and they want to show that they have bidi support
Restore behavior of wait for navigation to complete when a user prompt is opened
github: w3c/
whimboo: we have had someone spot a regresdsion when we have an alert open with navigation to complete
… we aren't waiting for the alert, we return immediately saying timeout
… my question is "Do we want to return early if there is an alert?" I think it would be better if we were to return immediately
Should a navigation clean-up the browsing context input state map?
github: w3c/
whimboo: It looks. like there is a broken understanding between browsing context and navigator
… this is likely an issue from the move between browsing context and navigable. Do we need to fix everything or can we go fix the actions first by themselves
… when speaking to orkon there are hundreds of cases that may need to be updated in the classic spec. do we want to change one or everything?
orkon: I think that this is the same problem when we were moving to navigable before with the html spec
… i think it probably makes sense to at least have a note with browsing context meaning navigable and replace all of them to prevent any confusion between commands
jgraham: I think every use of browsing context means navigable.
… <describes if it survives traversible>
whimboo: given that it should survive navigation then we can close this issue so we don't want to fix this as one item
jgraham: the way that orkon did this for bidi was a good way to do it for the classic. It will be a rather large PR
orkon: unrelated, I noticed that bikeshed allows combining files into a spec. I wonder if we can use this to make it simpler to move things across as there are similarities in the spec.
Include stacktrace into log messages
github-bot: w3c/
<github-bot> AutomatedTester, Sorry, I don't understand that command. Try 'help'.
github: w3c/
orkon: this is a PR/issue about stacktrace not being part of the log messages
… this was originally excluded but they have come up with a use case to ignore log messages if it comes from a "third party script".
… I am now wondering if we should include stacktraces to all console logs?
whimboo: I think it would be fine to add it. I think it would add it to console logging? I wonder if we want to all people to opt into this extra info as it could add a lot of info
jgraham: I was going to say something similar. I don't know if it is expensive to compute a stacktrace as it could be expensive
… this could lead into the subscription discussion later
… I think it would be good to have a way of config if you don't want debug messages you can exclude them and do we want to opt into stacktraces. It merits a discussion
sadym: I didn't mean that we add configuration to the subscription. I don't want to send them by default, just if the user subscribes it
… and users can limit the info being passed back with preload script
jdescottes: I think that stacktraces are there for most things, have a way to add it already and support adding it in this scenario
jgraham: Let's add it by default and if we need filtering we can add that at a later stage
whimboo: could someone submit a PR that updates and adds stacktrace
… or I can try do it next week
orkon: this is in the console spec already
whimboo: we don't have this in firefox yet so I think we may need the spec changes
<whimboo> see also whatwg/
whimboo: I have put a link to the issue above
sadym: we already send stacktrace for logEntry
Allow applying preload scripts to opened contexts
github: w3c/
orkon: this is one of the. topics that was brought up by the playwright folks
… this is the PR that prepared to implements inheritance for preload scripts
… I wonder if there are concerns with this approach and would this have an issue with the events being sent out?
jgraham: I think we shouild do this
… we should be looking to add global configuration or top level traversibles be documented
… I agree we should be doing this but I think we need to be aware of all the different ways that we should bve doing this
sadym: this looks like a new mechanism. I wonder if this playwright appraoch could not be handled with using preload script globally
jgraham: I think it could but that might be harder
… people would want it a per context and I think we want it inheritable. They are both required
Subscription IDs for events
github: w3c/
orkon: this is a continuation of the previous topic
… I have been reworking this to make sure that we can inherit events
… I have tried to get all the use cases but I am not sure that I ahve got them all
… should we add subscription IDs or should we use the current way of doing it without IDs
jgraham: I like the subscription id approach is good
… jdescottes brought this up for when working on tests so we can unscribe from events that are not related to what we are wroking on. e.g. harness events vs user events
… <describes a use case where we subscribe events from a list and then diff them>
… it might be easier to have it just as a list of events we want to handle
Support finding iframe elements by browsing context id
github: w3c/
orkon: proposal of a way to find the container of the navigable by browsing context id
… there is a request from playwright and puppeteer
… there are multple ways that we can do this. I have written a PR of this is
… there is another way that whimboo suggested
… I like this way as it like how we locate DOM nodes
simons: I think that it should be a locator as that is how classic/selenium does this
there is one wrinkle that people like to find iframes by id or name
jgraham: This is about finding iframes in a navigable which is different to classic. Using a locator feels weird but I can see the appeal
… I think that I would prefer a different command
… perhaps actually this is going to be fine and won't make much difference. I am happy the PR mostly as it is
orkon: regarding this PR. At the moment we discard the locator... I wonder if there is <missed question> and should we throw an error when using the locator or should we just ignore them
jgraham: is the second question more of a CDDL question?
orkon: not really... this there are other attributes
… and they are optional fields
jgraham: I think this is pushing me to this a new command
… there is something to be said about having a command that doesn't take invalid commands
sadym: if we send command with locate nodes and then get a browsing context
orkon: yes...
sadym: this feels wrong. We are going to need to send other fields here
orkon: we could have the search from the parent context to return the child
sadym: this would change the way that the command works and feels weird
jgraham: if we need to call getTree to be able to use the command that complicates this
WPT RFC-214 Add testdriver features
github: web-platform-tests/
sadym: please can everyone have a look at this. It's not directly releated to this group but could gsnedders and jgraham and others please review