I am fairly certain that I have PhpStorm configured correctly for debugging. When I create a run configuration as "PHP Script", the debugger functions as expected.
Now, I want to debug an "HTTP request" as described in the official documentation, because I want to pass some $_GET parameters - note, this is an AJAX request from the browser.
However, despite following it, the debugger hits no breakpoints; not even on the first code line - even when I set the "stop on first line" option.
When I click the URL indicated by the red arrow, it is launched in the browser (without the parameters), so the path looks ok. I see no PHP errors or warnings in the IDE, nor when I launch teh page int he browser.
vlocalhost` is running just fine.
Any idea what I am doing wrongly?
[Update] With thanks to #LazyOne for that comment.
File/Settings ... Languages & Frameworks/PHP/Debug, point 1), click the "validate" link.
The path shown was the path to the script, which is not the root of localhost. Changing it to the root of localhost validated and is valid - but I still don't hit any breakpoints :-(
This might help some using Windows.
Go to File > Settings > PHP > Servers and uncheck 'use path mappings...'
With thanks to #LazyOne for that comment.
File/Settings ... Languages & Frameworks/PHP/Debug, point 2), seems to have fixed it, installing the browser plugin from https://www.jetbrains.com/help/phpstorm/browser-debugging-extensions.html and activating it (point 3 might also have helped; try it if point 2 isn't enough for you)
Related
We are working on an automated system for memory performance monitoring.
We start Chrome with proper flags --trace-gc --trace-gc-verbose both on Windows7 and MacOSX High Sierra.
The output is printed and visible on the console. However capturing the output with standard stream redirection does not work:
What do we do:
MacOS X:
./Google\ Chrome --js-flags="--trace-gc --trace-gc-verbose" > log.txt 2>&1
Windows:
chrome --no-sandbox --js-flags="--trace_gc --trace_gc_verbose" > log.txt 2>&1
What gets written into the log file is only a part of what you can see on the screen: all gc-related data is missing in the file although abundant in the terminal window (you can see all the data when you run the app without stream capture at all).
We suppose a new process for V8 is run and it's output is not directed to stdout, though somewhat it gets printed to the console itself.
The V8 C++ code shows no mark of such a strange redirect, pretty clean standard code, in fact one can record gc-output of node --trace-gc script.js without any problem with standard stdout/stderr. It seems Chrome adds the undesired behavior.
Question how to record Chrome gc-related data to a file both on Windows and MacOS X.
Partial, unacceptable solution on POSIX-based systems we can grab all the terminal output with script command. The dump contains all the data we need, but the solution does not cover Windows scenario (we do need tests on Windows) and in fact it does not solve the problem neither explains the reason behind the lacking data, it simply hides the problem away.
I think there are two things worth being pointed out.
The only output that is actually being redirected is Chrome-related. I mean if we redirect stderr to a file we can see the errors in this file, but only Chrome's errors not V8's.
I wanted to use script command as I tried Powershell Start-Transcript, Tee and a few other options. It has turned out (no suprises here) that Windows has no command that can be used to achieve desired effect (AFAIK). So I used Babun (http://babun.github.io/) which is basically preconfigured Cygwin. No GC log has been displayed. Only Chrome's related stuff. I think that V8's logs are not being forwarded to Cygwin.
UPDATE:
This issue may be somehow related with these:
Chrome spawns many processes and from what I can see from logs - GC logs are gathered from child process (different PID than one related with opened terminal window). I do not know how this alone could affect STDOUT redirection. It's just a fact I noticed.
I found out that an application may know if its STOUD is being redirected and handle this situation differently - e. i. using buffers without flushing when STDOUT is being redirected to a file but not if it is printed on the console.
UPDATE:
I have created a following bug: https://bugs.chromium.org/p/chromium/issues/detail?id=865876#c3
It seems like it was noticed and someone is going to take care of it.
UPDATE:
It seems like ChromeDriver can do exactly what we need - http://chromedriver.chromium.org/logging/performance-log
Another workaround would be to run Chrome with --enable-precise-memory-info and the periodically invoke window.performance.memory, but that command does not provide us with nearly as much data as ChromeDriver
I am using geo-location for a site running locally on my machine using HTTP on Chrome. However this does not work as I am running on HTTP as opposed to HTTPS.
On the console it says:
getCurrentPosition() and watchPosition() no longer work on insecure origins.
To use this feature, you should consider switching your application to a
secure origin, such as HTTPS. See https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
for more details.
Accoriding to Deprecating Powerful Features on Insecure Origins its says to start chrome using --unsafely-treat-insecure-origin-as-secure="http://example.com" flag. The command I ran was similar to:
chrome.exe --unsafely-treat-insecure-origin-as-secure="http://hello.app"
However, the same error message still appears.
How can I fix this issue.
None of the solutions worked for me.
I achieved this by following steps.
Type chrome://flags/#unsafely-treat-insecure-origin-as-secure in the address bar.
Add the origin which you need to treat as secure as shown in the below image.
Relaunch chrome.
You must have missed some steps. Try to follow this
Go to File Explorer then paste this to address bar >> C:\Program Files (x86)\Google\Chrome\Application (or just go to where you can find your chrome.exe)
Right click chrome.exe > send to > Desktop (Create Shortcut)
Go to your desktop then find the chrome shortcut you've created.
Rename it to ChromeForTesting (this step is optional)
Right click the shortcut, then Click Properties
At the "Target", paste the following at the end of the link
--user-data-dir=/tmp/foo --unsafely-treat-insecure-origin-as-secure=http://example.com
so Target should look somewhat similar to this
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=/tmp/foo --unsafely-treat-insecure-origin-as-secure=http://example.com
Click Ok..
During testing close all of your opened google chrome browser.
Then double click ChromeForTesting shortcut (the one you've created), when a prompt appears, just click ok..
EDIT: If the steps above does not work for you, you might be using Chrome V63, update it to V64 above cause this flag is messed up in V63.
P.S. If it's still not working follow these extra steps
At your drive C, create a folder and name it "ChromeTempFiles".
Then in your --user-data-dir= you change the value into "C:\ChromeTempFiles"
Add these to your target as well
--allow-running-insecure-content --reduce-security-for-testing
so your target should look like this now
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=C:\ChromeTempFiles --unsafely-treat-insecure-origin-as-secure=http://example.com --allow-running-insecure-content --reduce-security-for-testing
You should also use a temproary fresh profile for that session. something like this:
chrome.exe --user-data-dir=/test/only/profile/dir --unsafely-treat-insecure-origin-as-secure="http://example.com"
Just an update to this for Chrome 70. This works perfectly
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=C:\ChromeTempFiles --allow-running-insecure-content
Now does anybody know if there is an equivalent for firefox?
For Chromium 44 use
--unsafety-treat-insecure-origin-as-secure=http://192.168.0.101:3000
instead
--unsafely-treat-insecure-origin-as-secure=http://192.168.0.101:3000
See that bug
In Google Chrome, you simply type into the address bar, "chrome://flags", and search for, "--unsafely-treat-insecure-origin-as-secure", enable that flag, and enter into the field below (multiples may be entered separated by a comma) the domain you wish to treat as secure. This may or may not compromise your security, but I would assume not as getCurrentPosition() and watchPosition() are somewhat recently deprecated features. this works for publicly served domains, as well.
With Chrome 79 this setting doesn't work no matter what.
What I ended up doing was to configure the domain on a VPS to show some test webpage and then generate a valid certificate for it using Let's Encrypt's certbot.
Then I copied that certificate to my machine and it's now valid.
I'm attempting to load a page that does a call to ADFS for authentication purposes. On the page load, there is a redirect and then popup to enter credentials.
HTTPS must be used.
Chrome must be used as the testing browser.
So, when loading the page everything is working fine, but I'm forced to manually enter credentials when running the test. After inputting the credentials everything is fine, but is there a way to leverage Watir to input this for me? I've tried popping the username:password into the link already with no success, and since I really need to use Chrome the Firefox plugins are moot.
require 'watir-webdriver'
b = Watir::Browser.new :chrome
b.goto 'https://internalUAT.clientwebsite.com/'
b.link(:text => 'HR Dashboard').click
I'm not allowed to post images due to reputation constraints, but please visit
https://i.imgur.com/ExVt8fp.png
for a screenshot.
When you try passing credentials with the https://user:pass#foo.com technique, do you have any unusual characters in the username or password? (Maybe you have a DOMAIN\username domain prefix?)
If so you might want to make sure any such characters in the credential string are properly escaped.
If that's not the problem, and there's no other way to disable the auth prompt for your tests, then your best bet (IMO) is to write a separate script (or thread) that uses RAutomation (or some other UI automation library of your choosing) to enter your credentials and click the Log In button.
See https://github.com/jarmo/RAutomation
The test cases in the following file contain examples of using RAutomation's send_keys method, which could prove useful:
https://github.com/jarmo/RAutomation/blob/master/spec/window_spec.rb
For the record, it looks like RAutomation may have been used by watir-classic for dialog handling:
https://github.com/watir/watir-classic/blob/master/lib/watir-classic/modal_dialog.rb
http://www.rubydoc.info/github/watir/watir-classic/Watir/ModalDialog
How can I disable chrome using address bar for google search?
I cant access localhost at 0.0.0.0:6000, because chrome thinks it's a google search and not an url
any ideas?
This may be because a url was added to your search history. Google is doing you a favor because that's what you did once before somehow.
Try clearing your history to see if this is the case.
I went to "Clear Browsing Data" in Settings > Advanced and I was able to enter a localhost url again.
Be sure you end the url with "/" symbol.
Try:
http://0.0.0.0:6000/
Instead of:
0.0.0.0:6000
SOLUTION For chrome version 62:
settings > advanced > Use a web service to help resolve navigation errors > OFF
Try
- turn off Search Suggestions
- under LAN settings, uncheck "use automatic configuration"
Do you get the same behavior with an incognito window?
Try this alternative: http://127.1.1.1:6000 or 127.1.1.1:6000 (without http).
A search through the web has revealed several different possible causes to this problem as well as solutions.
Causes:
this is malware
this is a chrome/browser issue
this is a misconfiguration of the httpd service
Solutions:
scan for malware, though probably not the issue.
update the host file, so that localhost points to 127.0.0.1
confirm your httpd service is accepting http:// requests through port 80, 8080, or some other port.
make sure the URL has the correct port .. http://localhost:8080
try appending different delimiting characters [ / ? # ] to the URL ...
localhost/Dir/
localhost/Dir?p=x
localhost/Dir#123
does it happen on a specific directory?
localhost/Dir .. works
localhost/Dir2 .. goes to search.
This suggests that the httpd service's configuration may need to be fixed. or that an .htaccess file is the cause. If these problems can be ruled out, then it's a browser issue.
remove the autocomplete entry from the browsers search/address bar
in most cases, type the url, using the arrow keys - highlight the offending entry, press [DELETE] or [SHIFT}+[DELETE].
does your browser support turning off autocomplete or searching from the address bar?
.. chrome .. Disable Predictive Text
.. firefox .. Disable Predictive Text
open the CLI and issue [ >wget localhost/dir ]. Observe what is returned on a working vs non working directory.
Follow up:
This issue is especially annoying when working with .htaccess files and browser redirect statements in PHP, ASP, nodeJS, and JSP which redirect the browser to a specific URL, but instead takes the user to a search page. If at all possible pre-pend http:// and post-pend a slash (/) after the URL in redirects.
http://localhost/dir/
And, YES ... it is annoying to have to add extra characters (as a work around) to get URLs to work right.
I might be a bit late to the party here but I just encountered this same problem on the current chrome (v. 96.0.4664.93) and could it would not resolve any local address using any of the other methods that I found on the web(http://192.168.178.1 or setting flags or insecure DNS).
What solved the problem, was a simple "/" at the beginning of the query string.
Whenever I enter
/192.168.178.1
into the Omnibox and hit enter it works for all services.
If some other people could verify this - I'd be really happy to get some feedback on this approach.
I have this problem often myself. First, go to just localhost, chrome should understand that, then, when you type in localhost/my/url/here, the context will allow chrome to understand to treat it as a url.
I have a script that loads a php page for variables. There are no problems when the swf is uploaded to the site but when I run it locally, I keep getting "Error opening URL" messages. I'm using absolute pathing and if I paste the URL my script is using in a browser, the correct page opens. This only started happening after the site changed servers. Any ideas what the problem could be? Thanks.
The "Error opening URL" seems to be caused by a number of issues. I have tried to keep track of all the different solutions I have used in the past to fix the problem. Ever time I encounter the "Error opening URL" the solution is different. Hopefully one of these solutions helps you.
I usually find the following solutions on google.
- Make sure crossdomain policy is setup correctly.
- Set a bunch of variables like Security.allowDomain(domainHERE)
- Change publishing setting for your flash file.
- Make sure your connecting to the right url.
Here is what works for me... usually.
1) Make sure you are connecting to the right URL.
Use the full path, don't use relative links. Also, copy and paste the url in your web browser to see if it connects.
You can also use flash.events.HTTPStatusEvent.HTTP_STATUS to view the HTTP headers but I would recommend you check out solution 5 first. Its a much easier way with more details.
Source: http://www.judahfrangipane.com/blog/2007/02/15/error-2032-stream-error/
2) Put a crossdomain.xml file in the root of your server (usually public_html or www)
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>
Source:
http://www.senocular.com/pub/adobe/crossdomain/policyfiles.html
3) While editing the flash file, press Ctrl + Shift + F12
Make sure Local playback security is set to Access Network Only.
4) If you are hosting locally using MAMP, WAMP, XAMP or something similar, skip this step. Otherwise, Call your webhost and yell at them ;)
I have hosted with godaddy, hostgator and liquidweb. It seems that all of them have some kind of firewall setup blocking flash from accessing the files you want it to.
Give your host a call, tell them your problem and ask them to whitelist the files you are trying to connect to and you should be good to go.
Remember, everytime you want to connect to a new file, it has to be whitelisted. I always forget this and it takes me 3 hours to figure out why changing the name of my file or moving it messes everything up. :)
5) Use Charles Web Debugging Proxy Program to gather some important information.
I will break this down into a few steps.
Usually for me the "Error opening URL" is due to a coding problem on the site I'm trying to connect to.
Open Charles
Run your flash file
Select the site your flash file tried to connect to in Charles side bar.
View the Response tab near the top.
On the Response tab you should see a few other tabs near the bottom. View the Headers tab.
See what HTTP_Status was returned. Then look search this page to see what that status code means. It will give a somewhat broad definition but it still helps narrow things down.
500 Means a problem with your server... If your server is running fine, then its most likely a code problem.
Then view the Text tab near the bottom of the Response tab. This will show you exactly what that webpage looks like to flash. If your server is in some kind of debug mode where it displays errors, this is where you will see them.
Well I hope this helps someone. I will try to continue to update it with more issues and solutions I run into. This is probably the number one problem I run into with flash. Super annoying!
Crossdomains.xml file possibly?
not really a solution, but a work-around:
before CTRL-ENTER on your .fla, do a CTRL-S
this seems to work about 90% of the time for me
NOTE: I never had this problem until one random day about 6 months ago. Now it plagues most of my old projects, cs4 or cs6.