For a specific website (internal to network, coded in XHTML) the behavior in IE6 was that when ever the window is re-sized or restored the page refreshes.
Since IE6 doesn't have tabs I upgraded to IE7 - but the problem with IE7 is whenever we switch from one tab to another, its makes the active tab's page to refresh, and this happens all the time.
After googling a bit, I found a temporary solution, (to disable the Meta-Refresh property in IE settings). This has resolved the problem to some extent but still refreshes happens.
Is there a way to permanently disable the refreshing of page when tabs are switched ?
In my opinion your solution is to use something along the lines of:
<!--[if IE #]>
Special instructions for IE # here
Rather than on restored just leave your code to refresh in resize.
Depending on what your page is doing you most likely may not need it to
refresh on resize using IE8+.
<![endif]-->
Otherwise I would just plan on the IE8+ being the used browser and not worry about what it does in IE6 anymore.
Related
We've been having an odd issue that I'm not sure how to tackle, and I think this may be related to a recent Google Chrome update, but I'd like some way of sanity checking myself before I open an issue on the bug tracker.
Problem
We have an internal web application that our users use Google Chrome to access. Starting sometime early last week, we've noticed that when users middle click links, one or more of our stylesheets gets unapplied to the page.
Weirdly enough, zooming in / out or opening Chrome's Devtools re-applies these stylesheets to the page. If you open the sources tab in the Devtools and watch the stylesheets that are loaded, when the layout is working, we're seeing the full list of stylesheets. When a user middle clicks on a link, the stylesheets area flashes and the CSS file is missing from the list. Zooming in / out re-adds the missing CSS file to that sources list and renders the page correctly.
Before Middle Click
After Middle Click
Troubleshooting
Thinking this was some JavaScript function doing this, I watched the elements to make sure there weren't any changes to the DOM (thinking we may be adding a class to our wrapper elements on accident). No DOM changes that I can see, and I'm not seeing inline styles applied to HTML elements.
Figuring that the previous step wasn't enough, I removed all the JavaScript on the page trying to narrow down what file is doing this. After removing all JS from the page, we're still seeing the same thing. Someone middle clicks a link, then the page's styles go crazy.
I double checked it in Incognito mode, figuring it was one of my extensions. It still happens in Incognito mode.
Thinking our Stylus compiler was going nuts, I double checked the stylesheets for any invalid CSS and couldn't find any. I removed the source maps from all our stylesheets thinking it may be related to that, but it didn't fix the issue either.
I've also checked for the stylesheet being affected having a disabled attribute set on it, but that doesn't seem to be happening.
Wrapup
All in all, I'm not sure what's causing this outside of a browser bug. This is something that had popped up late last week which coincides with the last upgrade of Google Chrome, which hints to me that this probably relates to that update.
That being said I've not seen this issue affect other websites, which also points to the website being the issue so I'm not sure.
Is there any other way I can narrow this down to being a Chrome issue? I've not had this happen on any other browsers I've tested. (Working on putting together a MVP of the issue that's happening now.)
Your problem sounds similar to this.
Chrome Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=647151
Should be fixed shortly.
I am having a really annoying issue where the page visibly jumps to the top and then to the previous scroll position on a postback.
Some details: I have an ASP.NET (VS 2010, .Net Framework 4.0) page that is using a set of RadioButtons in a RadioButtonList to display and hide a couple of Panels depending on which RadioButton is selected. There are also a couple of other controls on the page that cause the page to post back to the server. I have the MaintainScrollPositionOnPostback page attribute set to "true".
Functionally all of this works fine. The problem is visually the page jumps to the top when reloaded and then jumps down to the previous scroll position. But only in some browsers. I have tested this on my development machine using IE 9, Chrome and Firefox. My boss is testing it only in IE 9. On my development machine it works perfectly in IE 9 (oddly enough) but not in Chrome or Firefox. In IE the page sits there as it looked before the post back and then simply displays or hides the panel maintaining the previous scroll position the entire time. Looks great. In Chrome and Firefox, when the page reloads, it jumps to the top of the page and then jumps down to the previous scroll position and is really annoying to observe. The kicker is, on my bosses machine, she is also using IE 9. In fact it is the exact same version I am running but on her machine she is seeing the the same behavior that I am seeing in Chrome and Firefox.
I have tried adding the following meta tags, in every combination conceivable, but they have not done anything to help solve this issue.
<meta http-equiv="Page-Enter" content="Alpha(opacity=100)" />
<meta http-equiv="Page-Exit" content="Alpha(opacity=100)" />
Am I going to need to re-architect this page to use an UpdatePanel to resolve this issue or is there another way? What am I missing here?
Well . . . This is not really the answer but I solved the issue bu adding some Update Panels to the page and it works great.
I'm still curious about the issue and if someone would like to weigh in on it I'll continue to monitor this post to see what you have to say about it.
You should consider taking advatage of a JavaScript workaround that leverages the __LASTFOCUS hidden field. It is documented in this CodeProject article:
http://www.codeproject.com/Articles/17571/Maintain-focus-between-postbacks-in-ASP-NET-al
I manage ajax browser history using asp.net's(v. 4.0) EnableHistory="true" of the ScriptManager & everything has worked fine till today.
I fire my browser from localhost today and I get this error message in IE 9 (only IE)
Message:
Sys.InvalidOperationException: For the
history feature to work in IE, the
page must have an iFrame element with
id '__historyFrame' pointed to a page
that gets its title from the 'title'
query string parameter and calls
Sys.Application._onIFrameLoad() on the
parent window. This can be done by
setting EnableHistory to true on
ScriptManager.
I've undone all modifications I made today, cleared my browser cache+cookies+history+everything and deleted "Temporary ASP.NET Files" both from the Windows and Temp folders but this error wont go away.
Deleting <meta http-equiv="X-UA-Compatible" content="IE=7" /> from my master page however gets rid of the error but its not an option as a lot of styling goes wrong. The meta has been there from the start and everything has worked so my question is why now?
Any pointers to further reset my environment(e.g deleting some hidden files) or some light into what might be going on will be helpfull.
Thanx.
The ScriptManager outputs an iframe to make history management work correctly in IE7. In this case, unfortunately, there is a bug. Your browser is IE9, so it figures you don't need the iframe. But your meta tag makes the client-side behave as IE7, so it does need the iframe. It will be fixed in the next rev of .NET. Until then, you should be able to work around the problem by looking at the iframe content that is rendered when you use compat mode, or an actual IE7, and mimicking that in your page. But you need to make sure it doesn't end up in the page twice when it really is IE7, so only output it if you detect IE >= 8. Make sense, I hope? :)
I have a site, that i built through iframes, but i cant seem to use it with IE.
For safety resons i cannot give access to it, but ill explain wehat the problem is.
First of all i was forced to do it through iframes due to the webserver didnt support .net.
Heres how it looks:
http://ipdg.se/order.htm
So far so good, an iframe working good. But when i try to log in the problem starts.
If FF it goes smoothly, but in ie, it doesnt happen anything(Would normally be redirect to the same page but with session variables and showing other content) i dont know what causes this. but either IE cannot do response.redirects, or there is a problems with the iframe.. or both.
It works in alla major browsers except for internet explorer!
Some time back there was a problem like this... the iframe tag was
<Iframe src="order.php" width="450" height="650"></Iframe>
The solution was to change the src from order.php to order.html... That may not be possible in your case, but it appeared that there was an IE security setting that prohibited the dynamic page from loading.
As a previous poster said. the problem is with IE and its security check, therefore. Using server.transfer got it working.
response.redirect doesnt redirect directly to the page, it communicates with the client browser before the redirect. therefore the browser has a chance to stop the request(Lame IE).
but server.transfer doesnt do that and goes around the problem.
This may sound like a SuperUser issue, but I wrote the page in question and I'm wondering if there is something I can do to fix the problem....
I have a page in production that simlply displays data in a bunch of tables. Our employees basically go to this page to print a form with our clients information filled in for them. Today for a specific client the page is not printing. I've tried printing using IE 7 and 8 as well as Chrome on Windows XP and Windows 7. This client's data is by no means make the page longer or contain more data that others clients.
Symptoms:
Does NOT print using IE8 or IE7 on WinXP and Windows 7.
DOES print with Chrome.
The page to print is displayed fine as a far as the actual web page goes... it scrolls, there are no errors and and nothing seems to be wrong with the page.
When using IE to print, the document just spools with out actually printing out...I end up canceling the document from the printers window.
When viewing print preview the first page is displayed, but when we try to go to the second page in the print preview IE locks up.
This does not happen for every client, but when it does happen it can be reproduced.
The page is pretty long and has client info that is keeping me from just copy and pasting the markup for you guys. I am hopeing that some one else has experienced a similiar issue in IE and has some advice.
NOTE: The users are not allowed to use other browsers, so save the IE flamming please.
Hmmm, very hard to tell without markup.
Just to throw some ideas:
Are you using anything difficult on the pages, like Flash or Java?
Custom fonts / cufon?
Huge downscaled images?
opacity or IE specific crazy filter CSS rules?
A huge structure that IE doesn't manage to break up into pages, e.g. a giant table with position: absolute ?
If you use images, try turning off the images. Try turning off CSS.
A few things to try when debugging:
Switch everything over to a standard font and font size (e.g. Arial 12px).
Eliminate all CSS and JavaScript, and if that fixes it then you can narrow down from there by taking out chunk by chunk until it starts working.
If that doesn't work, try cutting down the content significantly to see if it will show up.