I have an application deployed in three environments, that use the LinkedIn JS API to open the LinkedIn authentication window. In two of those environments, when the LinkedIn window opens, it immediately tries to close itself with a prompt, in IE and Edge (works correctly in Chrome and Firefox, and in all browsers (including IE and Edge) in the third environment):
If you answer "Yes" to this prompt, the window closes and the user can't authenticate. If you answer "No", then a LinkedIn 404 page is shown.
I tried changing permissions for the associated API keys, and generating new API keys entirely, but none of those changes caused the error to go away in the two environments that are failing, or caused the error to appear in the environment where there are currently no issues.
Disabling Protected Mode in IE 11 fixes the issue, and re-enabling it causes the issue to return, but there is no such option in Edge. Disabling extensions with iexplore.exe -extoff {url} does not fix the problem.
You can reproduce the issue in IE or Edge on: https://jobs.sap.com/job/Palo-Alto-Senior-Quality-Specialist-Job-CA-94301/338144501/ by clicking Apply Now > Apply with LinkedIn, entering a fake e-mail address, and clicking Start. The self-closing window should appear. You should find that doing the same on https://sap.valhalla.qa.jobs2web.com/job/San-Mateo-Support-Account-Manager-Job-CA-94401/2160465700/ works correctly, where the LinkedIn authentication window appears, ready for user input.
This has been replicated by others, both on and off of the network I'm working on. I don't see any errors or warnings in the developer tools console. There aren't any browser plug-ins, etc. installed that might be blocking something.
Any ideas as to what I can check to try to resolve this issue?
Related
navigator.mediaDevices.getUserMedia({video: true}) hangs in my tab, no errors or anything. Expected: prompt for permissions
Has anyone encountered this issue before? It only happens to me in Chrome incognito mode. Firefox private browser works as expected
It's possible you've already denied permission for the origin server you're using. Incognito has its own lists of allows and denials, separate from the usual Chromium mode you use.
To diagnose this kind of thing look at the console in your browser devtools. It may say "DOMException: permission denied."
Also, you can click on the lock icon just to the left of the URL while the page is displaying. It will show you the current permission situation, and give you a way to change it.
The Chrome dev team apparently just rolled out a new "feature" called SuppressDifferentOriginSubframeJSDialogs, which makes it so alert+confirm boxes from an iFrame on a different domain than the parent does not show up, by default: https://www.chromestatus.com/feature/5148698084376576
This means if you have an embedded form, and you relied upon the standard JavaScript alert to inform the user of errors (or a confirm to ensure they want to make a change), it now does nothing, completely destroying the UX.
Obviously we can overwrite the built-in alert and confirms with custom ones, but moving away from what is built into the browser now introduces re-designs for every UI (mobile, tablet, laptop, desktop, etc.) instead of just relying upon proven, built-in technology.
Is there a way to change this cross-domain setting, or to whitelist specific domains to override this feature? We do have access to the parent site with an external JS include file (obviously, otherwise this would be a wide-open back door).
To Disable SuppressDifferentOriginSubframeJSDialogs , which block js Dialog box pop up
If you are single users ( Windows ) :
Right click on desktop and create a shortcut
Windows will pop up a screen and ask you "type the location of the item:"....now paste those value into the textbox
"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-features=SuppressDifferentOriginSubframeJSDialogs
Click "next" then "finish" button to create the shortcut
Now you shall see a chrome shortcut created in your desktop .Close all active Chrome instance ( if exists ) then launch the shortcut and you will found Js pop up wont block anymore.
Tips :
If you want push this fix to all your cooperate domain users , you may consider use Domain group policy to update Chrome shortcut value or use custom domain logon script logic to do so
I found a setting in the latest Chrome GPO template that creates a reg entry that will deal with this and the same reg entry placed in the Edge location also resolves the error there. (at least it worked for the problem that came up for us yesterday FWIW)
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"SuppressDifferentOriginSubframeDialogs"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"SuppressDifferentOriginSubframeDialogs"=dword:00000000
The latest Edge GPO templates do not have the setting yet, but I imagine it's only a matter of time.
Today I tried it again with Google Chrome Version 92.0.4515.131 and it suddenly worked again. Can anyone confirm this?
Add for Mac users.
If you use mac OS:
Quit all running instances of Chrome.
Run the terminal application.
In the terminal, run the command:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-features="SuppressDifferentOriginSubframeJSDialogs"
You can see more details here :
https://trailblazer.salesforce.com/issues_view?title=salesforce-functionality-impacted-in-[%E2%80%A6]oss-origin-iframe-javascript-dialogs&Id=a1p4V000002BRMX
I hava situation where some javascript a web page works fine in Safari and Chrome, but fails in IE11. Unfortunately due to issues with confidentiality I cannot put the javascript up here.
In IE11 the web page's java script fails to operate correctly. By that I mean some of the javascript works and some doesn't. With no errors displayed or any other indication of whats wrong.
If I try to debug the page using IE's developers tools, all the javascript works perfectly without any errors or issues.
Searching on the net I found many people with the same IE problem - fails normally, works when debugging. The main issues they talk about is the console.log(...) statement. I checked my javascript and don't have any console.log(...) statements.
I then saw a stackoverflow thread where adding a cache:false to the $.ajax({... calls solved the issue. I added the same flag but the problem still persists.
Are there any other bugs I've not found?
The web page is using jQuery to handle most of it's manipulation of the DOM with a single $.ajax... call and a series of $.get(... calls polling the server.
How to debug your web pages.....IE11 tips.
All modern web browsers suppress scripting error messages and warnings by default. (In the early days web browsers would halt page loading/rendering and display a script error message with an alert statement)... this gives the best user experience who isn't concerned with the internal workings of web site code.
So, scripting errors will only BREAK execution if:
1. The browser debug tool is opened. and
2. The developer tools' Debug tab setting for Break on Exceptions has been turned on.
So to debug your web pages.
1. navigate to about:blank to start a testing cycle.....press f11 to display the dev tool, select "Break on all exceptions" from the dropdown (looks like a stop sign). Pin the dev tool to the bottom of the browser.
2. Return to the browser address bar and navigate to your test site (typed address of paste and go)...
The dev tool will now break on ALL exceptions and you will list them in the console tab.
IE has built-in content blocking and has ActiveX filtering (ad blocking) which can affect outcomes. You need to configure Internet Options so that the IE dev tool console will record any blocked content or security (XSS) errors.
Tools>Internet Options>Advanced tab, check "Always record developer console messages".
Also on the Emulation tab of the IE dev tool you will find the Emulation Mode (aka documentMode) that IE is using, and how it was established eg. x-ua meta, Enterprise site mode list, user Compatibility View list, etc
If you are developing an internal company website, the emulation mode used by IE may be for an earlier version of IE.. (IE8 on XP).. you should include this information with your questions.
You should also include the IE security zone that your site has been mapped to.. File>Properties menu in IE.... eg. Intranet zone as this can have different security and blocked content outcomes.
finally, the first step in troubleshooting web browser issues is to test in noAddons mode (for IE, winkey+r>iexplore.exe -extoff ). IE has built-in form-fillers and popup blockers... third-party addons can affect the outcomes expected.
We have a web portal product and contains multiple iframes, js files and css files. Every time I visit the portal using IE11, the browse mode becomes 8, as shown in F12.
The weird thing is, I checked ALL requests and responses in Network in F12 Developer Tools, and only three response headers contains x-ua-compatible. The values are
IE=Edge
IE=EmulateIE7
IE=EmulateIE7
I have no idea where IE8 comes from?
Also in our DEV portal, the same product, it shows Browse Mode = Edge, even the same three values also present. It seems the browser mode is changed somewhere else outside Network/F12. I guess it is not javascript. But what can change IE's document mode?
Could this be related to Enterprise Mode? I think this is something that network administrators can set up.
If your product is accessible from the internet, I'd try using IE11 on a computer outside of work and see what happens.
https://technet.microsoft.com/en-us/itpro/internet-explorer/ie11-deploy-guide/what-is-enterprise-mode
I am using the Google+ Javascript API log in button and it works perfectly fine in Chrome on Windows and Android. It also works perfectly fine in Safari on an iPad and iPhone. However, when using Chrome on the iPad or iPhone, the pop-up tab for the Google log in never returns after clicking to allow access. It seems to be submitting the form to the pop-up tab and never directing back to the original tab. Any ideas?
Google knows about this issue, but currently cannot do anything about it. It comes down to window.open not working in UIWebview.
Safari is not limited by App Store rules the way all third-party apps
are. Apple can use any WebKit APIs they want to, whereas we are
constrained to what is possible using UIWebView.
They encourage anyone facing this issue to open a bug with Apple.
You can't make Apple do anything, but anyone affected by this can
file a bug against Apple about the fact that UIWebView doesn't support
window.open and subsequent cross-site scripting, to clearly
communicate demand for that support.
There's no way for people to add votes or comments to existing Apple
bug reports, so the usual advice is for everyone to file their own.
Here's the URL for bug reporting in Apple: https://bugreport.apple.com
Here is a sample bug posting to Apple provided by one of the users:
Summary: Please add support for window.open and subsequent cross-site
scripting to UIWebView. This is blocking Facebook/Twitter/etc login
workflows in Chrome for iOS for example
Steps to Reproduce:
1. In a tab, open a page that runs the code var w = window.open(yourURL, null, null);
2. The page at yourURL should try to accesswindow.opener`, such as to postMessage back to the original page
3. Don't profit.
Expected Results: New window can access window.opener.
Actual Results: window.opener is undefined.
Version:
7.0.4
Notes:
Configuration: Chrome Version (from "Settings > About Google Chrome"):
19.0.1084.60 Device Type: iPad 3
You can follow the issue thread for updates.