Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re: Difficulties with WWW::Mechanize::Chrome installation on Windows/Strawberry

by Corion (Patriarch)
on Jan 01, 2019 at 17:57 UTC ( [id://1227883]=note: print w/replies, xml ) Need Help??


in reply to Difficulties with WWW::Mechanize::Chrome installation on Windows/Strawberry

 t/51-mech-links.t rightfully fails because on your system, you have a weirdo search engine or malware installed which injects a search engine link into the page:

http://search.frontier.com/search/?q=http://somewhere.example/myiframe +&t=0

This is not the fault of WWW::Mechanize::Chrome, but it's still a problematic Chrome installation. See WWW::Mechanize::Chrome::Troubleshooting for further information.

As to your other questions:

Do others have this much difficulty installing it on Windows?

Personally, I develop under Windows and don't experience such problems, but I have AnyEvent installed and Log::Lo4perl as well..

Is there a sequence that works to reliably install it on Windows (preferrably with cpanm) without resorting to multiple attempts, and --force? Does my detailed description below provide enough to give hints, if I'm just doing something wrong

For me, the tests pass on my machine without problems. The tests fail on Travis CI from time to time due to timeouts and/or weirdo interactions between the VM and Chrome and (nonexistent) desktop environment, but I don't consider that problematic.

Does corion know that the cpantesters results "lie" about a successful windows install, due to not finding chrome.exe? Is there a way to make chrome.exe a prereq, so that cpantesters reports will be more useful

As I wrote the test suite so it skips the tests when the Chrome executable is unavailable, I guess I'm aware of that the tests get skipped when Chrome is not available. I wouldn't consider that a lie, especially when the tests themselves in the skip message say that they skipped the tests due to Chrome being unavailable. No, you cannot make non-Perl components a prerequisite. If you want more useful reports, see the Travis CI and AppVeyor reports where WWW::Mechanize::Chrome is tested on as well.

Is the failure i found in t/51-mech-links.t real, or an artifact of my problematic install? If it's real, is it a bug in the test suite, or a bug in the module itself?

As discussed above, it is a problem with your system and setup of Chrome. This is already discussed in the WWW::Mechanize::Chrome documentation, and while I think about making the test suite more resilient against such setups, you should still clean up your system and remove whatever plugin/malware injects new search links into your web pages.

If my failures end up being invalid, is there a way to delete/override the failing reports to cpantesters? (added)

Why would you want to delete that test run from CPAN testers?

Replies are listed 'Best First'.
Re^2: Difficulties with WWW::Mechanize::Chrome installation on Windows/Strawberry
by pryrt (Abbot) on Jan 01, 2019 at 18:48 UTC

    Thanks for the response.

    http://search.frontier.com/search/?q=http://somewhere.example/myiframe&t=0

    Ahh. It's not actually on my system: the same thing happens both on my phone thru WiFi at home, or on my PC. Based on the URL of frontier.com, my ISP is apparently "helping me" by injecting their search when I try to go to a domain that doesn't exist -- probably because I'm using their DNS. (The same thing happens whether through a browser on my PC, or whether on my phone thru wifi; if I switch my phone to just use its data plan, it properly tells me the domain somwehere.example doesn't exist.) Do you think that changing my DNS to a public server rather than my ISP's DNS server would get around this? I'll probably try that at some point

    Sorry for not seeing the ::Troublshooting docs: I didn't see it linked from the main POD or the ::Installing POD, so didn't notice it was in there. I now see it on the main https://metacpan.org/release/CORION/WWW-Mechanize-Chrome-0.27 page, though I'm not sure I would have noticed if I didn't know there was a page named ::Troubleshooting. I guess I need to read documents more thoroughly.

    I have AnyEvent installed and Log::Lo4perl as well

    That probably would have helped me. I wonder why AnyEvent doesn't seem to be problematic for you, when it is for me.

    "lie"

    That was too strong of a word on my part -- I put it in quotes to try to imply that "lie" wasn't exactly what I meant. I just don't like it when I see a "clean" cpantesters report, and it turns out it's because all the functionality testing is skipped because of missing external components. But since external components cannot be made pre-reqs, I guess there's not much that can be done on smoke testers machines. I wish more users would report their install successes and failures to cpantesters, so we can see more "practical" installs. Thanks for pointing out the travis-ci/appveyor results: I should have thought of looking for those.

    Are there any "true" failure modes -- ie, failures with your module, rather than weird system/ISP setups -- that would give a result of "3" instead of "2"? Or would it be possible to pass "2" or "3" as valid? if it really is my ISP's DNS doing it to me, then ISP=Frontier might mess up other Perl users, and there might be other ISPs who do it similarly to other people. (I mean, I know I'm not the only Frontier user in the world, though I may be the only Frontier user who also uses Perl (highly unlikely).)

    Why would you want to delete that test run from CPAN testers?

    since it's an invalid failure ("oops, my bad, nothing actually wrong with your module"), I guess I'd like to be able to erase that "strike" against your otherwise clean cpantesters matrix.

      http://search.frontier.com/search/?q=http://somewhere.example/myif +rame&t=0
      Ahh. It's not actually on my system: the same thing happens both on my phone thru WiFi at home, or on my PC. Based on the URL of frontier.com, my ISP is apparently "helping me" by injecting their search when I try to go to a domain that doesn't exist -- probably because I'm using their DNS.

      Aah, I see now. Maybe I can change that to a different, non-existing domain that does not get served by them. Maybe using localhost with a port number that is hopefully unused will work better, or have a different failure mode at least ...

        http://0.0.0.0/ might be a good option. Chrome bombs with "ERR_ADDRESS_INVALID" when you navigate there.

        Okay, I pointed my router at google's DNS instead of Frontier's DNS. I did a fresh berrybrew install of 5.28.1, and ran

        cpanm --installdeps AnyEvent => success cpanm AnyEvent => success (hmm) cpanm --installdeps Log::Log4perl => success cpanm Log::Log4perl => failure (known issue) cpanm --notest Log::Log4perl => installed cpanm --installdeps WWW::Mechanize::Chrome => passed all but Future:: +HTTP cpanm --installdeps Future::HTTP => success cpanm Future::HTTP => success (sometimes the order of + installs influences) cpanm --installdeps WWW::Mechanize::Chrome => success cpanm WWW::Mechanize::Chrome => success

        So, yes, changing to Google DNS fixed the issue with the WWW::Mechanize::Chrome test suite itself. Submitting passing report to cpantesters to offset my failure

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1227883]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (6)
As of 2024-03-29 09:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found