This repository has been archived by the owner on Jan 30, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 43
Remove the call to goja runtime from elementHandle.newPointerAction
#1170
Closed
2 tasks done
Tracked by
#1182
Comments
click
APIs use it.click
APIs use it.
click
APIs use it.elementHandle.newPointerAction
ankur22
added a commit
that referenced
this issue
Jan 19, 2024
Move the parsing of the options for elementHandle.click outside of the promise goroutine and back onto the main goja thread in the mapping layer. This will help mitigate the risk of a panic if more than one goroutine is accessing the goja runtime off the main goja thread. This doesn't solve the problem completely though since this API calls to other areas of the codebase which does still interact with the goja runtime. See #1170 for further details.
ankur22
added a commit
that referenced
this issue
Jan 19, 2024
Move the parsing of the options for elementHandle.click outside of the promise goroutine and back onto the main goja thread in the mapping layer. This will help mitigate the risk of a panic if more than one goroutine is accessing the goja runtime off the main goja thread. This doesn't solve the problem completely though since this API calls to other areas of the codebase which does still interact with the goja runtime. See #1170 for further details.
ankur22
added a commit
that referenced
this issue
Jan 19, 2024
Move the parsing of the options for elementHandle.click outside of the promise goroutine and back onto the main goja thread in the mapping layer. This will help mitigate the risk of a panic if more than one goroutine is accessing the goja runtime off the main goja thread. This doesn't solve the problem completely though since this API calls to other areas of the codebase which does still interact with the goja runtime. See #1170 for further details.
ankur22
added a commit
that referenced
this issue
Jan 19, 2024
Move the parsing of the options for elementHandle.click outside of the promise goroutine and back onto the main goja thread in the mapping layer. This will help mitigate the risk of a panic if more than one goroutine is accessing the goja runtime off the main goja thread. This doesn't solve the problem completely though since this API calls to other areas of the codebase which does still interact with the goja runtime. See #1170 for further details.
ankur22
added a commit
that referenced
this issue
Jan 19, 2024
This helps avoid using the goja runtime when it comes to parsing the options. The options parsing has been moved to the mapping layer and so has been moved back on to the main goja thread, which will mitigate the possibility of a panic which could occur when multiple goroutines try to work with the goja runtime (which is not thread safe). There is another issue to tackle more of the goja refactoring in #1170. The change also adds a temporary fix for page.click which will also be refactored at a later stage.
ankur22
added a commit
that referenced
this issue
Jan 19, 2024
This helps avoid using the goja runtime when it comes to parsing the options. The options parsing has been moved to the mapping layer and so has been moved back on to the main goja thread, which will mitigate the possibility of a panic which could occur when multiple goroutines try to work with the goja runtime (which is not thread safe). There is another issue to tackle more of the goja refactoring in #1170. The change also adds a temporary fix for page.click which will also be refactored at a later stage.
ankur22
added a commit
that referenced
this issue
Jan 19, 2024
This helps avoid using the goja runtime when it comes to parsing the options. The options parsing has been moved to the mapping layer and so has been moved back on to the main goja thread, which will mitigate the possibility of a panic which could occur when multiple goroutines try to work with the goja runtime (which is not thread safe). There is another issue to tackle more of the goja refactoring in #1170. The change also adds a temporary fix for page.click which will also be refactored at a later stage.
ankur22
added a commit
that referenced
this issue
Jan 23, 2024
Move the parsing of the options for elementHandle.click outside of the promise goroutine and back onto the main goja thread in the mapping layer. This will help mitigate the risk of a panic if more than one goroutine is accessing the goja runtime off the main goja thread. This doesn't solve the problem completely though since this API calls to other areas of the codebase which does still interact with the goja runtime. See #1170 for further details.
ankur22
added a commit
that referenced
this issue
Jan 23, 2024
This helps avoid using the goja runtime when it comes to parsing the options. The options parsing has been moved to the mapping layer and so has been moved back on to the main goja thread, which will mitigate the possibility of a panic which could occur when multiple goroutines try to work with the goja runtime (which is not thread safe). There is another issue to tackle more of the goja refactoring in #1170. The change also adds a temporary fix for page.click which will also be refactored at a later stage.
ankur22
added a commit
that referenced
this issue
Jan 23, 2024
Move the parsing of the options for elementHandle.click outside of the promise goroutine and back onto the main goja thread in the mapping layer. This will help mitigate the risk of a panic if more than one goroutine is accessing the goja runtime off the main goja thread. This doesn't solve the problem completely though since this API calls to other areas of the codebase which does still interact with the goja runtime. See #1170 for further details.
ankur22
added a commit
that referenced
this issue
Jan 23, 2024
This helps avoid using the goja runtime when it comes to parsing the options. The options parsing has been moved to the mapping layer and so has been moved back on to the main goja thread, which will mitigate the possibility of a panic which could occur when multiple goroutines try to work with the goja runtime (which is not thread safe). There is another issue to tackle more of the goja refactoring in #1170. The change also adds a temporary fix for page.click which will also be refactored at a later stage.
ankur22
added a commit
that referenced
this issue
Jan 23, 2024
This helps avoid using the goja runtime when it comes to parsing the options. The options parsing has been moved to the mapping layer and so has been moved back on to the main goja thread, which will mitigate the possibility of a panic which could occur when multiple goroutines try to work with the goja runtime (which is not thread safe). There is another issue to tackle more of the goja refactoring in #1170. The change also adds a temporary fix for page.click which will also be refactored at a later stage.
3 tasks
inancgumus
pushed a commit
that referenced
this issue
Jan 29, 2024
Move the parsing of the options for elementHandle.click outside of the promise goroutine and back onto the main goja thread in the mapping layer. This will help mitigate the risk of a panic if more than one goroutine is accessing the goja runtime off the main goja thread. This doesn't solve the problem completely though since this API calls to other areas of the codebase which does still interact with the goja runtime. See #1170 for further details.
inancgumus
pushed a commit
that referenced
this issue
Jan 29, 2024
This helps avoid using the goja runtime when it comes to parsing the options. The options parsing has been moved to the mapping layer and so has been moved back on to the main goja thread, which will mitigate the possibility of a panic which could occur when multiple goroutines try to work with the goja runtime (which is not thread safe). There is another issue to tackle more of the goja refactoring in #1170. The change also adds a temporary fix for page.click which will also be refactored at a later stage.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What
Can elementHandle.newPointerAction be de-gojafied? All
click
APIs use it.How
After #1189, there's only one method to de-gojafy:
ElementHandle.offsetPosition
.Tasks
The text was updated successfully, but these errors were encountered: