I've an ActiveX that runs well on IE previous 11 version.
<OBJECT id="DSV"
classid="clsid:CBBABF03-D183-11D2-819C-00001C011F1D"
align="baseline"
border="0"
width="0" height="0">
</OBJECT>
On Windows 8.1 with IE11, it works only if I launch IE as "administrator".
User is logged in Windows with administrator profile.
All ActiveX security settings are done.
First of all, I would check to see if Protected Mode is breaking it (since elevating IE also get you out of Protected Mode) - try adding it to Trusted Sites and see if that works. If not, then to investigate, I would start with Process Monitor to determine if it's something straightforward, like a file or registry write. You also should consider what the control does in determining what the best course of action would be.
Related
we have a Struts 2 application. It has a web page that works fine in all browsers except IE 11. The page hangs while loading and stops responding. How to troubleshoot the page hung issues in IE 11 ? Please give some tips.
You could use a virtual machine to achieve so. Refer to Microsoft virtual machines download page for more information. The only problem is that you will be able to test IE8 as the minimum version. There is a specific VM with Windows 7 and Internet Explorer, so if you can use a VM you will be able to test your app.
Other possible solution is to use IETester, it has some bugs, but you can even download a debug bar for it.
Hope it helps.
Finally, we were able to resolve the hung issue in IE browser. We did the following :
In IE, we opened the F12 Developer Tools and went to the Debugger tab.
Clicked on the page that was getting hung.
In the Debugger tab, it showed the line number that was resulting in error. The error was something like "method not supported". The code was
document.form.submit="post".
Made changes in code to solve the error. I modified tag with property method="post" instead of "get".
This fixed the issue.
I'm running Firefox 36.0.4 on Windows 7 32-bit. I've diabled all add-ons, extensions and user scripts before retesting this.
I'd like to step through JavaScript code that is served up in a <script> tag in the HTML document being produced by a Java (Tomcat) web server.
Unfortunately, when I select the HTML document under Debugger > Sources, the source of the page returns to the login page of the application - it appears that session information is not being used to request the source.
I stepped through the server-side code and found that the correct session cookie values were being sent for the real page request and some AJAX requests sent by the page. However, when I tried to load the page source in the JavaScript debugger, I found that an incorrect session cookie was being sent by the JavaScript debugger.
I can replicate this behaviour in other webapps, not just my own. For example, Stack Overflow:
Is this a configuration issue, or a bug in the Firefox Developer Tools?
I can't reproduce your problem using StackOverflow as an example, at least in Firefox Developer Edition ( currently version 38 ):
One thing that might help - try disabling the cache while the toolbox is open - this setting is in the developer tools setting panel ( click on the 'gear' icon at the top right of the toolbox ):
After reviewing canuckistani's answer, I downloaded Firefox Developer Edition. Seemingly, the problem was fixed.
Five minutes in, I became sick of being asked whether to remember passwords and having to manually clear session cookies (I prefer being able to do it by simply closing the browser) - it makes testing easier.
As per usual, I went to Options > Privacy > History to disable this behaviour, by setting the value to Never remember history.
Changing this setting requires the browser to restart. However, upon restarting, I once again saw the same erroneous behaviour - the wrong session cookie was being sent to the web application again.
The workaround here is to not use the Never remember history setting. I have filed a bug report at Mozilla.org Bugzilla.
I have an existing website and suddenly some days ago I can't use Google Chrome anymore for developing. When I use a standard edit and create page, I get the above error. But i'm not getting it in Internet Explorer. I use Windows 10 (all updates installed) and VS2013 with Update 4. The project is the latest MVC version. I even checked the web.config but nothing is changed. I deleted all history, cookies, passwords etc.
Anyone any idea?
I had the same problem. For me the solution was to both clear my browser cookies and to disable Adblock. Other addons may have the same effect. I believe the problem is limited to the Visual Studio / Chrome development environment and will not occur in production regardless of whether the end user has Adblock enabled or not.
Do you have a
<httpCookies requireSSL="true" />
in your Web.config? Change that to false. Then in your transforms files (Web.Prod.config, and other environments that have SSL):
<httpCookies requireSSL="true" xdt:Transform="SetAttributes" />
I'm also having the same issue in recent weeks, but it's also extending cross-browser after originating from Chrome. What's even stranger is that it still works flawlessly with the identical project on a different machine using all browsers.
I have gone so far as to uninstall all extensions, delete all cookies / data, sign out of Chrome completely and re-install it. Problem still persists.
On deployment to Azure websites the problem isn't present on any platform. My current work-around is to Ctrl-F [ValidateAntiForgeryToken] and comment out every occurrence, and re-enable it upon deployment. Annoying, but it works.
This was happening to me in Chrome, and seemed related to using the 'remember me' checkbox on login forms, and closing then re-opening the browser. The token was present on inspecting page source, but was reported as being not present during debugging sessions in visual studio. By clearing the browser cache and not checking the 'remember me' box I did not get the problem - but I don't fully understand why!!
My steps to reproduce the bug in Chrome:
Sign in to your MVC web application, clicking on 'remember me' to make it checked
Close browser
Open browser to your current retained session
Try to sign out - error happens here.
Anyway, the following solution worked for me. Inside your MVC view form, try replacing this:
#Html.AntiForgeryToken()
with:
ViewContext.Writer.Write(Html.AntiForgeryToken().ToHtmlString());
Are you on cloud platform ? chrome emits cookies from cloud domains hence the only way to do it is to map another named domain to your cloud web site
This is probably because browsers like Chrome use the Public Suffix List(https://publicsuffix.org/list/effective_tld_names.dat) to restrict certain cookies. If the domain suffix set on the cookie is shared publicly then the browser may block such a cookie in order to prevent itself from sending "unauthorized" data to other servers running on the same domain.
I've designed an SSRS report in SQL Server 2008 R2. I'm displaying the report in an MVC application using the ReportViewer control.
It is working fine in Firefox and Chrome and below IE10 browsers. However, in IE 10 the report is not getting displayed.
If I changed browser mode to IE10 Compat View in the IE Developer Tools (F12), it is working fine. Please check the attached images:
I have gone through several forum's posts, most of them suggesting to keep an meta tag in master file:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIEX">
where X is the IE Version. Some other forum threads suggests to install Service Pack 2 for SQL Server, which I tried but still no luck.
We can not suggest to end user (some of whom may be non-technical) to change the browser mode in Developer Tools.
Please help me display the report in latest IE browsers (IE10 or above) by default.
I've had a similar problem plaguing me for awhile now, and I've never truly been able to get IE10+ to display a report without using compatibility mode. I did discover a workaround though.
Instead of displaying the report in the Report Viewer, I set the display mode to open the report in another program. It appears that your report could be exported to Excel, so I would set the report to open in Excel.
In c# it would look something like this:
rp.ReportDisplayMode = "Excel";
I'm tasked with fixing a bug on the mobile version of a project I just came on (and still learning my way around it). Its a heavy use 24/7 kinda job, so not keen on the trial and error guess/upload/test style of debugging.The bug is that almost none of the controls, particularly tabs, respond to user "clicks" on the ipad. The app was developed in asp.net MVC4 and I work on windows 7 in vs2012.
We are not a mac shop, but still need to support the Ipad and phone.
This is probably a simple question: but my searching keeps taking me
here: iOS6 - removed console log for IPad - how to use web inspector on windows?
and here: Accessing iOS Safari Web Inspector from Windows Machine.
I need a way to gather actually diagnostics, like what would be available in web inspector, without having to acquire a mac.
Use weinre. It runs a webserver that that can repond to a bookmarklet or <script> to run a remote inspector.
weinre is a debugger for web pages, like FireBug (for FireFox) and Web Inspector (for WebKit-based browsers), except it's designed to work remotely, and in particular, to allow you debug web pages on a mobile device such as a phone.
Get NodeJS, NPM, and a webkit-based desktop browser to run it.
Homepage: https://people.apache.org/~pmuellr/weinre/
Docs: https://people.apache.org/~pmuellr/weinre/docs/latest/
To install with yarn:
yarn add --dev weinre
then because it's no longer maintained, you may get TypeError: mime.lookup is not a function when you try to use it, then you have to edit node_modules/connect/lib/middleware/static.js and change require('mime') to require('mime-types') on line 21 (thanks). Then start with
yarn run weinre
If you now open the url showed there, you'll see the bookmarklet you can use etc. (Note: If using this from other computers, you may have to open local firewall ports, and if debugging a https site you may have to add a reverse proxy with cors headers.)