Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Async JSHandle prepare #1365

Merged
merged 3 commits into from
Jun 5, 2024
Merged

Async JSHandle prepare #1365

merged 3 commits into from
Jun 5, 2024

Conversation

inancgumus
Copy link
Member

@inancgumus inancgumus commented Jun 4, 2024

What?

Prepare JSHandle to be async by turning panics into errors.

Why?

  • Stability.
  • To convert JSHandle to async.

Checklist

  • I have performed a self-review of my code
  • I have added tests for my changes
  • I have commented on my code, particularly in hard-to-understand areas

Related PR(s)/Issue(s)

#1303

@inancgumus inancgumus changed the base branch from main-async to async/response June 4, 2024 08:13
@inancgumus inancgumus force-pushed the async/js-handle-prepare branch 2 times, most recently from 0b09ecb to 3523f93 Compare June 4, 2024 09:25
@inancgumus inancgumus self-assigned this Jun 4, 2024
@inancgumus inancgumus added stability runtime stability improvements refactor mapping k6 browser to Goja mapping related. labels Jun 4, 2024
@inancgumus inancgumus requested a review from ankur22 June 4, 2024 09:33
@inancgumus inancgumus marked this pull request as ready for review June 4, 2024 09:33
@inancgumus inancgumus force-pushed the async/response branch 2 times, most recently from 72377f7 to 1982d55 Compare June 4, 2024 14:26
@inancgumus inancgumus force-pushed the async/js-handle-prepare branch from 3523f93 to 76fa23c Compare June 4, 2024 14:27
Copy link
Collaborator

@ankur22 ankur22 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Woohoo! Less panics! Nice work.

common/element_handle.go Show resolved Hide resolved
common/frame_manager.go Show resolved Hide resolved
for _, child := range frame.ChildFrames() {
m.logger.Debugf("FrameManager:removeFramesRecursively",
"fmid:%d cfid:%v pfid:%v cfname:%s cfurl:%s",
m.ID(), child.ID(), frame.ID(), child.Name(), child.URL())

m.removeFramesRecursively(child)
if err := m.removeFramesRecursively(child); err != nil {
return fmt.Errorf("removing child frames recursively: %w", err)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this clash with the error in removeChildFramesRecursively? It might make debugging difficult. Could this error instead be changed to removing frames recursively?

Then there's the error below when calling frame.detach, which i think could change to detaching frame.

WDYT?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, fixed in 736e87e.

Base automatically changed from async/response to main-async June 5, 2024 07:54
@inancgumus inancgumus force-pushed the async/js-handle-prepare branch from 76fa23c to 736e87e Compare June 5, 2024 07:57
@inancgumus inancgumus merged commit c0dcf4d into main-async Jun 5, 2024
13 of 14 checks passed
@inancgumus inancgumus deleted the async/js-handle-prepare branch June 5, 2024 07:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mapping k6 browser to Goja mapping related. refactor stability runtime stability improvements
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants