Sometimes the style sheet disappears when naviguating on our WSS 3.0 sites (white background on the site, no colors, no formatting, etc.). This has mainly happened with IE6 (corporate browser for the majority of our computers). The fixes were :
clean up temporary internet files
if it still doesn't work, upgrade to IE 7
However, this time, the upgrade to IE 7 hasn't worked, the style sheet isn't applied. When we clean up temporary internet files, things go back to normal, but after a while the css disappears again.
Here are a few ideas on what you could try:
Fiddler should be able to tell you if there is a network problem.
Check the HTML for anything unusual. Is it malformed in any way? Can you save a copy and run it through an online validator (although this is limited in use as SharePoint's default markup isn't compliant).
If some users are having the issues but others aren't, check their permissions on the server.
You could also try using the SharePoint "Log in as another user" feature to see if the problem can be reproduced on your machine when logged in as them. You may also want to try running Internet Explorer as that user.
Check the Event Viewer on both client and server for anything unusual.
Check the IIS logs on the server for any errors.
Check the SharePoint ULS logs on the server in the "12 Hive" for errors that might be related to this problem.
Try running Process Monitor on the client and reproduce the problem. Search for keywords such as FAIL or ERROR to see if anything appears. Make a note of the time the problem occurs and see if the Process Monitor logs give any additional information.
Is there some javascript that's involved as well? Could it be a virus scanner that is set way to strict? As you pointed out in one of the comments, the CSS isn't even being requested (at IIS log level, which is as basic as you get, not even in SHarePoint yet), so it HAS to be something on the client PC.
Related
I have switched to using Content-Security-Policy for my website. I'm starting to see reports about the following not being allowed: https://www.pagespeed-mod.com/v1/taas
Does anyone know why the website is trying to load this file? I'm using Google Analytics and Tag Manager, but I don't think that I have any page speed mod installed. Maybe this is an extension in the user's browser? Or when they open developer tools? Another source I could think of is automatic optimization through Cloudflare which I'm also running on.
Extra info: The source of loading this script is https://3001.scriptcdn.net/code/static/1 which doesn't reveal much about who made that.
Had the exactly the same issue and preventing me from using Element Inspector/ debugger. It appears to be some Chrome extension you have installed gone rogue, see if you have extension called "Auto Refresh Plus" installed like i did before.
I also see reports on https://www.pagespeed-mod.com/v1/taas being blocked with the same source of loading. It seems to happen in short periods on the various resources I have reports from. This indicates that it is related to the user/browser and not related to the site itself.
The same can be seen with translators, extensions, security proxies etc. I have given up trying to attribute the source of anything that is likely not caused by legitimate site content.
Every time I try to connect to any SharePoint site running on my customer server I get the following error.
An error occurred accessing your Microsoft SharePoint Foundation site
files. Authors - if authoring against a Web server, please contact the
Webmaster for this server's Web site. WebMasters - please see the
server's application event log for more details.
I already checked the sharepoint options in CA and in every site in the mentioned server. Everything seens correct but the error persists.
It looks like there is no direct relation to SharePoint and something else in the server but I was not able to determine what could cause such behaviour.
Hope someone here has something to say.
Well... After a very long and painful headache we were able to find out what was causing this malfunction.
It was a .net agent from New Relic. This agent is used to analyse traffic, page load time and some other cool things. It basicly add some javascript to the head session of every response our IIS make and this code send some data to New Relic servers that will be processed to build some reports about the applications running in the IIS.
In the end, I just disabled it and SPD turned back to life.
Thanks.
PS: Boland was in the right path. I were able to find out the solution using Fiddler to analyse the responses from IIS. Thanks.
You have to check the event log. Do you see any error there? If not, it must be a network issue. Firewall is rare, because SPD works on TCP/80.
Trying to investigate an issue a customer is facing where he gets a generic IE9 error - "Internet Explorer cannot display the webpage". We have ruled out connection settings as a potential cause, is there any to get a dump/snapshot of the security settings on this customer's computer?
I already saw some threads on the forum regarding gpedit.msc (here); however when I did a dry run on my system I am not seeing the information that I expect. I.e. the operation is not recursive and the few sites in my trusted/blocked list do not show up either. Is there a better method?
Vin
hi
i have a problem at my production site, client reported that he is not seeing data in lists of sharepoint, as well drop downs which have years in pages of site appear empty with one user A on machin X having with windows 7. but data and comes up and drop downs are now populated when accessed from machine Y with same user A.
i dont knw wht really the problem is. As to development site this issue is not produced,
plz help,
thnks in advance
From your question, I gather the data does exist and the same user can see the information from one computer but not another.
A couple things spring to mind. (I am presuming usage of Internet Explorer since SharePoint 2007 has some rather weird rendering issues with other browsers. Correct me if this is an incorrect assumption.)
First, Windows 7 has later versions of IE which can refuse to send network credentials to a server it doesn't think is part of the intranet (corporate network). What makes this especially frustrating is that IE will prompt for network credentials (a result of the challenge from the website) but will not transmit those credentials. Examine the IIS logs to see if this is the case. The requests will be void of credentials using IE but will be present using Firefox (and presumably any other web browser). The fix for this is usually as simple as adding the domain into the Local Intranet zone in Internet Options.
If this is not the case, can you confirm the user is using the same credentials? Is this integrated authentication using Active Directory or forms authentication?
Are there any differences between the two computers with regards to how they reach the SharePoint site? (Such as one is VPN, the other is directly connected)? Or are they essentially equal but with different browser/OS configurations?
Are the lists standard out-of-the-box lists or have they been customized with SharePoint Designer or any other means? Are you injecting JavaScript via a Content Editor Web Part which might not be executing correctly?
It would be very helpful to know browser versions used, OS versions used, differences in connectivity to the resource from each machine, type of authentication used, and any other thing you can think to list.
I wish you luck in tracking this down!
Windows 7 or xp has nothing to do over here probably it has to do with the browser which he is using to browse the site ask him to chk the internet explorer settings and verify that he has enabled execution of javascript and other related things
A cheeseburger to the first person who can help me make sense of this. I have a page in a Sharepoint app that uses Telerik's RadUpload to upload files. This has worked for months; last week it stopped working (in Internet Explorer, this detail is important). After talking with a co-worker about the problem, I tried the upload with Firefox; it worked. Not only that, all subsequent uploads from Internet Explorer started working. Flash forward an hour, and the aforementioned coworker, on another Sharepoint site, running on different servers, was having problems downloading (using Internet Explorer). Being half serious, half smart-aleck, I said 'try it in Firefox'. Not only did that work, ALL SUBSEQUENT DOWNLOADS IN INTERNET EXPLORER WORKED! And he re-produced this behavior on another machine. My fear is that this a browser issue. All advice will be greatly appreciated.
a
IE will try and present credentials to a server it knows to be in its Local Intranet zone when it tries to connect (depending on the setting of "Automatic logon only in Intranet zone").
Firefox will only present credentials when prompted, and will generally ask you by popping up a box (unless you've configured a list of sites for it to always present NTLM credentials to).
I've seen a similar case with Sharepoint where you can cause IE to work by logging in with Firefox. I theorized it was due to a permission on a remote resource being for "Authenticated Users", and you're causing your user to authenticate by logging in forcefully. We eventually set the "Automatic logon only in Intranet zone" to "Prompt" and it worked. My theory there was that it wasn't detecting the site as being in the Local Intranet zone for some reason. If you're not accessing a domain with no .'s in it, try also setting your Local Intranet site policy to match the full domain of the Sharepoint server, not just *.example.com - I've read that that can help.
Was it as simple as IE not re-downloading miss-cached .js file, maybe, that firefox did download, making IE work after that?
Pretty gnarly to debug.