HackBrowserData icon indicating copy to clipboard operation
HackBrowserData copied to clipboard

Published 20 hours ago • verified publisher icon moonD4rk

chore(deps): bump github.com/otiai10/copy from 1.14.0 to 1.14.1

Open dependabot[bot] opened this issue 11 months ago • 1 comments

Bumps github.com/otiai10/copy from 1.14.0 to 1.14.1.

Commits
  • 5ef5923 Revert "CopyMethod" since it's not ready
  • 49b0b59 Merge pull request #164 from eth-p/feat-copymethod-api
  • f530620 ci: Allow triggering Go workflow manually
  • b4dd789 refactor: Split common code out of CopyBytes
  • 9205813 feat: Add FileCopyMethod option / API
  • 2f93b8f Merge pull request #159 from otiai10/dependabot/go_modules/main/golang.org/x/...
  • 87072f3 Bump golang.org/x/sys from 0.23.0 to 0.24.0
  • d0690cb Merge pull request #158 from otiai10/dependabot/go_modules/main/golang.org/x/...
  • b87119d Bump golang.org/x/sys from 0.22.0 to 0.23.0
  • 355527c Merge pull request #157 from otiai10/dependabot/go_modules/main/golang.org/x/...
  • Additional commits viewable in compare view

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependabot[bot] avatar Jan 06 '25 17:01 dependabot[bot]

setting the port to a random value using --websocket-port makes everything work ok

theDogOfPavlov avatar Mar 10 '25 09:03 theDogOfPavlov

Yes, you cannot use the exact same port twice. As such you definitely need to specify a different one when running a second instance of geckodriver in parallel.

whimboo avatar Mar 12 '25 13:03 whimboo

I think you've misunderstood.

Up until recently, geckodriver worked fine in a multi-thread environment, as by default it allocated unique ports.

That behaviour seems to have stopped, and so now it requires a manual port assignment.

theDogOfPavlov avatar Mar 12 '25 13:03 theDogOfPavlov

Yes this is causing rails system tests to throw random failures since I upgraded to Firefox 136...

tomhughes avatar Mar 12 '25 14:03 tomhughes

The problem existed before but it was shadowed and could have caused a BiDi client that used geckodriver to start the 2nd Firefox instance to actually connect to the wrong Firefox process. Starting with Firefox 136 this is now causing a shutdown if the WebSocket server cannot be created because the port is already taken.

Ultimately we could do a similar approach as for Marionette by letting it automatically select the port. Would that be a solution for you?

whimboo avatar Mar 12 '25 14:03 whimboo

yup!

theDogOfPavlov avatar Mar 12 '25 14:03 theDogOfPavlov

I filed a meta bug for now (https://bugzilla.mozilla.org/show_bug.cgi?id=1953520) to collect requirements. Note that we most likely will not get to it soon.

whimboo avatar Mar 12 '25 15:03 whimboo

Is there any way to work around it? As far as I know the testing environment where I'm hitting this doesn't use that port so is there some way that I can tell geckdriver to tell firefox not to try and listen there?

tomhughes avatar Mar 12 '25 15:03 tomhughes

I assume that it might set the webSocketUrl capability which requests WebDriver BiDi to be enabled. Maybe you can tell it to not use that capability in case you aren't using BiDi.

whimboo avatar Mar 12 '25 16:03 whimboo

So, I burnt loads of time trying to get it to work using all the official geckodriver/webdriver docs, and things like webSocketUrl didn't seem to work (with it in the config, the port would still be listening and/or connected to, and fail the instance start).

The only thing I found that worked consistently was to find a free, random high-port and assign it with the --websocket-port argument.

theDogOfPavlov avatar Mar 12 '25 16:03 theDogOfPavlov

Does --websocket-port=0 work here to autoselect a port, like --port=0 already does?

joerg1985 avatar Mar 19 '25 07:03 joerg1985

Yes that does indeed appear to work.

tomhughes avatar Mar 19 '25 08:03 tomhughes

I filed a meta bug for now (https://bugzilla.mozilla.org/show_bug.cgi?id=1953520) to collect requirements. Note that we most likely will not get to it soon.

@whimboo is it naive to assume this is a one line change here, from None => 9222, to None => 0,?

joerg1985 avatar Mar 19 '25 11:03 joerg1985

@whimboo is it naive to assume this is a one line change here, from None => 9222, to None => 0,?

Lets say it is not that easy as you may thought. For desktop it's most likely fine because we do not have to do forwarding of WebSocket connections from the device where the port needs to be identical on the device and host. Using 0 on the device could make use of a port that is not available on the host, so forwarding will break.

whimboo avatar Mar 19 '25 12:03 whimboo