We have customized ribbon(js scripts) that loads properly in IE and firefox but in google chrome(which is a requirement to use it due to its high response time) it does not load the ribbon at the first instance. However, it loads after several page load refreshes(Ctrl + F5). If anyone come across this issue, provide your inputs. Appreciate your help. Thanks
SharePoint and IIS are always trying to cache resource, to ensure application performace. When you're doing SharePoint Development you've always to ensure that cache is cleared.
Especially when you're working with the SharePoint ribbon it's required to clear the cache before accessing the website after deployment.
When you're using CKS tools for deployment from VS2010 you have to ensure that files are copied to the SharePoint Root. Sometimes I get an exception when they try to overwrite JS files in the SharePoint root, because sharepoint has a handle on them.
When doing SharePoint development I always copy *.resx and *.js by hand.
The issue appears to be with the rendering of the search box control in Google Chrome. Try adding 'Visible="false"' to the 'SharePoint:DelegateControl runat="server" ControlId="SmallSearchInputBox" Version="4"' control on the master page. This corrects the rendering issue for us.
SharePoint is officially not built to work in Google Chrome
I just fixed my webkit (chrome and safari) browser issues such as scrolling and the ribbon loading with this nice script http://goo.gl/1OUlI. Ended up being a timing issue. Hope it helps you out. I see this is a bit old but no best answer.
Related
I have just developed a xbap app which is hosted in an IIS server. Working fine in server and in the developers machines but when users access to it, the message "this application type has been disabled" appears. They only have to enable "XAML" for solving this error but I dont want them to do that.
I need a solution to allow users to run this app without changing anything in their explorer.
I cant believe Microsoft decided to not enable XAML apps to work directly since Internet Explorer 9!
Thanks a lot guys!
After some research, I realized there's no solution directly in WPF Browser.
I am moving my app from that WPF Browser to asp.net web. Hard to simulate the same behaviour but moving forward so far...
I have tried this on numerous pc's and are receiving the same error. My webbrowser control isnt displaying javascript or jquery.
Here is a example:
when i visit this url in my browser: https://binarykings.co.uk/traderoom-aspx, it looks great with the charts and prices etc.
example: http://i.imgur.com/1Lmq4em.png
same in internet explorer: http://i.imgur.com/3KP864X.png
however in my vb.net webbrowser control it looks like this: http://i.imgur.com/qjme2Yg.jpg
What is causing this ? Its not just this site but any other site that has a similar way of displaying things via jquery/javascript.
I do have script errors suppressed however when i disabled this and clicked yes to the errors manually it still displayed the same empty page.
Thanks
The WebBrowser control uses the Internet Explorer rendering engine. But by default, for compatibility reasons, it is stuck using the IE 7 rendering engine, even if you have a later version of the browser installed on your computer.
There are a couple of ways to convince it to use a newer version of IE to render the page. One involves editing the registry, while the other involves modifying the web page.
In general, it is best to avoid attempts to solve local problems with global solutions like registry edits. There might be another app running on the same machine that uses the WebBrowser control and relies on the behavior of the IE 7 rendering engine. If you go changing global settings, you'll mess up that other app.
Therefore, the best solution, if possible, is to edit the web page. This is quite simple, and probably a good idea anyway. All you need to do is add the following code inside of the <head> section:
<meta http-equiv="X-UA-Compatible" content="IE=9" >
If you absolutely must use the alternative approach of editing the registry, you'll find the information you need here in the documentation.
I need to create a way so that when users load our webpage inside IEmetro it switches them to IE10 Desktop automatically. Reason behind this is our website features won't work in IEmetro. our site is built in Aspx and cs code, java script and uses some jquery at times.
Does anyone have an idea how we can achieve this?
You don't have any control over what browser the user is using; and there is no reason why your site should not work in Internet Explorer in the Modern UI (formerly 'Metro'). The two browsers are nearly identical in just about every way.
If you're having problems working with Internet Explorer 10, please ask a more specific question here and/or work through the Internet Explorer 10 Guide for Developers.
I would also be interested in this.
IEMetro unfortunately has a number of features disabled, and shows javascript alerts differently drastically altering the user experience.
I installed Microsoft SharePoint and Project PWA on Windows Server 2008 R2.
When I want to open Library in Windows Explorer, I randomly get an error:
Your client does not support opening this list with Windows Explorer
When I open IE it's working for 1st and 2nd time, but after some clicks it's not working anymore and I need to restart IE and then it normally works for couple of times.
When it not working through Sharepoint it also not works via \server\DavWWWRoot\PWA and oposite.
I'm searching through the web for weeks and didn't find any solution.
Do you have any idea what should be wrong here. Any suggestion is welcome :)
I had the same exact issue with Windows 7 and explorer view. The following steps resolved the issue for me:
First - be sure that the Web Client service is running (run>services.msc).
Next - In I.E. check Tools>Internet Options>Security>Local Intranet>Sites>Advanced and add the site that you want to use explorer view with.
This finally fixed it for me. I hope that you have already found a solution to this issue! I was surprised at how difficult it was to find a solution to this problem!
This error message is a symptom to a billion different problems.
I solved this problem when I realized my XP32 box could do this just fine with IE8. So I reverted to IE8 in 7x64 (you have to do it by uninstalling updates for IE until you're back at 8) and it didn't work. The build versions were different and on the 7x64 "about" box it said IE8 was using 256-bit cipher while in XP32 it had 128-bit. That to me was a hint that there may be 64-bit issues even when you run the 32-bit executable.
Then I found this hotfix so I reinstalled the windows update for IE10 and then installed this hotfix. Now I'm able to open the TeamCenter site in question in windows Explorer. IE10 reports it's version 10.0.9200.16686. I cannot guarantee that it was the hotfix alone (and not also the reinstallation of IE10) which fixed it. But I'm willing to bet it was the hotfix alone.
In XP I found it impossible to then map this network location to a drive letter, as mapping doesn't like URL's. However in Windows 7 you can transform the URL so that it is interpreted as a Windows share. If the URL of a given folder is of this form:
https://somesharepoint.com/folder1/folder2/folder3
you can also access it as
\\somesharepoint.com#SSL\DavWWWRoot\folder1\folder2\folder3
and, in this form, it can be mapped to a drive letter.
I do have issues at that point that even with IE10 open and logged in to the site I see some random time-out like problems and I get kicked off (and prompted to log in again in IE10). My situation is complicated because the site I'm accessing requires an Exostar token to log in, so I have to log in via website no matter what.
If it helps any one do the steps suggested above:
Make sure to use 32 bit internet explorer (program files (x86)/internet explorer).
Like was mentioned above Web client must be started.
You may also need to add your site to trusted sites in internet explorer.
Make sure enabled protected mode in internet options is disabled.
This is what finally fixed it for me: Check "Keep me signed in" on the login page. This was the key for me. Will not work without it checked in my case.
I had the same symptoms, and it turned out I don't have a root site collection. Creating one solved this for me.
Summarized the troubleshooting steps here:
http://letitknow.wordpress.com/2012/07/22/your-client-does-not-support-opening-this-list-with-windows-explorer-error/
There can be multiple reasons for it.
One could be using IE x64 version. It won't work there.
Secondly, check out this blog:
http://blogs.technet.com/b/asiasupp/archive/2011/06/13/error-message-quot-your-client-does-not-support-opening-this-list-with-windows-explorer-quot-when-you-try-to-quot-open-with-explorer-quot-on-a-sharepoint-document-library-in-office-365-site.aspx
I experienced the same problem as well.
And I found out that if none of the above options are working, and if you work in an organisation, maybe the proxy is blocking the "Open with Explorer" option.
I did the same, and removed the proxy and it worked just fine.
this fixed it for me ( however in windows server 2008 you may need to install desktop experience i think its called)
After you log into windows go into services then restart the WebClient then see if you can use explorer view without the error " your client does not support. blah blah blah" if it does work then. make a batch file that says:
net stop webclient
net start webclient
then make a scheduled tasks that runs that batch file at start up. Have it run as a user with administrative rights, make sure you tell it to run even if user is not logged in. it should prompt you for the password of the admin account you selected. this worked for me with windows 7.
I found online where the error can occur intermittently with SharePoint 2010, however I think the SharePoint version is irrelevant. They said the client polls for a SharePoint root site and that the error occurs if one isn't found.
We have not seen the error since I created a root site even though we’re only using WSS3. Our errors began when we changed clients to Windows 7. So in our case it sounds like the issue could be the root site polling due to an IE8 security change in Windows 7.
SOLUTION:
*you on x64 bit machine* so solution is that there is no problem but you are using the wrong IE shortcut.
There are different IE types you can use (just type Internet Explorer in start search bar) and you will see..
Internet Explorer (64-bit) - won't show any sharepoint add-ons
Internet Explorer (No Add-ons) - won't show any sharepoint add-ons
Internet Explorer - only this will show sharepoint add-ons and will
work so basically make sure you always use this version of IE
I am part of the developer team for a quite a large online system using ASP.NET(4).
Asp.net Ajax completely breaks down for Webkit browsers and we are getting full page postbacks when we should be getting partial only for the UpdatePanels.
I am starting to believe it has something to do with my Application Configuration, mainly for the following reasons.
If I move the ajax enabled controls to a new project they will work as expected for all browsers, including Webkit.
I created a static .aspx file with nothing but an UpdatePanel,ScriptManager and a button making a literal visible on click.
I get no Javascript errors from any browser, and i see an http request for the asp.net-ajax (ScriptResource.axd) in both Firebug and Chrome Developer tools
I tried ye'old safari fix from this highly referenced thread
Edit: After a bit more testing and http sniffing i noticed a major difference between the test application and the actual application. The test application generates 2 additional .axd files which are not generated from the actual application. These WebResource.axd, seem to contain data related to the async postback. However this is only the case for Webkit browsers. The WebResource.axd files are generated for Firefox as i can see them in firebug
What i am asking from the community, is any ideas or suggestions as to what could be the cause of this problem and if i am correct to assume that the problem is probably on the server side
Thanks for any help
The problem was due to a deprecated config file that's used to limit the content that bots/spiders/crawlers receive, which was loading by mistake thanks to our lovely inhouse CMS
In short if u get behavior similar to my case, check your or configs
I was having a similar issue however my problem was with all browsers and not just webkit. I ended up going through and tearing up the web.config file and found out that a line: <xhtmlConformance mode="Legacy"> was preventing webresource.axd from working properly. The fix was to simply remove that line from my web.config file.
For a little more information on xhtmlConformance, visit http://technet.microsoft.com/en-us/librarY/ms228268(v=vs.85).aspx.
If you scroll all the way to the bottom you'll notice it explicitly states that it causes issues with webresource.axd and scriptresource.axd.