I have an Ember App.
I am not sure if it is related to ember-cli-chrome add-on. I don't think so.
I was successful in deploying the chrome extension on local machine. I could also see the popup loading etc.
I am printing my environment.js "config" just to see the values, and I notice that these values are not updated based on my code base. If I run the same code in normal browser instance, it works fine.
I also notice that these environment.js contents are quite old (I had deployed the extension few days back) and seems like these values are coming from there - somehow!!! I uninstalled chrome and installed it back - no luck.
What could be happening?
Thanks
Related
I found the following issue here in stackoverflow however cannot comment as yet. I have a similar issue and wonder if there is anyone out there that has solved it.
https://stackoverflow.com/questions/40917501/tfs-2015-web-portal-code-viewer-not-working#
I am encountering similar here. In house TFS 2015, can't view code in the web portal using Google Chrome however IE is fine. I, however, am not using HTTPS so may be experiencing something slightly different.
When I do try to view a file in Chrome, the window where the code listing should be is simply blank. I did note too that the button for creating a new build definition appears to be indicating a broken image link.
This has not always been an issue. Around 4 months ago I could get the code view fine in Chrome and, to my knowledge as I have no access to the servers, nothing has changed apart from Chrome updates.
I've tried getting to previous versions of Chrome to no avail, though I wouldn't know which version I was on when this did work.
Interestingly, I have one or two .MD files around and these display perfectly well. They are simple text files. However when saved with .TXT extension (or anything else I've tried), they do not show. Curious.
Update
As you will see from the screenshot below, when selection on a file has been made, in this case a .SQL file, where I would expect the view to populate nothing at all appears.
As for the F12, I do get 5 of these:
Failed to load resource: net::ERR_CONNECTION_REFUSED
plus associated paths of course. We use Webroot internally here which has recently dropped in a Chrome extension however even when Webroot is disabled in its entirety (including removal of extension) I get the same behaviour.
All other Chrome extensions have been removed too at varying times to try to give a clean browser.
I have no other pop up blockers, ad blockers, etc installed on the workstation.
Problem solved thanks to the F12 key suggestion.
After some grovelling I was granted domain admin privs to have a dig around everything. It turns out that TFS was installed on ServerA with a URL port of 8080, this I knew from the original install and obviously the path I follow to get to my TFS web interface. What had also been done subsequently, with no consultation of the Dev user group, was that a second TFS application tier had been installed on ServerB, the port here was 8088.
I had not noticed the difference in path initially, assuming it was Chrome or workstation related. Anyway, I altered the port on ServerB to 8080 and everything jumped into life. I should not have made assumptions and should have paid more attention to the path in the error!
It seems the second application tier was set up on a non-production environment to allow senior Dev users access to the TFS Management Console rather than allowing them access to the original app tier which was on a production box. Our IT Operations just forgot to tell anyone.
Try to update your chrome to latest version of (55.0.2883.87 m (64-bit)).
Also clear the cache of chrome. I have also encountered similar issues. The solution is clear cache and connect to the web portal use another ID, then connect back use the original ID. I have no idea which one solved the problem. You could try both.
This problem should only be an individual phenomenon, since TFS2015 has been released for a long time.
We have a site that is not working in Google Chrome V44. It works well in IE and Firefox. All of sudden after updating chrome browser to V44, we unable to login to the system and just receiving this problem.
We're trying to figure out as why this is happening. We have 2 instances of our system in our server. Our live site is the one that is not working in Chrome V44 while the other - our demo site is fine. The only difference of the these sites is that our live has SSL. So our first impression is that there's a problem with Chrome V44 with our site with certificate.
I think Chrome can't establish secure connection with the site.
Has anyone experienced this issue?
Please help. Thanks.
This is due to a SSL in Chrome V44 where it incorrectly sends a HTTP_HTTPS header to be set, however the HTTPS header is still set correctly. It has been quite widely reported: http://www.zdnet.com/article/brand-new-chrome-44-release-added-a-bug/
https://ma.ttias.be/chrome-44-sending-https-header-by-mistake-breaking-web-applications-everywhere/
In order to stop this, in PHP, I added the following to the very top of my index.php file:
<?php
if (!isset($_SERVER['HTTPS'])) {
$_SERVER['HTTP_HTTPS'] = 0;
}
?>
Ensuring there is no space between the ?> and the next
I've recently had the chrome redirect loop on gmail.
Possibly significantly, I was doing some work involving changing my system time and it hasn't worked since. This guide helped to do that.
There is an available work-around, which is to use gmail in incognito mode, which does still work, although requires you to log in each time
In that case I would say this is an internal problem with you organization's setup. I would speak with your SysAdmin or IT staff. But just to be sure, use your phone carrier's internet, or a cafe nearby, basically something off your network to check if you can reproduce the error.
The issue with my MVC solution was, i had recently updated complete Nuget packages in my solution. After the update i forgot to update
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
section with new dll bindings which installed while update. So in my hosting server due to connectionstring issue, i was not overwriting the current .config file. So once i did the update in assemblyBinding section in .config file the issue gone.
There might be many reasons for the redirect loop. If you are confident your setup is done properly without any errors, then it might be the issue with your browser. You can try the following
Deleting cache and cookies
Correcting your system time (if it is not set to automatic)
Resetting the browser
Source
You should be able to fix this problem, you can try to clear your cookies in your browser
Open your Chrome browser.
Type "chrome://settings/clearBrowserData" in the address bar and press Enter.
Make sure you are clearing items from the Beginning of time. Then select Cookies and other site data. Click the Clear browsing data button.
If find from google search, this tutorial could helps you https://windows10freeapps.com/fix-err_too_many_redirects-error-google-chrome-browser
I'm using Windows 10 Technical preview. I know it's not yet tweeked out to full usage, but here is my problem.
On local IIS I'm developing my web app. It loads most of the data via ASP.NET MVC API. After the upgrade to Windows 10 I started to get
net::ERR_SPDY_PROTOCOL_ERROR
for all AJAX calls to API. The HTML page loads normally, but the dynamic loading of data content fails. I managed to figure it out by starting Chrome with parameters
--use-spdy=off --use-system-ssl
Strange thing is that on the first start I always get this error and have to restart Chrome. Other browsers fail too, but not with specific error. For the transfer there is used HTTP2.0 protocol, which is based on SPDY protocol.
Do I have to turn something off in IIS?
Edit:
Seems like an IIS problem with HTTP2.0. When trying to enter the site from Windows 8.1 I get the same error.
Most people’s reaction to this error would be to reload the web page. We would actually recommend this as a first response. Sometimes this even does work.
Interesting Factoid: SPDY actually stands for “speedy” and is used to reduce a web pages’ load time
If reloading the web pages does not remove the error, then you should close down Google Chrome and restart it. This alone will not really solve the problem because you will need to clear the cache as soon as you restart the browser.
or in cmd clear dns using this command ipconfig/flushdns
I know this was asked before but this is what I'm experiencing -
I'm working on a Chrome extension that needs to persist some data and I'm using localStorage for that . When I go to Settings->Tools->Clear Browsing Data and check everything (including 'since the beginning of time') , I would expect the localStorage of my background page to clear .
However everything stays put. The localstorage wasn't deleted!
It's not that I don't like that behavior , it's actually pretty great for my app , but is this normal ? Shouldn't localStorage delete once the user tries to clear everything , just like cookies should delete?
P.S
I found this nice blog that asks and tries to answer the same question :
http://sharonminsuk.com/blog/2011/03/21/clearing-cache-has-no-effect-on-html5-localstorage-or-sessionstorage/
Seems like the behavior changes from browser to browser . The behavior I talked about happens on Chrome 28.0.1500.71 m
This bug is not normal behavior. ( to answer your question )
I'm calling this a bug because someone might be using a computer at a library with some type of locally hosted application. There is a clear expectation that data is not retained in any way under a purge called "beginning of time"
Firefox purges localStorage data when you clear all browser data. It does this if the file is stored locally or hosted on a web domain.
Chrome purges localStorage data only if you code is hosted on a domain.
I made a video of this bug..
https://youtu.be/CgojKg4v7X0
Save this URL with HTML/JS a local drive to reproduce the bug...
https://html5dataprivacy.github.io/
steps:
- load a local web page containing javascript HTML5 storage code
interact with the page that stores your data in a way that changes the data
clear everything in history until the beginning of time
give the keyboard and mouse to another user in the library or public cafe...
result: That javascript storage is retained , another person can see your data...
expected result: The data is purged for the new person at the keyboard
notes: This bug does not exist on Firefox current version as of April 19th, 2017. Does not fail if chrome is working off a hosted domain
Workaround: After you clear things to the beginning of time you must open up the console and type "localStorage.clear()"
ps: please be kind. This is my first attempt to answer on StackOverFlow :)
I'm trying to get TypeScript source debugging working in Chrome, but I'm running into two specific and perhaps related problems.
The first is that the comment generated by the TypeScript/WebEssentials compiler that's supposed to identify the location of the source map file looks like this:
//sourceMappingUrl=MySourceFile.js.map
But Chrome won't read that file. It seems expect that the comment will look like this:
//# sourceMappingUrl=MySourceFile.js.map
If I manually change the comment to that, and refresh my page, then magically the references to all the .ts files show up as sources in the Chrome Developer Tools.
However, that leads to my second problem, as the files don't actually get loaded. The .ts source file that Chrome should be trying to download is http://localhost/MySourceFile.ts, but the one that it's actually trying to download is http://localhost/C:/source/web/MySourceFile.ts. That sort of makes sense, as the opening attributes of MySourceFile.js.map look like this:
{"version":3,"file":"tmp1523.tmp","sources":["C:/source/web/MySourceFile.ts"
But that obviously doesn't work with Chrome, as it interprets the source-map location to be entirely relative, and IIS (quite correctly) won't serve up any URL looking like http://localhost/C:/source/web/MySourceFile.ts.
So, with respect to these two problems, is it Chrome or the TypeScript source-map feature that's doing it wrong? And what's the recommended way of doing this?
I'm using Chrome 25.0.1323.1 dev-m, with TypeScript 0.8.1 and WebEssentials 1.8.5.
This is an issue with version 1.8.5 of Web Essentials (the version currently available from the Visual Studio Gallery). The latest nightly build (at time of writing http://madskristensen.net/custom/webessentials2012.vsix) fixes the problem and generates the map linkage correctly.