I have an ASP.NET webpage that is rendering many (~3000) <input type="text"> textboxes on a single page (that are client-side only, i.e. do not need to postback). In Chrome, if these inputs are wrapped in <form> tags, Chrome will hang while I'm typing into the textboxes. (Duration is proportianal to how many textboxes are on the page). Firefox and IE do not have these problems.
You can view samples of my pages in the following links:
Slow page (with <form>): http://jsfiddle.net/ZXcMs/
Fast page (without <form>): http://jsfiddle.net/5V74U/1/
My questions:
Why is this? What exactly does <form> mean to a web browser?
My ASP.NET project requires the use of a <form> tag. How else can my site be made compatible with Chrome?
Nathan I just try the pages that you give and they not hung at all to me. I use the Chrome version 19.0.1055.1
Now what I remember is that I have a similar issue and was because of an extension !
Google Chrome is still developing and go from version 1 to 19 in one day :) and extensions are not so good tested with this version change. So extension that have been written just before some months maybe have problems now.
Disable all extensions to see if the problem goes away, and then if it does, just locate the one that have the issue.
Related
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'm getting a difference in my design view and what the actual preview displays. I'm pretty sure my code is correctly reflecting what appears in the design view, but incorrectly in the browser preview. Any suggestions on how I can fix this and why this is happening? The black content area should be below the header and buttons.
Master Page Design View: http://imageshack.us/photo/my-images/30/designview.jpg/
Browser Preview: http://imageshack.us/photo/my-images/638/browserpreviewz.jpg/
IE and Chrome both display the same behavior.
Here is the code of the master page: (because of '<' I'm having getting asp code in here...how do I enter it in as code sample?)
Personally, I find i can never trust the web preview in visual Studio, so while this is not really an answer to your specific question I recommend you always use an actual browser for preview. :)
Your CSS might be cached. When you are looking at the web preview, It is worth a try to reload the page and the CSS by clicking ctrl-F5 (not just F5). This worked for me a few times when I felt that my CSS changes are not being rendered in the web preview.
Can anyone explain why my input type="file" is greyed out in IE8 but not IE7. It's still usable, but you can't actually type in the box any more.
<INPUT id="fil1" type="file" size="44" name="fil1" runat="server">
IE7:
IE8:
<input type='file'> is treated as a special case input field in all browsers. It looks different in pretty much every browser, and it can't easily be styled using CSS.
The reason for this is that the browsers consider it to have security issues, for example, where users may upload files without realising it. They therefore enforce a standard look and feel for it, so that the field will always be recognised for what it is. They also prevent CSS and Javascript from having access to the field so that they cannot modify the how it looks or alter the value of it.
In the case of IE8, the browser developers have decided that the only way the user should be allowed to access the field is via the file selector button. This is a concious decision by the IE developers to increase security. There's nothing you can do about it.
For the sake of curiosity, you should try seeing how <input type='field'> is rendered in other browsers - Firefox, Safari, Chrome, Opera... you'll be surprised by how different they all are in how they render this. It's probably the single most inconsitently rendered element.
Because the textbox is readonly; which is the expected behaviour. You can select a file using the Browse button.
Typing is not an option, since the file is on the users pc and the webpage cannot directly access those files.
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/