I have an oldish asp.net app. That is behaving differently in IE8 then IE7, even in IE7 compatiblity mode.
The app contains several User Controls that make use of the System.Web.UI.WebControls.Panel, it seems to me that IE8(inc 7 mode) render the panel as tables, but in IE7 they are rendered as divs.
Seems to me that ASP.Net is not identifying the browser properly, does anybody have any pointers on how to fix?
Look at this
http://msdn.microsoft.com/en-us/library/x3k2ssx2(VS.80).aspx
Overriding Browser Type Detection
If you want to explicitly control how
the page is rendered instead of
relying on automatic browser
detection, you can set the page's
ClientTarget property. You can set the
property declaratively as an attribute
of the # Page directive for that page,
or you can set it programmatically.
The value of the ClientTarget property
is an alias for the type of browser
you want to render the page for. For
example, to force the page to render
for Microsoft Internet Explorer 6.0,
you can use the alias uplevel. The
alias must be defined in the
clientTarget Element (ASP.NET Settings
Schema) section of the configuration
file. The predefined defaults are ie5,
ie4, uplevel, and downlevel.
By specifying the alias downlevel, you
can force the page to render HTML
3.2-compatible elements no matter what browser has requested the page.
Similarly, by specifying uplevel, you
can force the page to render CSS style
attributes even for older browser
versions.
You can create additional aliases by
defining them in the Machine.config or
Web.config file, which enables you to
create custom browser definitions. For
more information, see ASP.NET
Configuration Settings.
Related
my xPages app (with oneUI theme set) works perfect when I use e.g. this URL:
https://testserver.xxxx.xxxx.com/app_folder/Home.xsp
and then our Domino admin mapped it to a new URL
https://myApp.xxxx.xxxx.com
that by default opens Home.xsp page
but now I see several UI issues - some icons/images are not shown, some controls displayed incorrectly.
What could cause this problem? It's the same Domino server but just two different ways to log in. Is it something related to "XPages Resource Servlet" configuration? Where can I check it?
For example. I have an image on xPage that has following resource:
"../../oneuiv2/images/sortDescending.png"
then when I log in through https://myApp.xxxx.xxxx.com - it doesn't show the image...
OK, then I replaced it with:
"/.ibmxspres/domino/oneuiv2/images/sortDescending.png"
same result.
but this works:
"/.ibmxspres/global/theme/oneui/images/sortDescending.gif"
I can replace all images/icons with new resource URLs but anyway other standard controls are not shown correctly..
Based on our short discussion your problem is in wrong URLs.
So why one URL works and the other one doesn't? Concatenation, in my opinion. Browser, JS frameworks (DOJO) and JS programmers in general tend to use either relative URLs or cut/concatenate URL string. This my result into URL that is not understandable by server.
In your case check URL mapping made by your admin - does it apply to all URL formats used by XPages? Are those transformed URLs accessible on server (enter them in URL bar of browser)? That is the key to get your XPage working.
OK.. it's fixed. The problem was in Virtual Server Mapping document.
Names.nsf -> Web -> Web Configuration -> Virtual Server -> Mapping tab...
we had to set
HTML directory: domino\html
which was
HTML directory: /myappdbname.nsf
instead
There is an app with a default grails.plugins.springsecurity authentication. When I enter login/password in Opera [12.14] it offers me to store the login/password for the page, while Chrome, FF and IE don't.
Does this have to be configured on the page somehow or is this browser-specific?
That's intentional, as a security precaution - it's due to the nonstandard autocomplete='off' attribute in the form tag. Apparently Opera ignores it, while the other browsers do the right thing. If you want to allow this, remove the attribute from your auth.gsp file.
I have a chrome extension where the popup.html simply has an iframe that loads a page.
I want to allow users to select their language, and as I'm helping a charity do this each language page is very different as they need very different content based on the country!
Therefore, I can't just replace some of the fields like the google developer page example does; I need to change the page that is loaded in the iframe.
e.g. In my directory where the pages are stored I have english.html, german.html, spanish.html all of which are completely different pages.
By default the english.html page loads in the iframe, but the user should be able to go into the options file and select german so when they click on the extension the german.html loads by default every time.
Here is the jsfiddle showing what I currently have in the popup.html, and the popup.js:
http://jsfiddle.net/hemang2/EDV82/
You'll see the flickr API being called, but that's only there because I wasn't sure how to get rid of it!
So essentially my question is how to link the options file to change the default url loaded in the iframe.
Use the setPopup method: http://developer.chrome.com/extensions/browserAction.html#method-setPopup
It allows you to set any html file as your popup.
We are creating a custom branded Master Page in SharePoint 2010. To make the page similar to a legacy page we have implemented an html based custom dropdown navigation menu we had in place directly on the Master Page (consisted of basic HTML elements ULs and LIs with A tags styled with a CSS class).
I assumed the links from the basic HTML on the page would be subject to Alternate Access Mappings currently in place, but it seems to not be the case. On a test page opened in 3 different URLs (http://sharepoint2010, http://sharepoint2010.mydomain.com, https://sharepoint2010.mydomain.com) the links from a WIKI page are modified as I expected, but the links from the Custom Navigation Menu (plain HTML on the Master Page) are not modified.
I can see where that would be useful... But is there a way that I can add links on the MasterPage in a way that SharePoint parses them first, making them subject to Alternate Access Mapping translation? I tried placing a link inside a SPLinkButton control, but it didn't achieve the desired behavior.
e.g.
<ul id="navmenu">
<li><SharePoint:SPLinkButton runat="server" NavigateUrl="http://sharepoint2010">sharepoint link</SharePoint:SPLinkButton></li>
<li>sharepoint2010</li>
<li>test</li>
</ul>
When I access the page via https://sharepoint2010.mydomain.com the links above are still http://sharepoint2010 rather than https://sharepoint2010.mydomain.com
Any thoughts?
Thanks,
Victor
EDIT (clarify):
I was planning on using relative links as a fallback. But for the purpose of what we are doing it would be more maintainable if we could keep the full links and use AAM.
I'm aware that standard relative links are a possibility. I was hoping to identify if there is a way to use AAM on Master Page content (or even on Content Retrieved from External Services down the road) by providing a specific link syntax, or control framework.
There is no need to re-insert the host name if your links are on the same domain and you're not using managed paths. Keeping your links relative will ensure that any bindings in IIS and AAM setup in SharePoint will work without any additional work.
Otherwise, I would heavily suggest to use the available ~sitecollection and ~site SPUrl token to retrieve the current site collection url or current web url. You need to wrap it in anything running server side as the expression will be handled ... server side.
eg:
<asp:Literal runat="server" Text="<% $SPUrl:~site/press-releases/ %>"/>
Hope it helped
When you use the NavigateUrl= attribute of the SPLinkButton, SharePoint renders a simple anchor with href= instead of regular PostBack JavaScript code. Alternate access mapping do not play a role here.
If its simply relative links you want, then leave out the dns entry altogether (ie the bit of the url you are switching with your AAM) and begin the url with a forward slash to make it relative. If this doesn't meet your needs, the way Sharepoint does it is with a relative url token. Have a look in v4.master for the tilda character followed by 'site' or 'sitecollection' which refers to the current web and site collection respectively. Copy this method. For more details, look at this link: http://msdn.microsoft.com/en-us/library/ms473643.aspx
I have a WSS 3.0 system using SSL where every page is supposed to be served as https. Almost all pages do come out as https, but in certain cases I click on a link and that brings up an http version of a page (which does not load). In those cases I have to put the 's' in by hand to get the page to load. Places where this happens are:
/_layouts/newgrp.aspx : when I try to create a new group, it takes me to http://server/_layouts/newgroup.aspx, although it should be https. The page does not load at http. It does load if I change the url by hand.
/_layouts/edtgrp.aspx : same thing as newgrp.aspx
if I go into a document library and view version history for a file, the URLs to the individual versions of that file are http. Interestingly, the browser status bar also indicates http when I hover over them (so it seems that SharePoint gets confused when it generates the links, rather than when I click on them)
To fix this, I have tried adding some javascript to the DOM that searches for instances of http and replaces them with https. This works in some cases, but there are some places where javascript can't reach, for example when SharePoint provides the target URL in response to a POST request, which I think is the case with newgrp/edtgrp.aspx.
I have also tried adding ISAPI filters to redirect pages from http to https. This seems to cause redirect loops, and in any case I'm not sure if such filters would preserve querystring or POST information.
Has anyone seen this problem?
Update: We have switched to ISA from Squid, and the problem continues in the version history, but not on new group or edit group. We have not seen any improvement yet from changing AAM settings.
Places where this is happening in ISA:
"Version History" under item in list or document library
"Manage Permissions" under item in list or document library
"Alert Me" under item in list or document library
"Add Users" menuitem in "People and Groups" page
"Group Settings" menuitem in "People and Groups" page
"Edit Group Quick Launch" menuitem in "People and Groups" page
"Set Up Groups" menuitem in "People and Groups" page
"List Settings" menuitem in "People and Groups" page
Not sure if this is it, but have you checked your alternate access mappings to make sure they say https instead of http?
I would echo the suggestion to check your Alternate Access Mappings. Is the SSL being done on the SharePoint Front Ends, or is it being done via a piece of dedicated SSL hardware?
Use an HTTP Module to modify SharePoint's output so that links are always changed to https. Such a module can plug into IIS and modify the HTML of anything rendered. I've used this technique to make SharePoint XHTML compliant and it works well.
Even better, almost all of the work has already been done for you. The UrlRewritingNet module is open source and available for free download. It should work fine for your SharePoint site. This tool has great documentation and uses regular expressions to match which URLs to alter. It should be pretty easy to write one for your case, e.g. ^http://. There's also many more advanced options you can take advantage of if necessary.
If you'd prefer to write your own then there is a good article called Rewrite.NET -- A URL Rewriting Engine for .NET on the 15 Seconds site.
Finally, if you're using IIS 7 you could try its URL Rewrite Module. I've never used this myself and don't know if it works with SharePoint, but it's the most UI-driven solution available.
Add a redirect in IIS from http to https. Every time you access that page it will redirect you to your https page instead.
I would also suggest placing WSS on another server to see if you have the same problems. If you don't, you might need to rebuild/migrate your stuff over.
Alex answered this question with an approach that I think will generally work. Here is how I fixed this specifically.
It looks like when a SharePoint aspx page is loaded, it populates a javascript structure of type ContextInfo (defined in init.js), which is instantiated in the variable ctx. That structure has a member called httpRoot, which is later used in core.js to build menuitems in various dropdown.
This ctx.httpRoot is for some reason populated in javascript in the aspx files created by SharePoint with a line like this:
ctx.HttpRoot = "http:\u002f\u002fsubdomain.domain.com";
Yes, it has Unicode slashes and it has http instead of https. I have no idea why. But, fixing this line of javascript seems to fix the problem.
I changed the line by adding a URL translation rule in ISA that converts http:\u002f\u002f\ to https:\u002f\u002f\ . I suspect that an HTTP module that makes the same replacement would also work. Or possibly some well placed javascript that reassigns the variable at some point.
I still believe this is not ideal and there must be a more appropriate way to fix these links.