After logging into Clarity 13.1, taken to the General Tab\My Work page. Can see the following:
<meta http-equiv="X-UA-Compatible" content="IE=8"/>
Go to Project list view and scroll list:
Expect: Headers to remain on screen.
Actual: Headers scroll off screen.
Repeat Project list view test: Headers remain on screen while scrolling.
Closer browser and restart. Manually set Browser Mode via Developer is not retained. Back to losing headers.
Question 1: Why is IE10 Compatibility Mode and IE8 Standards Doc mode hardcoded into the header's metadata, rather than IE10 and IE9 Standards?
Question 2: Is there any way to force an override that is permanent, unlike the temporary means used through IE Developer?
We are expecting to upgrade to 14.2 in 2015-Q1. If behavior is different/better there, can wait for it.
Are you saying you are testing IE10 and experienced this or did you have something you were specifically testing? We are on 13.3 and I have been using IE10 for months with no issues. Maybe it is something in 13.1?
Not testing - we are using IE10 corporate wide and experiencing this in 13.1.
Since are on 13.3, please login to Clarity and go to General\My Work page, then hit F12. In the html tab, expand the <html> tag and look for a meta tag with "http-equiv" - see if it says:
- <meta http-equiv="X-UA-Compatible" content="IE=8"/>
or something else.
If something else, then maybe issue is fixed in 13.2 or 13.3.
It still says that (I did it from the Overview page ):
So are you saying this is why Freezing of header columns does not work on IE and if CA would change that, then this could possibly work like Chrome/FF? CA has juts always documented that headers freezing is not supported in IE ?
However, I followed your steps, but my dropdown defaults to IE10 - I do see the Document Mode: IE8 standards. Did I not read something correctly above? My headers did not stick. I even tried changing the text above to 10 (changed it back)
Thanks for confirming 13.3 header metadata for me.
If you click on the Document Mode: pull-down and switch from IE8 standards to IE9, then headers will stick. This change also helps me with other issues, such as editing lookup based attributes in 'in line editing' views (e.g. in IE8 Standards mode I have to select the pick value twice, before it will stick and save).
I have found one issue with IE9 Doc Mode: When in this mode, I can't change the owner of a Knowledge Store folder. For this, I need to switch back to IE8 Standards Doc Mode. Rarely have to make this change.
Seems that I can't find one mode where everything in Clarity 13 works correctly in IE10. Fortunately, the issues I'm finding affect very few users - mostly a few very high-power users. So, for me and a couple others, always find ourselves hitting F12 after login in order to ensure on IE10 Browser Mode and switch to IE9 Doc Mode.
We also have IE10 roll-out to for all the users of Clarity and during upgrade from 13.0 to 13.3 patch 7, we faced the IE10 issue and received many compliants from the users. Issues reported by users was:
a. The application login page gets hanged for many users , shows white page until it is refreshed two-three times
b. For few users, overview page items showed jumpled up.
c. Clicking on HOME menu items does not responds and no action is triggered in the application
We investigated a lot on IE10 issue and found that IE10 first tries to access cached application pages even though we have made changes on the page or logged in whith another user's account, this creates conflict between the cached page and the actual application page . So, we changed the cache management settings for IE10 which resoled our issue and now none of our users are compalining about IE10:
a. From IE10--> Tools --> Go to "Internet Options"
b. In"Browsing History" section, click on " Settings"button
c. In the pop window " Temporary internet files and history settings",select " Every time I visit this Webpage" option
d. Click on "OK" button to save the changes.
e. Close the current browser and open a new browser window toaccess Clarity
This settings forces browser to pull fresh page from the clarity application and does not accesses cached pages.
Also, the document mode changed from F12 options stays only for current browser session. The above setting need to be done only once and clarity will work fine with IE10.
Please, test till option and let me know.
Yes, setting Temp Internet Files to "Every Visit to this page" does help a number of caching issues. However, IE8 Doc Mode issue is unrelated.
Several of the features in Clarity 13 and newer versions required Doc Mode to be set to IE9 - yet the HTML header for Clarity pages sets Doc Mode to IE8.
We've been running with "Every Visit to this page" set now for years - it has no impact on the Doc Mode settings, at least not for us.
Perhaps there is another switch or setting that can be adjusted, that will make IE9 the default Doc Mode for us that will then end the need to manually change it each session? Haven't found this, yet. So, current thought is that the metadata in the header must be changed.
According to my knowledge the problem is that the exact IE version is not correctly recognized in a BrowserUtils-java class and thus "IE8 " is sent as meta-header in UIServlet-class each time, even when using the latest IE11.
Only way to change this without a fix from CA (it has been fixed in 14.1) is by patching the class/JAR file.
Christopher - have you implemented this patch, and if so, do you have guidance as to where to find this file and what to change in it?
Met Sergiu last week at TRW TCD Dusseldorf, and recognized we had been in contact via LinkedIn and this community site for several years. Was good to put a real person together with the internet presence! Joerg and Tamara were there, too.
Also, discovered a CA office about 50 meters off my walking path to work, between hotel and TCD.
Regarding this question, do you know which class/jar file needs to be changed?
Sergiu told me about having met you.. the world is small
The logic for setting the content-header to "IE8" is in uif.jar in class com.ca.clarity.uif.UIServlet.
The root problem with the faulty IE browser detection is in union.jar in class com.ca.clarity.union.utility.BrowserUtils.
Let me know if you need further assistance.
Sorry to take so long getting back to you.
Will ask our team to take a look at modifying this file that you suggested. Since then, I ran across one case where after making the changes manually via browser settings, the CA PPM pages went white and stayed that way. I had seen this before on my own machine, but only as a temporary thing - refreshing always cleared the problem. This one user is located in Shanghai, China, using IE10. She was logged in from her apartment, via VPN, to our TRW network.
Restoring browser/doc values back to IE 10 Compatibility Mode and IE9 Standard cleared to problem for her.
Will need to understand root cause of her white screen and have a corrective action identified, before we can roll this out as a global change. Otherwise, I may have all of our China users seeing nothing but a white screen.
PS: Yes - small world. Met Sergio in Dusseldorf, where each morning I would walk from my hotel past the CA office to our TRW office. In our first meeting, if I recall correctly, we had one of those "Wait, are you the person on CA PPM site that worked with me on...?" moments.
if you've moved onto ie11, have your IT service desk force enterprise mode for the site. (can even set it for certain paths in the URL)
This solution can be set per user basis (as this is not a server setting but a client setting) if they have enough administrative rights without the intervention of your service desk department.
yes that's true too, generally though it's best to have a centrally managed xml file which urls are checked against.
That way it's easy for the administrators to add or take away configuration without having to push update packages to devices.
Here's some good information
Stay up to date with Enterprise Mode for Internet Explorer 11 - IEBlog - Site Home - MSDN Blogs
For 14.2 a similar header is set to force compatibility back to IE10 if you are on IE11. Something to consider there.
Thank you. My current expectation is that we will be on IE10 still when we first launch 14.2, later this Spring/Summer. But good to know for when we do switch.