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
Related
I have absolutely no idea why, but on 2 websites (2 websites that I professionnaly work on, and they havent been hacked or compromised), my Chrome console keeps clearing every 500ms.
Which is pretty annoying.
I desactivated all extensions. Tried private browsing. It's the same thing.
I uninstalled chrome as well as my extensions. Same.
When I try to reproduce it on someone else's computer, I cannot.
When I use another Chrome session the issue does not happen.
I have absolutely no idea how to get rid of this or what is the exact cause of the issue.
The code running is :
setInterval(function(){console.clear();console.info('Console was cleared by browser extension.');},500);
Since I unfortunately do not seem to find the reason, my only question will be : would there be a way to desactivate that code or postpone the setinveral to a bigger number?
Thanks !
In Chrome, on the developer tools, click on the settings icon, and tick the the "Preserve Log" option so the console is not cleared.
If your websites happen to be ecommerce (Magento specially) I'll advice you to check your code well for unknown js. This is one of the "symptoms" of the Magecart credit card skimmer. Preserve log option
I'm working on a Rails app and was updating a page.
The page has a whole bunch of background images defined in css. When I refreshed the page (cmd+r on the mac), nothing changed. When I went into the Chrome inspector and unchecked then rechecked the css rules, the images appeared. Also, if I opened a new private browsing window (cmd+shift+n), the images all correctly displayed.
Am I running into some weird kind of cacheing issue?
Chrome: Version 21.0.1180.89
Mac OS X: 10.8.2
You need to do a hard refresh that bypasses the browser cache. I don't know the key combination on a mac, but it's probably similar to Windows: ctrl-shift-R. This is not the same as a normal refresh (ctrl-r on Windows) that does not bypass the cache.
Aparently on a Mac the equivalent key combination is cmd-shift-r.
Try forcing the browser to load your new css file. I usually add a query string (?v=1.0) to the link, like this:
<link rel="stylesheet" href="style.css?v=1.0" "type="text/css"/>
and then I change the number (?=1.1) each time I've done some changes in the css file.
This usually fixes it in Chrome.
Hope that helps!
I have this issue from time to time myself, especially when I am making lots of changes, I find clearing your browser cache works best, unless you have specifically set up some sort of caching.
Also make sure to check the "Disable Cache" is the inspector settings.
Screenshot taken October 10, 2016. Please update if changes have taken implemented by Google.
Command + Shift + Delete
Empty cache from the "beginning of time"
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 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/
customers does not want to allow user to use back or forward button. Just a clean page without commandbar and toolbar, same for FF an IE.
Disabling them is not an option as now.
You cannot change that kind of thing in a existing window -- the only way you can make those disappear is by opening a popup, specifying they should not appear in that popup when it's being opened.
Still, note that you should not try to disable those buttons nor have them disappear : your application should work fine with them, handle their actions -- after all, it's one of the few things users have understood in browsers...
And as a user, this is disturbing and annoying :
I don't like popup windows -- and I'm not the only one who doesn't
I don't like when a website tryies to take control over my browser
It will not always work anyway.
And, as a sidenote : even if the back/forward buttons are not displayed, users can still use Ctrl+left/right or some kind of equivalent !
I know this is not easy, but a part of your work as a web-developper is to explain your clients how Internet and web-applications work... not the same way as desktop applications !
If you can force your users into IE (can't believe I'm suggesting use of IE!) you can do this trick. Try running this from the command line
"C:\Program Files\Internet Explorer\iexplore.exe" -k
This will force IE into kiosk (or full screen mode), similar to pressing F11 when in a usual browser session.
PS. I agree with the other answers suggesting this should be discouraged but there are instances (such as when the end user really can't be trusted) that this is a good solution.
No, there's no other way.
However, this is extremely annoying behavior and should be greatly discouraged. This isn't a code issue to solve...this is behavior that shouldn't be implemented at all.
My opinion here, you have a client problem not a code problem. Whatever standard is the expectation, and the user has the expectation of having their back/forward buttons, break that and you break their experience.
Ever see a Windows application that removes the taskbar? That's the equivalent...
I don't think there is a reasonable way to disable the behavior. You may get rid of the buttons in various ways, but the behavior is still there (through keyboard commands, popup menus and so on).
The only reasonable way is to make your web application follow web semantics, and make the client realize this.
many web based ERP (for example) does not tolerate people using navigation buttons. BUT these web applications handle the fact people use these buttons and do not crash. That's what you should do. If each time people use the back button, they get an error message, they will quickly stop using it.
The solution that used to work in IE was adding a startup script with one line:
location.forward();