So I am implementing oauth login and it works on every browser except microsoft edge. Chrome also has an unnoticeable error that might prove important.
I call:
window.open(facebookoauthurl)
from https://www.example.com/home/index This then opens a new tab. In this tab the user logins and is redirected back to https://www.example.com/externalauth/callback
The callback page is empty except for:
try {
top.window.opener.loginMethods.handleRedirect('#Html.Raw(Model.RedirectUrl)');
} catch (e) {
alert(e);
top.window.opener.location = '#Html.Raw(Model.RedirectUrl)';
}
window.close();
This works in all browsers except edge where top.window.opener is not defined. If i extract this script into a function which is executed when you press a button google chrome shows an alert saying: "security error blocked a frame with origin from accessing a cross origin frame" however once you dismiss the alert it executes the code anyway and the parent tab gets data passed to it!
I have read into the causes of this. The domains are exactly the same, I have even gone to setting document.domain on both pages to be exactly the same. It appears in various other examples that an issue can arise going through different zones in IE/edge but these are both in the same internet zone. It also works perfectly fine running on localhost in edge. The code will work if facebook and my site are in trusted sites.
There were multiple suggestions of using showModalDialog to achieve this but that is obviously now deprecated. I know this has to be possible somehow but I am absolutely stuck now.
It is just based upon: http://www.codeproject.com/Articles/1006013/OAuth-Social-Logins-Facebook-Google-Twitter-PayPal
Related
Apologies that this is a long question, I wanted to make sure it was clear what the problem is and, just as importantly, what it isn't - because I know there are a lot of questions that seem related but they don't seem to be about quite the same issue:
The web application we're developing at work needs to open a URL in a new tab when the user presses a particular button, after an API request has completed. The URL in question happens to open a PDF document.
We're aware of the issue with popup blockers, so are opening a blank tab straight away when the button is pressed, then setting the location to the URL a short time later after the API request completes. And this is working fine on desktop browsers as well as on Safari on iPad.
But there is a peculiar problem with Chrome on Android - at least we have observed the problem on Galaxy tablet versions 6 and 7. I'm aware that for some reason Chrome on Android does not have a built-in PDF viewer - however, it seems that accessing the PDF should trigger the OS to ask the user which app they want to use to view the PDF, and we are OK with that. What we do not want - but what is happening at the moment - is the PDF simply getting downloaded in the background, and the user not being given the option of viewing it directly.
From my research on how browsers handle PDFs, it seems this behaviour is dependent on various response headers - notably Content-Type and Content-Disposition. But we are doing this correctly as far as I know - the Content-Type is application/pdf and there is no Content-Disposition header so it should default to "inline", ie opening up to view rather than downloading. And I have tried adjusting the backend to send this header explicitly, both with and without a filename parameter - with no change in observed behaviour.
I strongly suspect this is a bug with Chrome and/or Android, but I cannot find it clearly reported anywhere. The key thing is that there is a delay in setting the URL - because if I put this directly into the console (which I can do when running browserstack from my desktop; not sure if there's any way to input it into a real device directly):
function test1() {
window.open("url/for/my/pdf");
}
this works fine (the device prompts you with a choice of how to open the PDF)
but not with either
function test2() {
const newTab = window.open();
setTimeout(() => {
newTab.location = "url/for/my/pdf";
}, 1000);
}
or even with this, non-asynchronous, version:
function test3() {
const newTab = window.open();
newTab.location = "url/for/my/pdf";
}
Both test2 and test3 above, when called from the console, result in the PDF being downloaded rather than viewed. And this isn't specific to our endpoints - I've tested it with URLs to various random PDF documents I've found online, and the same behaviour occurs.
So my questions are:
is this a known bug with Chrome or Android?
whatever the answer to 1) above, is there any straightforward workaround which will ensure the user is always prompted to open an application to view the PDF, rather than simply downloading it? (Bearing in mind that we can't avoid the delay between opening the tab and setting the location - or at least this is our preferred way.)
Thanks in advance!
My question is different from the other posts similar to this.
AutoCAD offers developers a means of displaying a URL page inside the application. I created an intranet site for my company with the hopes that users can explore via desktop browser or their AutoCAD application.
The problem is that the browser AutoCAD uses is Chrome version 33 (currently its at 84) - there is no way to update or change the browser either.
I have no way to "inspect" or debug the site inside AutoCAD - and I've come to find out there are many difference in v84 and v33. I'm trying to diagnose errors right now but again, I have no way of accessing the console logs inside the AutoCAD Browser.
Is there a way for me to "alert" any errors that the console is trying to give me? (ie: the page can't find a script reference, there is an unexpected '.', etc...)
NOTE - my site runs great on the most updated Chrome browser (v84 on desktop browser), but some little things are not working right in v33 (in AutoCAD Browser).
If you control the website you can attach a listener on the window to listen for any unhandled exceptions. Add this before all other scripts to make sure everything is captured.
window.on('error', (e) => {
// if error is intresting, do work.
alert(e.message);
});
The handler accepts an ErrorEvent object.
NOTE - This will not capture errors that are triggered in scripts across domain. For example if you are loading google maps, and an error is triggered within that script, you will typically get a 'Script error.' and no other info. This has to do with cross origin policies. You can read more here.
If you need to specifically to capture data sent to console.error you can simply proxy the function. This may not capture anything except for code that explicitly calls console.error and is not recommended.
const error = console.error;
console.error = (...args) => {
// alert(...);
error.apply(console, args);
}
I'd like confirmation, should I be able to set onebeforeunload on an opened window in IE11.
Edit: some extra info
The page opening the window is located on a page such as
https://subsub.sub.company.tld/someapp/#/somepage
The window is opening an url like
https://subsub.sub.company.tld/someService/SomeIdentifier?timestamp=214124
As far as I am aware this should be fine?
var pop = window.open("url-on-same-domain");
pop.addEventListener("beforeunload", function() {
//something here
}):
Currently I can't add this listener due to Permissions (as far as I know this shouldn't be an issue on a same-domain environment). It does however have a unverified SSL connection e.g. defect certificate due to dev env.
Error: Permission denied
... some stack which goes back to pop.addEventListener
I also tried setting pop.onbeforeunload = function(){} but this is being ignored.
Anyone who can fill me in on this? We also have an issue on our test environment which is on localhost where attaching the evenListener won't work on IE and Edge.
My problem was caused by the popup opening a PDF File. In IE there is never access to Files opened in a window.
We worked around this by wrapping the file in an iFrame, which might sound nasty, but we needed to be able to display custom messages sometimes so it was OK for us as no other solution was workable.
We've got a site where we Response.Redirect to a page (the cart page) and for some reason, the Page_Init and Page_Load functions aren't being called for that page when using IE8. Even if I put the cursor in the URL Bar and hit enter, they still aren't getting called. When I hit F5, it gets called. When I use another browser (including IE9 in IE8 mode), they get called. I ran Fiddler2 to inspect the traffic and no traffic occurs when I click on the URL bar and hit enter even though you see the world icon spin and it seems to be doing stuff for a 1/2 second.
What could cause this behavior? Seems like it has to be Javascript and/or an Update Panel that's intercepting the Page_Load.
Specifics: The site is an AbleCommerce and the page is the cart page. We've customized the product selection process.
I'm able to replicate the problem on our test instance of the site so I added Breakpoints to both the Page_Init and Page_Load functions of the custom control that loads the cart. Under IE8, I can put my cursor in IE8's url bar and hit enter and the breakpoints never get hit. Any other browser, they get hit. Running IE9 in IE8 Browser Mode, they get hit. But in IE8, they only get hit when I do a refresh (F5).
I'm thinking this has to be a Javascript or Update Panel issue. There are no Javascript errors showing in the Firefox Error console or in IE8.
Any thoughts on what might be causing this? Or how I can troubleshoot it?
Try to call your page with an extra parameter, like &_=xyz where xyz is always fresh (like the current time tostring). If the page is refreshed with an extra parameter, you have a caching issue where the browser caches too aggressively.
Why is could be so - it's hard to say. It could be a jquery issue where you call the url with full caching enabled and then the browser pick up the caching setting internally and never calls back your page.
The current accepted answer is a good way to debug this issue. But a better solution to this issue is that you should set the HTTP headers on the response to tell the browser that it should not cache it.
Take a look at the accepted answer for this Stack Overflow question to learn how to set the cache headers in most popular languages:
Making sure a web page is not cached, across all browsers
I had your exact same problem... It's because the heavy caché options in IE. So instead of using the random variable, I set all response cache to false en every postback like this:
protected void Page_Load(object sender, EventArgs e)
{
Response.Cache.SetNoStore();
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(DateTime.Now);
Response.Cache.SetLastModified(DateTime.Now);
Response.Cache.SetAllowResponseInBrowserHistory(false);
....
}
Source: Page_Load called in Firefox, but not IE
I'm working on some old AJAX code, written in the dark dark days before jQuery. Strangely, it has been working fine for years, until today when it suddenly stopped firing its callback. Here's the basic code:
var xml = new XMLHttpRequest(); // only needs to support Firefox
xml.open("GET", myRequestURL, true);
xml.onreadystatechange = function() { alert ('test'); };
xml.send(null);
Checking the Firebug console, the request is being sent with no worries, and it is receiving the correct XML from the request URL, but the onreadystatechange function is not working at all. There's no javascript errors or anything else strange happening in the system.
I wish I could just rewrite everything using jQuery, but I don't have the time right now. What could possibly be causing this problem??
A further update - I've been able to test my code in a different browser (FFx 3.0) and it was working there, so it must be a problem with my browser. I'm running Firefox 3.5b4 on Vista, and I've tried it now with all my addons disabled with no luck. It's still really bugging me because I was working on this site yesterday (with the same browser setup) and there were no problems at all...
Actually I just took a look back in my Addons window and saw that Firebug was still enabled. If I disable Firebug, it works perfectly. If I enable it, it's broken. Firebug version 1.40.a31
is the url malformed?
have you tried putting the whole thing in a try-catch and alerting the errors (if any)
is it failing on an authorization check?
does the url in question require http-auth? (though there should be state changes in this case, I'll admit)
edit:
I have a really funny thought here. Are you using firefox 3.5 beta4? I develop a firefox extension for a browser-based game and recently discovered some odd behvaviour. With my extension or firebug observing the ajax requests made from the page, the script ccreating them would never get calledback. The request would be correctly observed and processed by both firebug and my extension (I could observe what was sent and received)... but the page itself would never hear from the request again -- like it had disappeared into a black hole.
Try turning off firebug (or at least turn off listening to 'Net' for that domain) and test it again
Known Firefox bug affecting Firebug; see http://code.google.com/p/fbug/issues/detail?id=1569&q=xhr&colspec=ID%20Type%20Status%20Owner%20Test%20Summary for details :-)
It seems unlikely that onreadystatechange would stop working. Is it possible that the 'alert' function has somehow been disabled or overridden? Can you replace the alert with some code to make a visible change in the page, and check its functionality that way? (I know, its a stretch, but it just seems so strange that onreadystatechange wouldn't work!)