Create object reference store for strong object references
Categories
(Remote Protocol :: WebDriver BiDi, task, P1)
Tracking
(firefox106 fixed)
| Tracking | Status | |
|---|---|---|
| firefox106 | --- | fixed |
People
(Reporter: whimboo, Assigned: jdescottes)
References
(Blocks 2 open bugs, )
Details
(Whiteboard: [webdriver:m4][webdriver:relnote])
Attachments
(1 file, 2 obsolete files)
To reference objects that can be serialized only partly or not at all a reference has to be stored on the remote end to keep the underlying object alive and accessible by the client at a later time.
Right now objectId is used in the specification but a PR is open to request such a strong reference and replace objectId with handle:
https://github.com/w3c/webdriver-bidi/pull/206
Once this PR got merged we could implement such a reference store .
|
Reporter | |
Comment 1•2 years ago
|
||
A dependency that we actually forgot to add is bug 1770480. This covers the implementation of the sandbox feature and is actually required to store the remote references per realm.
Before this other bug is fixed, which will happen soon anyway, I'll already get started with the plain no-sandbox case.
|
|
Reporter | |
Comment 2•2 years ago
|
||
Unassigning for now in favor of bug 1785092.
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 3•2 years ago
|
||
We will have to decide whether we store raw objects or Debugger.Objects in this map.
Per spec, only non-primitives should be stored, which nicely works with using Debugger.Object, because only non-primitive return values are wrapped in Debugger.Object instances.
Any of the roots we need to support is retrieved at least once as a Debugger.Object. For now I will get started with this.
|
|
Assignee | |
Comment 4•2 years ago
|
||
|
|
Assignee | |
Comment 5•2 years ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #3)
We will have to decide whether we store raw objects or Debugger.Objects in this map.
Per spec, only non-primitives should be stored, which nicely works with using Debugger.Object, because only non-primitive return values are wrapped in Debugger.Object instances.Any of the roots we need to support is retrieved at least once as a Debugger.Object. For now I will get started with this.
After actually implementing it, I went for the opposite direction and I am not storing Debugger.Object. Per spec, storing and reading from the object reference store happens during the serialization. And for now we don't interact with Debugger.Object in our serialization logic. So let's keep everything about regular objects for now. If in the future we start using Debugger.Object in the serialization, we can revisit this decision.
|
|
Assignee | |
Comment 6•2 years ago
|
||
Depends on D155446
This is missing tests, and might need to move to Bug 1770754, but since I brought it up when looking at supporting handle, I wanted to experiment with the
implementation.
|
|
Assignee | |
Comment 7•2 years ago
|
||
Depends on D155518
This also needs to move to another bug, but for now it confirms that the solution works.
With this you can retrieve a remote value with a handle from script.execute and then use it in your next call to script.callFunction
|
||
Comment 8•2 years ago
|
||
Comment on attachment 9291427 [details]
Bug 1770736 - [bidi] Set internal ids if needed during complex object serialization
Revision D155518 was moved to bug 1770754. Setting attachment 9291427 [details] to obsolete.
|
|
||
Comment 9•2 years ago
|
||
Comment on attachment 9291432 [details]
Bug 1770736 - [bidi] Deserialize remote values with handle field
Revision D155522 was moved to bug 1770780. Setting attachment 9291432 [details] to obsolete.
|
||
Comment 10•2 years ago
|
||
Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d38be1dc5fac [bidi] Add an object reference map to the Realm class r=webdriver-reviewers,Sasha,whimboo
|
||
Comment 11•2 years ago
|
||
| bugherder | ||
|
|
Reporter | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 12•2 years ago
|
||
For webdriver:relnote
Added an object reference store to hold strong references for objects serialized as remote values with an "ownership" type different from "none", which is for instance useful to retrieve and reuse complex objects when using commands from the script module.
(note: we might drop this release note item, if we feel like Bug 1778976 covers it already)
Description
•