The paste special function in SDL Tridion 2011 doesn't work in any current web browsers. Is anyone aware if this issue will be addressed in Tridion 2013? It was a real time-saver when it was functional, and prevented a lot of reformatting that's now unavoidable when pasting from Microsoft Word or any similar programs.
Mark - For me this does work i've just looked with both IE7 and FF18.
In IE the focus of the paste special pop-up dialog sometimes is never to the front, so I sometimes have to minimise the SDL Tridion edit window to find it.
Perhaps you could provide some additional information about the browsers and errors you receive?
Also fyi the supported browsers from the official SDL documentation shows:
Web browser Supported:
Internet Explorer 9.0 Safari 5.1 for the Mac Google Chrome, latest
version Mozilla Firefox, latest version
Paste Special works properly for us in Internet Explorer but not in Chrome or Firefox.
With the 2011 upgrade we’ve been pushing users toward Google Chrome because it is so much faster than IE or Firefox and paste special not working properly in Chrome has turned into one of the biggest usability issues our editors and producers are having with Tridion 2011 (not surprisingly they like to write primarily in msword.) We'veraised the issue of Paste Special not working iwht Chrom with Tridion support back in November and received two conflicting responses from them.
In both cases Tridion acknowledged knowing about the issue and in both cases they stated they would not fix the issue in Tridion 2011. The place the difference comes in is that in the first response we received from them they said they would be fixing the issue in Tridion 2013 and in the second response we received they said they had no plans on fixing the issue.
We did look into what was going on with the code to see if it was something we could fix by hacking the UI and what we found for Chrome was the following snippet which enables/disables the paste buttons:
if ($dom.isWebkit) // couldn't get it to work in Chrome
{
delete allowedActions["Paste"];
}
So basically it would seem like Tridion tried but gave up on implementing Paste Special in Chrome
Likewise in Firefox the buttons are enabled but when you try to paste special, nothing happens. Our development manager debugged and it turned out the paste method is throwing a silent exception -> NS_ERROR_DOM_XPCONNECT_ACCESS_DENIED in the following code when executing lDocument.execCommand:
var lPasteFailed = false;
try
{
pastingWithFlag = iProcessingFlag;
if (lPasteFailed = (!lDocument.execCommand("paste", false, null) || lDocument.body.innerHTML == ""))
{
throw Error("paste had no result - possibly clipboard data unaccessible");
}
if (pastingWithFlag == undefined)
{
lPasteFailed = true; // in certain cases lDocument.execCommand("paste"...) will cause paste into the main area in IE, which will be handled in the onpaste event handler -> do not paste again
}
}
catch (err)
{
$fa.canAccessClipboard = false;
lPasteFailed = true;
self.fireEvent("warning", { source: "paste()", message: err.message });
}
We are getting a lot of internal pressure to get this issue resolved so we’re going to be re-opening the issue with Tridion support and I am planning on getting in touch with my account rep sometime in the next couple days to raise this as a critical issue with him as well.
We re-opened this issue with SDL and here is their response with regards to where/when Paste Special should work in Tridion:
IE: supported and works. Any issues can be reported and we will look into fixing it.
Chrome: not supported (Chrome does not give access to clipboard)
Firefox: There are steps here to enable clipboard access (http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/task_RECON43B1609144D94562A394BB51FAC884B9),
although we have seen evidence of Firefox closing off clipboard access
similar to Chrome
Building an extension to enable paste special is outside of R&D
current scope.
On February 13, 2013 SDL will be announcing a contest during the
community webinar (http://webinars.julianwraith.com/).
The contest will challenge the community to create paste special
extensions for both the CME and XPM.
The contest will have prices to incentivize community participation.
People are frequently landing on this page, just want to let know, there is an extension available on Community now.
http://www.sdltridionworld.com/community/2011_extensions/pastespecial.aspx
Related
One of our client is trying to generate reports with lots of sub reports, its a single page report. If they generate it for 2-3 years it works for all browsers, but when they generate it for 5 years. Report works fine in chrome and firefox but IE will not be able to load reports and show IE window "Internet explorer cannot load page".
There is no errors in eventlog or in IE console. Even Fiddler does not give any information why IE could not able to load reports. It says response 200.
Reports are generated successfully, as I can see that in log.
I am not sure why this is happening with IE(8,9,10). Please check images below
Thanks
This could be due to the memory management problem in Internet Explorer, as you are fetching the 5 year data.
There is a work around for the memory problem.
->Go IIS
->Open your reporting Website
->Check which application pool its using
->Right click on that and recycle it.
->Then try generating the report.
Not sure if it resolves your problem.
I've seen a very similar issue recently - it started a few months ago, across multiple unchanged reports, and seemed to be triggered by hard or soft Page Breaks (I found that out from a lengthy process of elimination).
That scenario was SQL Server Reporting Services 2012 SP1, via the Native/Report Manager portal.
Does your report render with page breaks?
My solution was to set the Report / InteractiveSize / Height to 1000cm. Then for each hard page break, I disabled it for browser rendering by setting the Page Break / Disable property using this expression:
=Globals!RenderFormat.IsInteractive
The result is a little untidy in the browser, but renders with page breaks in other formats (PDF, Word, Excel). Importantly it stopped the browser freezing in IE.
Personally I have moved away from the report display control. It provides inconsistent display on different platforms (al least it did in 2013 when I did the lions share of converting a project).
Instead I render to PDF (Word or Excel) at the server and use an embed tag to display the content to the user. You are guaranteed to know what it looks like on the user screen that way. A level of caching is possible and its a lot easier to work with.
I am working on 4 internal websites, everyone should be using IE but not everyone is.
Is there an easy way to force the user to use IE, ideally without installing anything new like JQuery?
Cheers,
Kohan
Addendum
I really shouldn't have to justify why i'm wanting to do this, but here goes.
This site is totally internal and 98% of the users do not have the rights to install a new browser... however there are a select few that do. This is fine for most of our sites, but since these sites are very old, they do not work in anything but IE. I could fix it for all browsers... but it is a better use of my time to just put a "hot-fix" in for now as it will likely all get rewritten next year. The site itself is also only used once a year. It's simply not worth the time investment in this case.
Thanks
Kohan.
If you really wanted to do this you could check the user agent of each request and if it's not IE redirect to a holding page explaining that they need to change browsers.
var userAgent = HttpContext.Current.Request.UserAgent;
Alternatively use the Request.Browser property.
if(HttpContext.Current.Request.Browser.Browser != "IE")
{
// do stuff...
}
You could find the browser type, and if its not IE, then do a Response.Redirect() to a generic "Use IE" page.
if (!(Request.Browser=="IE")){
Response.Redirect("UseIE.aspx");
}
You'll have to check the return values of Request.Browser though as I'm not certain without testing
I'll suggest something eretical: instead of fighting against Internet Explorer, force the users to use the Google Chrome Frame It's a "plugin" for Internet Explorer that make the page work as if they were in Chrome.
I'll quote from that page:
Google Chrome Frame is an open source plug-in that seamlessly brings
Google Chrome's open web technologies and speedy JavaScript engine to
Internet Explorer. With Google Chrome Frame, you can:
Start using open
web technologies - like the HTML5 canvas tag - right away, even
technologies that aren't yet supported in Internet Explorer 6, 7, 8,
or 9.
Take advantage of JavaScript performance improvements to make
your apps faster and more responsive.
Now your users can have IE 6.0 to work with their obsolete internal web applications AND you can work against a "unified" (you are programming only against Chrome) "modern" web browser.
I'm using the Selenium 2.0 web drivers to try and login to a page. The following code works with the Firefox webdriver just fine, it finds the fields, fills them in and clicks the button.
driver.FindElement(By.Id("UserName")).SendKeys("name");
driver.FindElement(By.Id("Password")).SendKeys("test");
driver.FindElement(By.Id("btnLogin")).Click();
However, whenever I try to use the internet explorer webdriver it says it is unable to find the element with id == UserName. I tried using By.Name, and By.Xpath as well with valid inputs but I still get the same error saying it can't find the element. I am using IE 9 so I'm aware it may be a compatibility issue, however I can't seem to find any posts or information saying there is a known issue.
I just wanted to see if anyone else was experiencing the same issue, or if there is something I'm not doing correctly that is causing my issue. Also, this is a C# .NET project.
-- Edit --
Apparently it is an issue with IE9, I removed 9 and went back to 8 and the test works. I'm still interested to know if anyone finds out why this happens or if there is a work around.
The current release of Selenium (2.0b2) does not support IE9, however 2.0b3 should be released soon and supports both IE9 and Firefox 4.
This answer may also be relevant for anyone experiencing issues getting 'clicks' to fire with IE9.
A workaround to this is to send a .Click() to another element on the page, so that the browser gets the focus, before attempting to click the link, e.g. it's parent:
driver.FindElement(By.Id("Logout")).FindElement(By.XPath("..")).Click();
driver.FindElement(By.Id("Logout")).Click();
I am trying to debug a large and complex webapp that makes heavy use of DIVs, AJAX, dynamic HTML and server-side code to do its job.
Under normal operation we do not have problems. However, when we put the webapp into an IFRAME, certain functions trigger a crash in IE7 that renders the browser inoperable (all CPU used).
What tools exist to help track down what could be happening? Loading the IE process into the debugger gives me all sorts of fascinating info about the registers, but I think the issue is in javascript.
We have tracked down one problem with the app already that involved incorrect reparenting of an element (something attached itself to window. instead of document.)
I wrote a test IFRAME page that dumps the innerHTML of the iframe into a textarea, so it can be compared during various states, but that only shows me static attributes, I can't tell what sort of javascript events are associated with elements or determine if a handler is firing out of turn.
IE8, Firefox, Chrome etc do not have the same behaviour.
Ideally I'd like something that would let me snapshot the DOM (or the javascript VM?) during a known good state, then "just before it happens" so we can figure out what's added / removed / missing / different. What is out there?
Update: I'm now trying to use the IE Developer Toolbar to track it down.
Update 2: The IE7 crash occurs following this AJAX code:
function Sys$UI$Control$get_element() {
/// <value domElement="true" locid="P:J#Sys.UI.Control.element"></value>
if (arguments.length !== 0) throw Error.parameterCount();
return this._element;
}
The return this._element; line is the last thing that happens before I lose IE.
IE Developer's Toolbar. Download it here (IEDevToolBarSetup.msi).
For JavaScript debugging refer this blog.
Some guy made a bundle that's called Internet Explorer Collection. It includes some 6 different IE browsers ranging from IE6 to IE8 in different builds. All those include Firebug (really, it sort of works) and Internet Explorer Developer Toolbar.
It was really helpful for me to debug IE7 issues.
see this link.
By placing 'debugger' in the javascript files in places where you'd like to start debugging you can debug the javascript in visual studio as well complete with trace, call stacks, etcetera.
The IE developer toolbar definitely helps alot. Visual Studios's debugger is also very good if you can get a machine with VS and IE7 on it.
DynaTrace is a profiling tool for IE7. However, it provides a great deal of information (including JS stacks), so it can also be very helpful for debugging.
IE 7 and IE 8 has built in debugging tools. Press F12 and you are ready to debug. Also firebug-firefox and chrome's inspect element options are useful/
I have a weird issue. I am opening a popup window in IE6 with SSL enabled on the server.
When the following executes it seems to lock the browser up. I know this is vague. This is the JScript that appears to be the problem. Gotta love your IE6!
function PopoffWindow(url) {
var features = "height=400,width=550,top=60,left=100,"
+ "toolbar=no,location=no,menubar=no,status=no,"
+ "scrollbars=yes,resizable=yes";
var win = window.open(url, "DSRocks", features);
win.focus();
return win;
}
This is not a problem in IE7 or Firefox. And the problem seems to be isolated to this server (with SSL). Anyone have any insight on this?
Thanks,
Nick
Is it possible that the window.open call does not return quickly enough to allow you to perform a .focus() on it, in the next line?
What happens if you throw an alert() between those two lines?
have you tried assign the window a name? IE6 sometimes does funny things when you open an unnamed window. just add a "windowName", before the url
With a problem like this, it is usually best to get back to basics. A few things to check:
How are you testing IE6? Are you using the Microsoft Internet Explorer Application Compatibility VPC Image or some workstation install where you've managed to get IE6 and IE7 working on the same PC? Having both IE6 and IE7 on the same PC may appear to work, but lead to issues like you are seeing. Even if you are using an existing VPC Image, you may want to download (or extract from an existing download) a fresh copy and see if it happens on that copy of IE6.
Have you cleared the Temporary Internet Files, Cookies and History of the IE6 install? I know it sounds obvious and stupid, but perhaps a resource that is being loaded in the PopUp window is corrupt in cache, causing the problem.
Have you disabled every Add-on in IE6?
I think the first thing to determine is whether the problem is with every copy of IE6, or just your copy of IE6 (covered by the first bullet point).
Grant,
Thanks. But the problem is with all IE6 instances that are viewing the hosted site. I will try to add an alert before the focus() to see if this is the issue. As for the windowname.. that is the second parameter I am passing, "DSRocks".
The problem was with a JSON webservice call. Please see this link for details:
http://codeclimber.net.nz/archive/2006/12/22/How-to-enable-an-ASP.NET-WebService-to-listen-to-HTTP.aspx