Chrome cy.visit breaks testpage, but works in Electron #4263
Assignees
Labels
browser: chrome
type: duplicate
This issue or pull request already exists
type: unexpected behavior
User expected result, but got another
Comments
|
For investigation:
Same thing works in Electron:
|
MrMinimal
changed the title
|
There is a closed issue with the same problems: #1497 It seems that a browser plugin might be the problem. |
|
@jevors Thanks for the fast reply but as stated in that issue they also reproduced the issue without any plugins. I don't have any Chrome extensions installed. |
|
We have also been facing this issue for quite some time now and had to use electron to bypass it. It would be great to get a fix. |
|
@MrMinimal The localhost issue will be much harder to reproduce, since we are not running your same application I am not experiencing the 404 on visiting google.com in Chrome Version 74.0.3729.157 or 74.0.3729.169 on a Mac.
@RicardoVaranda What OS are you using? What Chrome version? Did it start happening at a specific Cypress version? |
|
I was experiencing the same issue, and upgrading from 3.1.0 to 3.3.0 solved it. |
I'm running Windows 10 and tried on both :
Similar to @MrMinimal the same tests run just fine if I choose to run in Electron 61 without redirecting to a 404 page. |
|
Hi @jennifer-shehane, I also experienced the same behaviour as other people commenting here (@RicardoVaranda, @MrMinimal). If I am correct, the problem is with setting "top" window. Here is the test (no rocket science in here): describe("example", function() {
it("of test", function() {
cy.visit("https://www.google.pl/");
});
});I would really like to post the screenshots but the corpo firewall is blocking my connection, so I will describe the situation: In Electron => Dev Tools => Sources I see the following: top When I open (index), I see the following info inside: This is probably the part that is failing in Chrome and working in Electron. When I start test in Electron, I see that the test is running and request to "https://www.google.pl/__" is performed but then the whole Cypress environment inside browser is reloaded and then the test is being run again, that time (I suppose) the 'top' is set correctly and request to "https://www.google.pl" is sent correctly and page is displayed correctly. When the test is started in Chrome, all I see is the request sent to "https://www.google.pl/__" and the famous 404 error: "The requested URL /__/ was not found on this server. That’s all we know." I hope that my description will help you guys with fixing the problem. Cypress is a great framework, although it has some limits imposed by its creators. I was thinking that such requests to Google are outright blocked but it seems to be a problem with Chrome, not with Cypress. Keeping my fingers crossed for fixing this problem. Wojtek |
|
OK, I verified the reload when running test in Electron. At the beginning, Dev Tools => Sources shows this: top After a reload, there is a significant change: top Chrome also replaces "localhost:xxxxx" with "www.google.pl" but the request fails with 404 error, so it is clear for me that setting the "top" fails in Chrome. |
|
We also seem to be facing this issue if we try to point to an application locally, if we try with electron it works correctly, once we switch to canary / chrome. The tests seem to break out of frame and it redirects within the angular app: |
|
Interesting observation: I set the DEBUG mode on my Windows computer: https://docs.cypress.io/guides/guides/debugging.html#Print-DEBUG-logs Then tried to run the test with Electron (output below is visible after the reload, when "localhost" is being replaced with "www.google.pl" in Dev Tools => Sources tree on the left): However, when I run the test case with Chrome, reload is performed but no such logs are present in console. This may mean that the browser cannot connect to the Cypress environment, where "top" is set. Correct me if I'm wrong. |
|
@jennifer-shehane @flotwig @brian-mann Hey guys, is there any further logs we can provide to help resolve this issue? Essentially this is blocking us internally to run any tests other than using the built in "Electron". I'll be happy to supply any logs / details required to try and get to the bottom of this issue. Thanks |
|
The top url reloads when you do not have a You can read more about this intended behavior here: https://on.cypress.io/best-practices#Setting-a-global-baseUrl |
|
Thanks for your reply, we have previously tried setting the baseUrl but it comes out to the same result,
and then gets redirected to:
This route obviously doesn't exist within our app and redirects to a 404 page. |
|
I also noticed another format of slashes in console when running tests on Electron vs. Chrome |
|
I can't reproduce this with Chrome 73 and Cypress 3.3.0 on Windows 10 either: @RicardoVaranda Please supply the complete |
|
@flotwig we probably both experience the same issue (me and @RicardoVaranda). Here are my logs: Cypress 3.3.1 Chrome 74: Console log: Electron 61: Console log: It seems that something fails with Chrome after switching the page URL: Electron: Chrome: |
|
This may be an interesting point - however, I am not sure if this can be related to Chrome and not Electron, as both are based on Chrome/Chromium... https://stackoverflow.com/a/35921090
Maybe the difference is just between Chrome and Chromium (Electron)? Electron is a built-in browser from atom.io and it is based on Chromium. |
|
Aaaaaaaand I think we got it @RicardoVaranda @flotwig :) Electron: Chrome: Take a look at remote address of a successful and failed request for https://www.google.pl/__/: Electron (successful): Chrome (failed): |
|
I've freshly installed cypress and set up a simple test like so: it('should load page', () => {
cy.visit({
url: 'http://localhost:4200/group/test',
failOnStatusCode: false,
});
});Prior to cypress open I ran:
I also have no proxy configuration set and I'm pointing to a local environment as can be seen above. These are the initial request headers we have on Electron: Compared to the same request on Canary / Chromium: While most of the requests are equal on Canary / Chromium it seems the remote address are different. |
|
@flotwig any updates on this? We already provided the potential problem description, could you check this? TL;DR: Remote address (host and port) in request headers is not set to Localhost when using Chrome. Everything is working on Electron. |
|
This is interesting, thank you for discovering this discrepancy. Remote Address should be the @wojciechsabaj Can you could supply the I'm also wondering if this could be #1253 in action - corporate policy preventing us from setting the proxy Cypress needs. Could you share screenshots of |
flotwig
changed the title
|
@flotwig I also previously attached my command prompt debug logs, check them out here: The first section under Chrome and Electron browser names. After setting "DEBUG", I get the following results: START: Starting Chrome: Starting Electron: Chrome chrome://policy/: After visiting "chrome://net-internals/#proxy" I only see those two buttons: "Re-apply settings" "Clear bad proxies" I hope that this will help you to pinpoint the problem. |
|
@wojciechsabaj It does look like you're experiencing #1253 - see how you have This isn't something that we can fix from Cypress's end, since there's no way to block Chrome from loading policy. You may be able to ask your administrator to lift this policy restriction. Can you try the workaround listed in this issue comment? #1253 (comment) @RicardoVaranda @MrMinimal Can you check your |
|
@flotwig, good catch! I am very eager to check this out but my corpo computer is so locked that I have no access to delete the value 😭 It will only be possible from Rescue Mode, after loading the hive, changing the value and unloading the hive. Is this possible for Cypress to display a warning if such key is detected on system? |
|
Since we are having similar issues I'll also post our findings within our corp: After setting When I switch and run on Chromium and Electron it doesn't seem to generate any logs but when we initially run: These are the logs: Sadly due to company rules can't send all of the information but I can tell you that
Please let me know if you require anything else from chrome://policy and I'll see if I'm able to release it. In |
|
@wojciechsabaj Good idea, I've created an issue to track adding a warning: #4391 @RicardoVaranda Thanks for supplying this, it looks like you are also having the |
|
@flotwig Thank you for looking into it, sadly I don't see this change happening in corporations with emphasis on security. In our case this is a company wide policy. |
|
@RicardoVaranda You may be able to delete the policy yourself if you have local administrator access. Sidebar: It's especially unfortunate that so many companies have this policy set, as forcing a proxy is basically just security theater. It does nothing to make you more secure. Users can get around being forced to use a proxy by using other browsers that don't respect policy, like SRWare Iron, or by injecting a DLL that blocks the policy. Of course, your company's network will not allow Internet access without going through the proxy, which also makes forcing ProxyMode redundant. 🙄 |
flotwig
added
type: unexpected behavior
|
@RicardoVaranda An idea that comes to my mind is to try to use the portable version of Chrome/Chromium, as portable version should not use the Windows registry and store the values inside the file in program dir instead. FYI, "Managed by your organization" was introduced in Chrome 73. I do not know if installation of an older version of Chrome can help in accessing the proxy settings and removing them. |
|
@MrMinimal Can you check and let us know if you are also being affected by policy? Just sharing your |
cypress-bot
bot
added
the
stage: awaiting response
|
@wojciechsabaj That's a possibility but it's subjective to the level of security or restrictions within your organisation. Within ours it's quite strict and as a result installations and even execution of programs are all restricted by policy. We will continue using electron for now but sadly this makes cypress harder to sell internally. Not being able to run it in an external browser which is often the default one is raising a lot of questions. We have a requirement to also test integration with a chrome extension which you are not able to do with electron. |
|
@wojciechsabaj I tried to use portable Chrome from portableapps.com as a workaround, but it doesn't seem to work. Did you have success with a particular portable version of Chrome? Also, fyi, using Chromium instead of Chrome may work to bypass the policy. |
|
I also tried Chrome Portable and it was also overtaken by my organization - which seems kinda strange, 'cause portable version of the browser should not use the settings in registry. I am currently using Electron but I will try to work on this topic when I have more time. Thank you all for your engagement in solving the problem. Keep up the good work! |
|
Closing this issue for now since it looks like a duplicate of #1253 @MrMinimal - if you do not have Chrome policies set by your organization (check |
jennifer-shehane
removed
the
stage: awaiting response
|
Hi Everyone, Is there a workaround for this issue , as even I am facing the same issue. Unfortunately I can't use Electron as it's not a supported browser. Also my chrome://policy/ has { "ProxyMode": "system" }. |
|
@yaminikkotharu12 Please see this comment #1253 (comment) |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Current behavior:
When running a cy.visit in Chrome 74 the testpages turns nearly blank and displays
Cannot GET /__/.However it does visit the page when Electron is used.
1. Running test
2. Redirect?
Config
Desired behavior:
The
cy.visit()call should show the served page atlocalhost:8080in an iframe.The testpage should stay visible (as seen in screenshot 1).
Steps to reproduce:
The following test redirects to the page shown in the screenshot:
Versions:
Windows 10
The text was updated successfully, but these errors were encountered: