So a couple of month back I wrote a test sender to get some experience with Cast senders. It worked fine and I could send images and videos to my Chromecasts.
I now need to create a custom receiver and I wanted to use my old sender to test my receiver code. However, my sender doesn't work anymore eventhough I didn't change anything since then.
The errors i'm now getting in Chrome's console are the following:
GET file://www.gstatic.com/cast/sdk/libs/sender/1.0/cast_framework.js net::ERR_FILE_NOT_FOUND
Uncaught ReferenceError: cast is not defined
at window.__onGCastApiAvailable (script.js:84)
at chrome.cast.cb (cast_sender.js:99)
When I look at the "Network" tab I can see that the cast_framework.js file failed to load after 22s.
I then tried to use the sample on Google's Github to see if it was my sender that was at fault but I get the same error.
I also can reach the devices with the Cast button in Chrome's menu.
What is going on with that file? Is it my browser that has a problem? Is it my devices?
So the problem was the following:
As you can see the browser was looking for the file with file://. This happens because I launched my HTML file locally so the url in the browser was file:///home/.../index.html and I guess when it loads the framework file it guesses that it has to use file:// too instead of html://.
Someone told me that I should serve the file from a server so I made a brief Node server with express.static to serve the file and it then worked again when I loaded the page via localhost:4000.
I still don't know how it worked a couple of month ago but I guess I was just lucky in some way.
Upon checking, this file below is visible:
www.gstatic.com/cast/sdk/libs/sender/1.0/cast_framework.js
You might want to try putting these codes inside your head tag in your html file that calls "script.js":
Check this Github Guide
Include the cast_sender.js tag
Add the script tag to your HTML page
<script type="text/javascript" src="www.gstatic.com/cast/sdk/libs/sender/1.0/cast_framework.js"></script>
<script type="text/javascript" src="https://www.gstatic.com/cv/js/sender/v1/cast_sender.js"></script>
Related
I host my own website at home (using wamp) that uses basic authentification. The authentification worked well and username:password in the url worked too. But since last week, when I load url with username:password#url.com it doesn't work and it seems that the css /js data won´t load. I tried this with a bootstrap example site and it worked. So I guess the problem is my website.
Here is my website template, as you can see the CSS doesn´t work except when reloaded.
I don't have this problem at the bootstrap example site (Link)
I use Google Chrome Version 59.0.3071.115 on my computer and it doesn't work on my android phone too.
Edit : it seems that the problem come from the URL. Chrome try to load css with basic authentication in URL and it fail. I've got Provisional headers are shown for the css file.
Do you know why I've got this problem now and how to avoid it ?
I found somebody else with this problem :
Bypass blocking of subresource requests whose URLs contain embedded credentials
Apparently it's a new limitation of chrome :(
When going on your page, I get this warning :
[Deprecation] Subresource requests whose URLs contain embedded credentials (e.g. https://user:pass#host/) are blocked. See https://www.chromestatus.com/feature/5669008342777856 for more details.
What is happening there, is that you are doing requests to URLs like :
http://stack:123456#88.182.191.233:8090/[...]
So, since you are sending crenditentials il the URL, Chrome blocks it (returning a (blocked:origin) status)
Edit: By the way, you should never send credentials over URL, especially when you are using http only.
In both image and script tags.
My understanding was that you can access both scripts and images on other domains. So when does one use this attribute?
Is this when you want to restrict the ability of others to access your scripts and image?
Images:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-crossorigin
Scripts:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script
The answer can be found in the specification.
For img:
The crossorigin attribute is a CORS settings attribute. Its purpose is to allow images from third-party sites that allow cross-origin access to be used with canvas.
and for script:
The crossorigin attribute is a CORS settings attribute. It controls, for scripts that are obtained from other origins, whether error information will be exposed.
This is how we have successfully used crossorigin attribute it in a script tag:
Problem we had: We were trying to log js errors in the server using window.onerror
Almost all of the errors that we were logging had this message : Script error. and we were getting very little information about how to solve these js errors.
It turns out that the native implementation in chrome to report errors
if (securityOrigin()->canRequest(targetUrl)) {
message = errorMessage;
line = lineNumber;
sourceName = sourceURL;
} else {
message = "Script error.";
sourceName = String();
line = 0;
}
will send message as Script error. if the requested static asset violates the browser's same-origin policy.
In our case we were serving the static asset from a cdn.
The way we solved it was adding the crossorigin attribute to the script tag.
P.S. Got all the info from this answer
CORS-enabled images can be reused in the element without being tainted. The allowed values are:
The page already answers your question.
If you have a cross-origin image you can copy it into a canvas but this "taints" the canvas which prevents you from reading it (so you cannot "steal" images e.g. from an intranet where the site itself doesn't have access to). However, by using CORS the server where the image is stored can tell the browser that cross-origin access is permitted and thus you can access the image data through a canvas.
MDN also has a page about just this thing: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image
Is this when you want to restrict the ability of others to access your scripts and image?
No.
If you're developing a quick piece of code locally, and you're using Chrome, there's a problem. if your page loads using a URL of the form "file://xxxx", then trying to use getImageData() on the canvas will fail, and throw the cross-origin security error, even if your image is being fetched from the same directory on your local machine as the HTML page rendering the canvas. So if your HTML page is fetched from, say:
file://D:/wwwroot/mydir/mytestpage.html
and your Javascript file and images are being fetched from, say:
file://D:/wwwroot/mydir/mycode.js
file://D:/wwwroot/mydir/myImage.png
then despite the fact that these secondary entities are being fetched from the same origin, the security error is still thrown.
For some reason, instead of setting the origin properly, Chrome sets the origin attribute of the requisite entities to "null", rendering it impossible to test code involving getImageData() simply by opening the HTML page in your browser and debugging locally.
Also, setting the crossOrigin property of the image to "anonymous" doesn't work, for the same reason.
I'm still trying to find a workaround for this, but once again, it seems that local debugging is being rendered as painful as possible by browser implementors.
I just tried running my code in Firefox, and Firefox gets it right, by recognising that my image is from the same origin as the HTML and JS scripts. So I'd welcome some hints on how to get round the problem in Chrome, as at the moment, while Firefox works, it's debugger is painfully slow, to the point of being one step removed from a denial of service attack.
I've found out how to persuade Google Chrome to allow file:// references without throwing a cross-origin error.
Step 1: Create a shortcut (Windows) or the equivalent in other operating systems;
Step 2: Set the target to something like the following:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
That special command line argument, --allow-file-access-from-files, tells Chrome to let you use file:// references to web pages, images etc., without throwing cross-origin errors every time you try to transfer those images to an HTML canvas, for example. It works on my Windows 7 setup, but it's worth checking to see if it will work on Windows 8/10 and various Linux distros too. If it does, problem solved - offline development resumes as normal.
Now I can reference images and JSON data from file:// URIs, without Chrome throwing cross-origin errors if I attempt to transfer image data to a canvas, or transfer JSON data to a form element.
In both image and script tags.
My understanding was that you can access both scripts and images on other domains. So when does one use this attribute?
Is this when you want to restrict the ability of others to access your scripts and image?
Images:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-crossorigin
Scripts:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script
The answer can be found in the specification.
For img:
The crossorigin attribute is a CORS settings attribute. Its purpose is to allow images from third-party sites that allow cross-origin access to be used with canvas.
and for script:
The crossorigin attribute is a CORS settings attribute. It controls, for scripts that are obtained from other origins, whether error information will be exposed.
This is how we have successfully used crossorigin attribute it in a script tag:
Problem we had: We were trying to log js errors in the server using window.onerror
Almost all of the errors that we were logging had this message : Script error. and we were getting very little information about how to solve these js errors.
It turns out that the native implementation in chrome to report errors
if (securityOrigin()->canRequest(targetUrl)) {
message = errorMessage;
line = lineNumber;
sourceName = sourceURL;
} else {
message = "Script error.";
sourceName = String();
line = 0;
}
will send message as Script error. if the requested static asset violates the browser's same-origin policy.
In our case we were serving the static asset from a cdn.
The way we solved it was adding the crossorigin attribute to the script tag.
P.S. Got all the info from this answer
CORS-enabled images can be reused in the element without being tainted. The allowed values are:
The page already answers your question.
If you have a cross-origin image you can copy it into a canvas but this "taints" the canvas which prevents you from reading it (so you cannot "steal" images e.g. from an intranet where the site itself doesn't have access to). However, by using CORS the server where the image is stored can tell the browser that cross-origin access is permitted and thus you can access the image data through a canvas.
MDN also has a page about just this thing: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image
Is this when you want to restrict the ability of others to access your scripts and image?
No.
If you're developing a quick piece of code locally, and you're using Chrome, there's a problem. if your page loads using a URL of the form "file://xxxx", then trying to use getImageData() on the canvas will fail, and throw the cross-origin security error, even if your image is being fetched from the same directory on your local machine as the HTML page rendering the canvas. So if your HTML page is fetched from, say:
file://D:/wwwroot/mydir/mytestpage.html
and your Javascript file and images are being fetched from, say:
file://D:/wwwroot/mydir/mycode.js
file://D:/wwwroot/mydir/myImage.png
then despite the fact that these secondary entities are being fetched from the same origin, the security error is still thrown.
For some reason, instead of setting the origin properly, Chrome sets the origin attribute of the requisite entities to "null", rendering it impossible to test code involving getImageData() simply by opening the HTML page in your browser and debugging locally.
Also, setting the crossOrigin property of the image to "anonymous" doesn't work, for the same reason.
I'm still trying to find a workaround for this, but once again, it seems that local debugging is being rendered as painful as possible by browser implementors.
I just tried running my code in Firefox, and Firefox gets it right, by recognising that my image is from the same origin as the HTML and JS scripts. So I'd welcome some hints on how to get round the problem in Chrome, as at the moment, while Firefox works, it's debugger is painfully slow, to the point of being one step removed from a denial of service attack.
I've found out how to persuade Google Chrome to allow file:// references without throwing a cross-origin error.
Step 1: Create a shortcut (Windows) or the equivalent in other operating systems;
Step 2: Set the target to something like the following:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
That special command line argument, --allow-file-access-from-files, tells Chrome to let you use file:// references to web pages, images etc., without throwing cross-origin errors every time you try to transfer those images to an HTML canvas, for example. It works on my Windows 7 setup, but it's worth checking to see if it will work on Windows 8/10 and various Linux distros too. If it does, problem solved - offline development resumes as normal.
Now I can reference images and JSON data from file:// URIs, without Chrome throwing cross-origin errors if I attempt to transfer image data to a canvas, or transfer JSON data to a form element.
There is a bunch of images in a web page.
Other browsers do download them correctly, but Chrome doesn't.
In the developer's console, it shows the following message for each image:
Failed to load resource
As mentioned before, problem appears only in Chrome.
What is it?
I recently ran into this problem and discovered that it was caused by the "Adblock" extension (my best guess is that it's because I had the words "banner" and "ad" in the filename).
As a quick test to see if that's your problem, start Chrome in incognito mode with extensions disabled (ctrl+shift+n) and see if your page works now. Note that by default all extensions will be already disabled in incognito mode unless you've specifically set them to run (via chrome://extensions).
Check the network tab to see if Chrome failed to download any resource file.
In case it helps anyone, I had this exact same problem and discovered that it was caused by the "Do Not Track Plus" Chrome Extension (version 2.0.8). When I disabled that extension, the image loaded without error.
There is also the option of turning off the cache for network resources. This might be best for developing environments.
Right-click chrome
Go to 'inspect element'
Look for the 'network' tab somewhere at the top. Click it.
Check the 'disable cache' checkbox.
Kabir's solution is correct. My image URL was
/images/ads/homepage/small-banners01.png,
and this was tripping up AdBlock. This wasn't a cross-domain issue for me, and it failed on both localhost and on the web.
I was using Chrome's network tab to debug and finding very confusing results for these specific images that failed to load. The first request would return no response (Status "(pending)"). Later down the line, there was a second request that listed the original URL and then "Redirect" as the Initiator. The redirect request headers were all for this identical short line of base64-encoded data, and each returned no response, although the status was "Successful":
GET data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAACklEQVR4nGMAAQAABQABDQottAAAAABJRU5ErkJggg== HTTP/1.1
Later I noticed that these inline styles were added to all the image elements:
display: none !important;
visibility: hidden !important;
opacity: 0 !important;
Finally, I did not receive any "failed to load resource" messages in the console, but rather this:
Port error: Could not establish connection. Receiving end does not exist.
If any of these things is happening to you, it probably has something to do with AdBlock. Turn it off and/or rename your image files.
Also, because of the inline CSS created by AdBlock, the layout of my promotions slider was being thrown off. While I was able to fix the layout issues with CSS before finding Kabir's solution, the CSS was somewhat unnecessary and affected the flexibility of the slider to handle images of multiple sizes.
I guess the lesson is: Be careful what you name your images. These images weren't malicious or annoying as much as they were alerting visitors to current promotions and specials in an unobtrusive way.
If the images are generated via an ASP Response.Write(), make sure you don't call Response.Close();. Chrome doesn't like it.
I was getting this error, only in Chrome (last version 24.0.1312.57 m), and only if the image was larger than the html img. I was using a php script to output the image like this:
header('Content-Length: '.strlen($data));
header("Content-type: image/{$ext}");
echo base64_decode($data);
I resolved it adding 1 to the lenght of the image:
header('Content-Length: '.strlen($data) + 1);
header("Content-type: image/{$ext}");
echo base64_decode($data);
Appears that Chrome dont expect the correct number of bytes.
Tested with sucess in Chrome and IE 9. Hope this help.
Facts:
I have disabled all plugins, and the problem still remains.
There are some sites, where the problem does not occour.
It's a known issue. See Issue 424599: Failed to load resource: net::ERR_CACHE_MISS error when opening DevTools on PHP pages and Stack Overflow question Bizarre Error in Chrome Developer Console - Failed to load resource: net::ERR_CACHE_MISS.
There is a temporary work around in Reenable (temporary) showModalDialog support in Chrome (for Windows) 37+.
Basically, create a new string in the registry at
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\EnableDeprecatedWebPlatformFeatures
Under the EnableDeprecatedWebPlatformFeatures key, create a string value with the name 1 and a value of ShowModalDialog_EffectiveUntil20150430. To verify that the policy is enabled, visit chrome://policy URL.
FYI - I had this issue as well and it turned out that my html listed the .jpg file with a .JPG in caps, but the file itself was lowercase .jpg. That rendered fine locally and using Codekit, but when it was pushed to the web it wouldn't load. Simply changing the file names to have a lowercase .jpg extension to match the html did the trick.
In Chrome (Canary) I unchecked "Appspector" extension. That cleared the error.
I updated my Chrome browser to the latest version and the issue was fixed.
It is due to ad-blocker.When project files names contains words like 'ad' then ad-blockers also block theses files to load.
Best solution is that never save any files with these name keys.
Removing the / from the path helped me to solve this problem.
See more at:
Failed to load resource: net::ERR_FILE_NOT_FOUND loading json.js
I have been trying to locate an example of remote Javascript execution from a local HTML 'a' tag. This is not going to be a malicious execution. On my index page, I use Javascript to hide divs and bring a single div to the front - in order to have multiple pages on one (in a nutshell). I typically do this using the following example snippet:
About Us
However, on a different PHP/HTML page on the same site, I would like to have links that will execute the Javascript in the same fashion, only after pushing the browser to the new HTTP request. For example, in my inept-thinking, I would expect it to work like this:
About Us
This was a failure - as my Firefox renders the hyperlink as plaintext, and not clickable. I've scoured Google and this site for info, but found no examples. I would appreciate any feedback.
Thanks.
My understanding is that you want to invoke the same JavaScript function in multiple pages. How about using the script src tag as follows:
<script src="../common.js"></script>
I believe the src attribute can be a remote js file, but haven't tested it out.
Therefore, no matter what page you want to use the JavaScript to show the about us footer, you can have the same link:
About Us
So... you want to have the browser navigate to http://samedomain.com and then execute javascript:footerAbout()?
How about passing an argument as part of the address? Something to the effect of:
http://samedomain.com&show=footerAbout
http://samedomain.com#footerAbout
Then reading the URL in your destination page and letting the destination execute footerAbout()?