Skip to content

_WD_ExecuteScript: don't reformat JS code #489

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

Merged
merged 5 commits into from
Aug 1, 2023
Merged

_WD_ExecuteScript: don't reformat JS code #489

merged 5 commits into from
Aug 1, 2023

Conversation

Danp2
Copy link
Owner

@Danp2 Danp2 commented Jul 31, 2023

Pull request

Proposed changes

Fixes #487

Checklist

Put an x in the boxes that apply. If you're unsure about any of them, don't hesitate to ask. We are here to help!

This is simply a reminder of what we are going to look for before merging your code.

  • I have read and noticed the CODE OF CONDUCT document
  • I have read and noticed the CONTRIBUTING document
  • I have added necessary documentation or screenshots (if appropriate)

Types of changes

Please check x the type of change your PR introduces:

  • Bugfix (change which fixes an issue)
  • Feature (change which adds functionality)
  • Code style update (formatting, renaming)
  • Refactoring (functional, structural)
  • Documentation content changes
  • Other (please describe)

What is the current behavior?

Stripping of tabs and spaces from JS can result in code that no longer functions properly.

What is the new behavior?

Code is processed as-is. Any reformatting that is required should be performed prior to calling _WD_ExecuteScript

Additional context

System under test

@Danp2 Danp2 marked this pull request as ready for review July 31, 2023 22:07
@mlipok
Copy link
Contributor

mlipok commented Jul 31, 2023

still need to check, but currently focusing on frames issue.

@mlipok
Copy link
Contributor

mlipok commented Aug 1, 2023

still need to check, but currently focusing on frames issue.

here is my latest opinion

#487 (comment)

@mlipok
Copy link
Contributor

mlipok commented Aug 1, 2023

Please remove all $JSON_MLREFORMAT usage

@mlipok
Copy link
Contributor

mlipok commented Aug 1, 2023

Also in wd_helper.au3 the use of StringReplace(...... , @TAB, '') should be considered a candidate for removal.

@mlipok
Copy link
Contributor

mlipok commented Aug 1, 2023

Also in wd_helper.au3 the use of StringReplace(...... , @TAB, '') should be considered a candidate for removal.

because:

$sData = Json_StringEncode($sData, $iOption) ; Escape JSON Strings

from here:

au3WebDriver/wd_core.au3

Lines 1744 to 1748 in c39d1f5

Func __WD_EscapeString($sData, $iOption = 0)
$sData = Json_StringEncode($sData, $iOption) ; Escape JSON Strings
Return SetError($_WD_ERROR_Success, 0, $sData)
EndFunc ;==>__WD_EscapeString

It's enough

@mlipok
Copy link
Contributor

mlipok commented Aug 1, 2023

The other question is why we always return $_WD_ERROR_Success here:

Return SetError($_WD_ERROR_Success, 0, $sData)

@mlipok
Copy link
Contributor

mlipok commented Aug 1, 2023

Also in wd_helper.au3 the use of StringReplace(...... , @TAB, '') should be considered a candidate for removal.

but maybe not? I think they are there to CleanUp the mess in sphagetthi called logs.

@Danp2
Copy link
Owner Author

Danp2 commented Aug 1, 2023

Also in wd_helper.au3 the use of StringReplace(...... , @tab, '') should be considered a candidate for removal.

To me, these are two separate issues:

  1. JS code submitted by the user
  2. JS code supplied internally by the UDF

This PR is intended to only deal with the 1st instance.

but maybe not? I think they are there to CleanUp the mess in sphagetthi called logs.

Right... IIRC, you wanted the inline code to be more legible so this is the way it was done.

@Danp2
Copy link
Owner Author

Danp2 commented Aug 1, 2023

The other question is why we always return $_WD_ERROR_Success here:

IDK. We are dealing with an internal function, so it may not matter. This appears to be a carry over from before we switched to using Json_StringEncode. I suppose we could check the error code from Json_StringEncode, but then return a different error code if the function returned an error.

FWIW, I also noticed that the function header is missing a Return values entry.

@mlipok

This comment was marked as duplicate.

@mlipok
Copy link
Contributor

mlipok commented Aug 1, 2023

. I suppose we could check the error code from Json_StringEncode, but then return a different error code if the function returned an error.

Please propose solution.I will check when I woke up.

@mlipok
Copy link
Contributor

mlipok commented Aug 1, 2023

Looks fine for me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

issue in _WD_ExecuteScript / __WD_EscapeString when comments // was used in JavaScript string
2 participants