Im not sure why is this happening but there is a piece of viewstate being shown on the top of my page with its closing tag.
I believe is just happening when there is some javascript code in the page, but is quite odd because has nothing to do with the ViewState at all.
Anybody knows anything about this?
Thanks,
Leonardo
any chance you could provide the offending code snippet and what precisely gets displayed on the page that shouldn't?
Based on what's been provided in the OP, it could be as simple as improperly nested tags
e.g.
<tag1><tag2></tag1></tag2>
Different browsers handle this problem differently, so it would come as no surprise that this produced unexpected behavior.
Similarly. different browsers also handle unclosed tags differently so watch out for that.
Related
I have an annoying white space below footer problem, and no matter how long I have searched for the answer I cannot find it, because it doesn't seem to be anything I can do in CSS to solve the problem. Also, the problem is not on every page... it arbitrarily selects (seemingly) random pages within the website, which made me think that perhaps it is happening as a result of some javascript code that I cannot seem to locate as being the offending party.
Anyway, after hours of scrolling through websites, I decided to load the website without javascript and sure enough the white space disappeared. As a somewhat novice programmer, I'm not really sure what to do next. I put
<div class="clear"></div>
right before in my header, and voila, it worked... no more white space on any of the pages. So technically, I guess this resolves my problem, at least visually, but since I'm a novice, I have no idea what the potential repercussions are for this? Is it okay to leave it? Could I try something else? Does this problem sound familiar to anyone? Many thanks in advance for your help! I don't know if you'll need more info than this.
Just to be clear, I'm developing a child theme in Wordpress off of someone else's theme. The website is a multisite, and the other site on the multisite doesn't seem to be broken at all, despite having nearly all the same elements. One of the few differences is a Contact Form 7 form where they each have their own instance of a CF7 form. When I attempted to add some javascript to the CF7 form, I believe that's when it broke. Since I only added it to one website (within the form itself), I think that's why only one website broke with the white space underneath. Simply removing the code wasn't enough.
By the way, I should add I have had this problem with this website before, and my (weird) solution at that time was to rename the links of the pages where the white gap was showing up... and sure enough, it worked. Obviously, as my site grows backlinks I don't want to keep doing that.
So, is my rudimentary fix enough?
As APAD1 said, the <!DOCTYPE> declaration must always be the very first element in the HTML document, otherwise it will have no effect! The fact that placing <div class="clear"></div> before the <!DOCTYPE> declaration seemed to fix your problem indicates that the white-space was somehow the related to or caused by the browser defaults for that particular HTML rendering mode.
Also, what browser are you using? You're not using Internet Explorer, are you? Different browsers or even different versions of the same browser may render your page differently.
As for the <!DOCTYPE> declaration, it is needed to indicate a particular layout mode the browser should enter.
In Internet Explorer, for example, the omission of a <!DOCTYPE> declaration may cause the browser to enter Quirks mode, as opposed to a Standards-Compliance mode. Note that <!DOCTYPE html> is used for HTML5 documents, whereas something like:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">`
...is used for HTML4. The (X)HTML doctype declaration is used to put the browser into a particular layout/rendering mode. Different rendering modes result in different CSS default styles. It is likely that some combination of CSS rules are resulting in the unexpected white-space.
I suggest you become familiar with (or at least play around with) Firebug (a FireFox extension), the Webkit Inspector ("Developer Tools") that comes in Google Chrome and Safari, and/or the IE Developer Tools. All of these tools allow you to "inspect" elements in the Document Object Model (DOM) for your webpage. These tools will even let you view and modify the HTML source code and CSS rules for elements in the DOM. (Please be aware any changes you make with these tools will not be saved and therefore are not persistent!) This means that using one of these tools, you can select your footer element and view its applied ("computed") CSS styles. This is especially helpful in not only troubleshooting your webpage or WordPress theme, but also in developing it.
So, to sum up:
If you don't place the <!DOCTYPE> declaration as the first element, then you might as well omit it altogether.
The <!DOCTYPE> declaration places the browser in a particular layout mode that has certain CSS defaults.
A combination of CSS rules is likely resulting in the unexpected white-space.
You may use browser "developer tools" such as FireBug to inspect (and modify) your webpage.
Okay, this is resolved (as of right now). The problem was a plugin conflict that was writing javascript to the footer. It only caused a problem when I added javascript to the Contact Form 7 plugin.
To resolve the issue, I edited the HTML in firebug as you suggested, Alex. Once I found out the offending plugin I disabled the conflicting scripts.
Thanks for all your help, guys. This is resolved.
I set a breakpoint in a script block of a razor view.
VS2012 attaches to IE but breakpoint has yellow triangle with exclamation mark saying:
The breakpoint will not currently be hit. The code in the document is
not loaded.
Script debugging is enabled in Internet Options of IE.
Have no idea what is wrong.
I faced this problem too. After trying many codes and things take from different posts in Stackoverflow and others websites, they have not solve my problem. When i have take a look for #robert4 solution and go back in my javascript code, i saw one error and fixed it, by doing like that, i have finally solve may problem and can now get a breakpoint in my javascript document. For those who will face this type of problem, i think that the first thing to do it is to verify your js file code by code to see if there is no error before beginning to implement each of others solutions take from differents posts.
When I had similar issue it turned out that an omitted } was the cause
(in one of the JavaScripts of the page, one of the {}s was not closed).
There was no error message on the browser console at all,
just didn't work and I had no clue for half an hour.
When I fixed the missing }, everything began to work as expected.
I"m wondering if anyone can give me some insight into a really strange IE9 issue I've been struggling with.
I'm finishing up production of a site for work - it works well in ff/chrome/ie7/ie8 with no script errors.
On IE9 the last step of the application causes the entire tab to whitescreen with no script errors or warnings. (changing the document mode to ie8 will fix the problem but is obviously unsuitable for production)
Unfortunately the site pretty complex with a ton of ajax, and in-page scripts so I can't really post the relevant code easily. I'm more trying to figure out how to diagnose this.
I've checked the IE error logs and they are empty. Web developer tools tells me nothing. The site is not using any plugins (Flash/Silverlight, Ect. ) just javascript w/jQuery.
There is a PDF being displayed in an iframe around the step where it fails - but a nearly identical pdf is displayed in the previous step (using the same method) without problem. The code fails around a call to the jquery UI window but I can't seem to get the exact line.
If anyone has a clue how to try to diagnose this further I'd really appreciate it. I can keep hunting for the bug but I've never seen this kind of behavior before and just am not sure what I am looking for.
Thanks for all the input on this. Sorry I got completely overwhelmed by a few projects at once so I wasn't able to post updates on the debugging steps.
It took forever but I finally realized that everything was crashing when I closed the dialog containing the first PDF.
One of my helper functions was opening the dialog and automatically destroying the contents on close. Normally this works fine as I'm either removing a div containing the page fragment, or the iframe.
In this situation I had a page fragment loaded into the dialog which contained some buttons and the pdf iframe. I called the .remove() method on the parent element containing the iframe rather than the iframe itself. For some reason this seems to work fine in every other browser - but in IE9 it pretty much kills the page rendering without any warning or message.
I strongly suspect that the culprit is the adobe plugin but I'm not entirely sure.
Here is the fix-
Html:
<div id="container">
<iframe src="loremipsum.pdf"></iframe>
</div>
Javascript:
//Ruins my entire week
$("#container").remove();
//Works as the pdf is removed directly
$("#container").find("iframe").remove().end().remove();
I ran into the same issue on IE11 while trying to remove an iframe in a div with AngularJS. Removing the iframe first would just cause the same issue, so I navigated the iframe src to a new page (about:blank) first, then removed the div which worked. Hopefully this helps someone with a similar problem.
Pseudo-code below:
$ctrl.iframeUrl = 'about:blank'; // change the iframe url here
$timeout(function(){
$ctrl.removeIframe(); // remove the iframe here
});
As a thing to try - see what's in the IE9 DOM viewer after it whitescreens. There's a decent chance that most of the stuff is there and just not rendering properly (or having something else rendered over it). At the very least, knowing whether it's losing a ton of stuff out of the DOM or not should give you some useful data.
I have a few annoying problems.
The thing is, that when I am looking with Firefox every thing work perfect, after I try it with Chrome, sometimes happens that the code appears one web page (it is not all the time).
So, it appears in input text it display " />" or some piece of code of java script, which is written inside input tag.
The web page is: www.kalahoo.eu (do not try it in English )
In this picture you can see the problem:
http://rhc.si/slike/problem.png
Thank you very much for you help!!!
Can you post a link to the exact page with this error?
Either way, I would imagine that if you use the Chrome developer tools, you should get pointed in the right direction. Might want to give that a try.
You seem to be improperly escaping code that's making the HTML end before the rest of the attributes are read.
Check the spot in the code where its doing that, its probably a bad ' or " or even a >.
I'm hoping some Javascript/ASP.Net gurus can give me some hints here.
I've written an application which (unfortunately) uses UpdatePanel (yes, I'm aware that was a dumb idea, too late now though, I understand it more now - even though its an intranet site I'm having troubles with it)
The site is a web based timesheet site, kind of tabular format. Anyhow, it basically saves everything in it in an update panel, and autosaves once a minute. This seems to work fine for me, but I use firefox. Other users with more timesheet entries, and IE7 have problems with IE memory usage increasing and their browser slowing down.
I ran Sieve (checks for memory leaks on a website) and it was pretty obvious it was bad:
alt text http://rodh.org/images/Programming/sievemain.png
Thats my site loaded up and left running for a bit, refreshed it at the dip and left it and you can see once a minute it jumps up a little bit. THe area on the timeline before the dip was when i was hitting the save button a bit, so its obvious what is causing it. The DOM nodes and memory both go up.
I'm using a ScriptManager.RegisterClientScriptBlock's (mainly to get the clientID's of controls so I can do javascript totals) and also a ScriptManager.RegisterStartupScript on page_load to get set the focus to be the same after a partial postback. Maybe they are contributing?
Is there any tools that can help me out further to this? Sieve reported alot of empty divs being made when the postback occurs? bit I've never used sieve before so maybe this always happens?
alt text http://rodh.org/images/Programming/sievnodes.png
Is there some sort of code analysis I can do, or something that at least lets me see the new DOM nodes created each time...
I'm thinking hte problem might be to do with my code behind hackery to get the client id's, it stores them in an array, and then recreates taht array on each postback, perhaps something is going wrong there?
I've uploaded my JS file which does that hackery, and also the code behind in case anyone needs more info.
http://rodh.org/images/Programming/javascript.txt
http://rodh.org/images/Programming/codebehind.txt
So I guess my question is:
- Can anyone think of anything immediately that would be causing this?
- what are some common causes of increased DOM usage on UpdatePanels (using Jquery too btw)
- what tools can I use to debug?
I can tell you first hand Microsoft knows about the IE problem(KB 2000262) with UpdatePanels. Its a DOM parser issue. I had a site that ran fine up until a certain page content size and then IE(all versions) had a fit. FF and other browsers handled the same pages with ease.
Things I did to make my pages faster:
Use UpdateMode=Conditional wherever possible
Implement the KB 2000262 fix
UpdatePanel Async Postsback slow in IE…Part 3