Just to update to help everyone; Following hot fixes has been released to fix this issue:
SDL Tridion 2011 SP1 HR2 - CME_2011.1.2.88116
SDL Tridion 2013 SP1 - CME_2013.1.0.88115
(SDLTridionWorld.com login required)
This appears to be due to a change (or defect) in how Chrome 36 handles the xlink namespace.
The Tridion vendor is working on a hotfix to adjust to the Chrome xlink handling - if I hear anything, I'll update here.
Actually, it seems that this was related to issues with Chrome 36, for which there exists a hot fix:
Chrome 36 with Tridion 2011 or 2013
Apparently I already had the hot fix but still needed to restart Chrome. After restarting Chrome, the error is gone.
According to my mailbox, I've seen this error before :)
It was resolved by re-registering the CAPICOM.DLL file that Tridion requires to encrypt/decrypt this configuration file. It looks like something must have changed recently on your server causing this dll to not be registered anymore.
Credit goes to Brandon Truong from SDL Customer Support:
As promised, I have applied Hotfix CME_2013.1.1.88718 to our environments and it has fixed the Chrome 42 issue on all of them.
Hotfix is available from SDL support or https://www.sdltridionworld.com/downloads/hotfixes/SDL_Tridion_2013_SP1_HR1/index.aspx
Good luck to everyone else who had this problem and thank you for the responses.
@Mark - There were two versions of the hotfix released, the first version only tree.js file was included and in next version (with the same hotfix number) it included two files: tree.js and FormatArea.js.
So make sure that you have applied the later version of the hotfix containing two files and also version number is incremented in system.config.
Yes - I have experienced this problem, and have also heard reports from other people of the same thing. I've been working around it by simply using a different browser.
It's starting to look like Chrome updates are a source of risk. Do you remember the problems with Chrome 36? That problem was addressed in the short term by a Tridion hotfix, and then ...
This can happen if you manually copy the url of an edit window of a Component, or any other item for that matter, (the full url including the CME address, query string) and do a Save and Close. Since you opened the tab manually, Tridion is unable to close it for you.
This is normal behavior BTW. So no, there is no hotfix.
Looking at the component with Dev tools enabled, could see this invalid markup character at the end of the namespace:
error on line 1 at column 67: xmlns: 'http://site.domain.com/folderPath/DescriptionKeyï»¿' is not a valid URI
This was not seen by the naked eye when you view the namespace that was updated in the schema source.
I later found out, that ...
@Sab you suggest it's intermittent but perhaps it's a pattern you haven't yet identified.
As Atila indicates, it's standard browser security to not let a script close a window that a user opened. See https://developer.mozilla.org/en-US/docs/Web/API/Window/close for more details.
Could the 'intermittent' aspect be the difference between a browser instance ...
Since you only see it on some Schemas and not all, it either sounds like you might have database performance issues (in which case I would expect it on other browsers too), or perhaps some wierd browser caching issue.
It might be a random kind of thing that only happens in Chrome, so if you can't get it solved, do report it to Customer Support.
To ensure ...
Although the hotfix - CME_2013.1.1.88718 has been released for SDL Tridion 2013 SP1 HR#1; but I can confirm that this will also work for SDL Tridion SP1 as well. Apply the hotfix on my SDL Tridion 2013 SP1 environment and it is working fine.
The hotfix for this issue is available on Tridion World on the downloads page for 2013 SP1 HR1 - CME_2013.1.1.88718: