Embedded Signing with Safari on Mac not working as intended - docusignapi

I successfully (with much frustration) got our c# embedded signing to work on our site, however, that was before I tested with Safari on a Mac. Safari does not allow Third party sites to open in an iframe without already having a cookie for that site stored. If you either open the site beforehand or allowing all cookies, the document will show embedded. However, even messing around with that, the redirection after completion is not working. The please wait popup does not redirect back to my site. I am looking for any embedded solution that supports mac.
The process works great on windows, but does not work on Safari for Mac and is intermittent with Firefox and Chrome on mac.
I am looking for any non-iFrame embedded solutions that I could implement that should work on all platforms and browsers.

Since you have embedding working in terms of generating a URL token, it's up to you how to access that URL. We've seen developers write their own programs to view where they have complete control over the iFrame and can do whatever they like with it, and another solution we've seen is to use a web browser control.
see this SO link

The only workaround that I know of is to pop up a new browser window. I know there is work being done to make it work without cookies, but at this time the new browser window is your only choice.
Sorry about that.

Related

Way to launch a browser w/ specific webpage without using ShellExecute? (Visual C++)

I want to add a button to my visual C++ form that will open with a specific browser. So far for links I've been using:
System::Diagnostics::Process::Start("UrlHere")
Which, as standard, opens with whatever your default browser is.
I'm wondering what the process would be to force the URL to open with a specific browser and if it's possible without the use of ShellExecute?
Edit - You are correct, this is C++/CLI. Removed the C++ Tag.
Edit Edit - Apologies if it came across as misleading. Some slight elaboration;
The buttons will launch to application URL's, some of which can only be used in Internet Explorer, others that CAN (and should) be used in Chrome. This is why I need to avoid using the default browser and have different buttons using different browsers when launching URLs
Before answering the 'how', I'd like to ask the question "should you be implementing this?"
By not launching the user's default browser, you are subverting the user's decision.
Perhaps the user prefers a particular interface, and is willing to live with the incorrect renderings that come with it.
Perhaps the user has a browser addon that they really need, such as a screen reader for the blind.
You are requiring additional software installed that the user may or may not want.
Perhaps the user doesn't want Chrome. Perhaps the user prefers FireFox.
You are saying that you know which browser is best, now and forever.
What if the next version of IE makes it work with the sites that are currently Chrome-only? What if the next version of Chrome fixes the sites that are currently IE-only?
What if the site changes so that it works in more browsers?
Do you go back and release a new version of your software that changes the browser for particular sites?
You're trying to solve a problem that may already be fixed.
Both Chrome and Firefox support a addon that will render a tab using the IE engine. It can be set to automatically activate when certain URLs are seen.
Perhaps there is a browser that already works with all your sites, that you don't know about.
Therefore, my recommendation is no, do not do this. The user has decided which browser they want to use, respect that decision and use the default browser.
That said, here's how you would do it: You could use the CreateProcess method, but you're in managed-land, so you might as well use it. Use the Process class to launch the new process for you.
Process^ browserProcess = gcnew Process();
browserProcess->StartInfo->UseShellExecute = false;
browserProcess->StartInfo->FileName = "C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe";
browserProcess->StartInfo->Arguments = "http://www.google.com";
browserProcess->Start();

Sharepoint - Accessing PDF links via Chrome

Firstly let me state that I have zero experience with Sharepoint so this may be a pretty stupid question.
I started a new job yesterday and part of the induction is viewing the company literature via their Sharepoint portal. I've noticed that whenever I try to access an embedded PDF link via Chrome it seems like it's a broken link and appears to do a Google search instead. Yet when I try the exact same steps using IE all works as expected.
I don't want to raise this with my boss if it's going to make me look a little stupid! Is there some cross browser issue with PDF links?
Thanks.
Darren, try flushing the cache in Chrome, and if necessary, log off and log back into your computer. We've had the same problem with Chrome and Google doesn't seem to be fixing the problem (although they might point the finger back at Microsoft).
Yes I have the same issue with Chrome and Firefox
Sharepoint is optimized for IE and vice versa
You also can't open Files with the "Check in and Check out" functionality because only IE is able to do that from Sharepoint (Other Browsers will just Download the File)
You can try using AddOns like IE-Tab
(simply uses the IE algorithms within FF and Chrome for specific Sites)
But its better to use Sharepoint with IE

open webpage in firefox

i am not sure..is there any chance to open my webpage in firefox. for example i am browsing mywebsite using IE. when ever i click link of the page then automatically it will open in firefox. this option is not for all pages only for specified page.
thanks.
If this were the case, ie6 would have gone out long ago. The best you can do here, would be to check which browser they are using (get_browser if you are using php) and refuse to show content to people using browsers other than firefox.
Instead you could redirect them to a page explaining why they need to be using firefox to access your websites services (I guess a link to the firefox download page would be nice too)
Sorry, it's not possible from plain HTML to open a webpage in a different browser. You can, at most, open the page in a new window of the same browser.
However, what you ask is not completely impossible. You could write a browser plugin that handles links and runs the Firefox executable
I would seriously hope this isn't possible.
What you ask for is not possible , but you could display a warning to your users that the page works best in the desired browser.

Is it possible to set a cookie from a browser plug-in?

Do browser plug-ins, such as the Yahoo toolbar or others, have the ability to set cookies on multiple domains as the user browses the web? Does the browser expose the necessary access to do this to a plug-in? If this varies across browsers, that would be helpful to know as well.
Thanks!
Cookies are stored in files and real plugins (i.e. ones using NPAPI rather than the browser's addon/extension engine) can read/write files. Hence, it's possible to do for any browser this way, although not really straightforward.
Firefox exposes cookies even to addons since there are cookie editor addons (that can edit cookie for any site).
Chrome/Chromium allows setting of cookies through "content scripts" that run in the context of a page (any page) - that's only in the beta branch so far, but soon to be in stable. However, the downside is that you might have to visit the site for it to work (you could fake that using iframes).
No idea about Opera.
The only one I have found that works quite well for creating/updating/viewing cookies is Firecookie

Why does google.com look different on blackberry & phonegap vs. blackberry & browser

I'm tyring to get phonegap up and running on blackberry storm (9530 simulator). I had been testing my webapp from withing BB's built in browser, and it was looking ok, but then it totally bit once I tried to look at the some code from within phonegap, even though I was pointing phonegap to the same url (I hadn't yet gotten to the point of running code locally on the device).
I tried a test case on google and got similiar results. see below. I suspect that I'm missing something basic here. I would have expect both images to be nearly identical.
Browser
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530WebGoogle.jpg
Phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530PgGoogle.jpg
[Update]
To shed some light on what is happening, I ran the browser and the embedded browser (phonegap) against the W3 mobile web acid test: http://www.w3.org/2008/06/mobile-test/
I definitely notice differences between the two, but I don't yet know the 'why' and the 'how-to-address'.
Acid via built-in browser
(source: eleganttechnologies.com)
BTW - I ran this earlier today and got a couple more green square than just now.
Acid via browser embedded into phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBb9530PgAcid.jpg
Disclaimer: I don't know anything about phonegap, but have a pretty good theory. By default the embedded browser control on BlackBerry uses an older version of the rendering engine than the BlackBerry browser itself does.
At the BlackBerry developer conference last year, a talk was given about this, and there's an undocumented option to use the newer rendering engine. \
The option ID is 17000 (yes, a magic number, which could change, use at your own risk etc), and should be set to true. Not sure how you'd pass this option through phonegap (I'm not familiar with the toolkit) but using the BlackBerry APIs it's something like:
BrowserContent content;
...
content.getRenderingOptions().setProperty(RenderingOptions.CORE_OPTIONS_GUID, 17000, true);
I don't know the specifics of the browsers you are using, but I do know that most of the big sites will detect your OS + browser combination to decide what HTML to show you.
If Google is seeing a different user agent, you might get a generic mobile version of the HTML instead os the Blackberry specific HTML you get for the built in browser.
If you have access to a web server, try hitting it with both browser setups and see if there is any difference in the log file. That might tell you something interesting.
As we can see in your Acid tests...
One browser (the built-in one) is reporting correctly as a BlackBerry9530, and the other (phonegap) is not presenting the user-agent ["Testing with ."].
In this case, Google is providing you with the default view of their homepage, whereas when you are reporting yourself as a BlackBerry device, you will get the BlackBerry specific rendering.
By the sounds of things, using phonegap is removing the default user-agent (most probably because it's not recognising your device). As phonegap is open-source, the best bet is to get in there, and debug it and find out what happens with the user-agent when the http requests leave the device and track it back from there.
Maybe one browser has capabilities that another one does not?
Hm. By looking at the screenshot I would say that the second page is probably missing some resources. It may be missing some images, scripts and the CSS files, which would explain different l&f. Knowing how Blackberry Browser Field API works, I would guess that the implementation that uses the BrowserField was not done correctly. Just my guess. In addition to that, when the browser field is initialized the caller needs to configure it properly by enabling the appropriate browser features - scripts, styles etc. Again, the API is done in a very weird way, I have gotten myself into this trap once. When setting the options, you cannot just create one mask (like CSS | WML | SCRIPT) and make one call. Options are numeric and, I believe, non-overlapping - but you still need to call the API for setting each option independently.
Also the way asynchronous loading of the resources for BrowserField takes time to understand.
Just my $0.02.

Resources