How to see if Chrome manipulates HTML by itself? - html

If you forget to close a HTML-Tag, Chrome will validate your code and try to fix problems like this.
I had a major problem because I forgot a closing Form-Tag, and instead of closing it correctly, Chrome deleted a following form, not the inputs, simply the Form-Tags.
When I looked at the Source Code itself, the Form-Tag was there, but not in the Elements-Tab in the console.
So at first, I thought it must have something to do with some JS deleting this DOM-Node and set a DOM-Breakpoint to find the script.
To cut a long story short, it took me hours to find out, that no JS deleted my form, but Chrome itself thought: There is a missing so I delete some other to fix that...
Is there any possibilty to see if Chrome automatically changes your DOM?
Thank You!

The browser Engine does indeed. They use string replace methods, although it happens internally.
<div>
</div>> // mistake
<div> //missing end tag
<div></div>
---------------------------------------------------
Methods
file=file.stringreplace('>>', '>')
an uneven count will add the missing div just after the next beginning div and conditionally if the missing is not found by the end of the file:
file=file.stringreplace('
<div>', '</div>
<div>')
The Parsing Engine after the missing and broken tags are repaired then parses the file and can then with a positive count set the screens GUI widgets by opening and closing tags as GUI Frames. It does this by adding tokens delimiters to the actual div tags making them easily distinguished from each other.
<div1s>
</div1e>
<div1s>//section columns
<div2s></div2e>
<div2s></div2e>
<div2s></div2e>
</div1e>
<div1s>Footer</div1e>
-----------------------------------------------------
The GUI Frame Tokens
for each "<dive1>"{
FrameCreate(CSS--ATTRIBUTES FROM ASSOCIATIVE ARRAYS--)
//the GUI Frame Widgets VERTICAL SECTIONS
}
//Next it finds the nested divs2 and embeds these into the thir parents above but with embedded Text Widgets also.
FrameTextBoxCreate(--CSS MATED ATTRIBUTES RULES--)
div3 etc------and so on.
In fact it is in the WebView GUI Widget Sets in its customized Mosaic Canvas Widget Sets in Chrome would be where they are repaired.

Related

Cant get tinymce to display

Im trying to install tinymce to use with my text editor to allow the user to have a text box just like the stack overflow one. I cant get it to display though
ive put this in the head of my index file
<script src='https://cloud.tinymce.com/stable/tinymce.min.js'></script>
<script src='https:https://cloud.tinymce.com/stable/tinymce.min.js'>
</script>
<script src="//tinymce.cachefly.net/4.1/tinymce.min.js"></script>
<script>
tinymce.init({selector:'infotextarea'});
</script>
then in my info page ive put
<textarea id="infotextarea">Your content here.
</textarea>
can anyone explain why its not displaying
It may be that at the time you run the tinymce.init function, it is not yet rendered and there is no textarea in the DOM.
Try debugging your code on the following line:
<script>
debugger;
tinymce.init({selector:'infotextarea'});
</script>
When the web's execution has stopped on that line, in the development console of your browser type the following:
$('#infotextarea').length
If the size is greater than 0, textarea exists at that moment and it is another problem, but if it shows 0 is that you have not yet created that view, this will help us get more information about your problem.
If you want to target a <textarea> by ID you need to use a valid CSS selector.
selector: "#infotextarea"
(note the # at the beginning of the string)
I would also note you appear to be loading TinyMCE 3 separate times - I have no idea why you would need to do that - loading it once should be sufficient
Its not a perfect answer to my question, but i used ckeditor and it worked perfectly.
I must have a mistake somewhere that i or my team could not find with tinymce

contenteditable br / p / div weirdness

I create <div contenteditable="true"></div>
The behaviour I want is:
Enter key press = <p></p> around the text line
Shift-Enter keys press = <br/> after the text line
To get the behaviour I want in Firefox, I have tried creating the following "keypress" event:
function(ev) {
if (ev.keyCode == '13') {
document.execCommand('formatBlock', false, 'p');
document.execCommand('insertBrOnReturn',false,false);
}
return false;
}
but Firefox (as at 33.1.1) insists on inserting <br></br> on first enter (which then gets wrapped in my paragraph). I understand it to a degree when a line is empty however I do not understand why it is not removed as soon as a character is inserted into the new line.
For example, assume I type:
hello<enter>goodbye
into the editable field, I will end up with the following markup (using the above event handler)
<p>hello</p>
<p>goodbye<br></br></p>
The <br></br> does indeed disappear if I hit enter again but then I am left with the following markup
<p>hello</p>
<p>goodbye</p>
<p><br></br></p>
There are 2 problems with this:
Users will not necessarily hit the second enter, leaving "invisible" <br></br> after the goodbye
Alternatively users will hit the second enter and end up with an essentially redundant line containing <p><br></br></p>.
In fact the only way I can see to get
<p>hello</p>
<p>goodbye</p>
ie. what I want, is to to use the following sequence hello<enter>goodbye<enter><backspace> which seems patently ridiculous.
At this point I should say that I personally love Firefox as a browser and my strong preference is to keep using it, however for our business clean editing markup is critical, and in Chrome, using the above method (excluding insertBrOnReturn) produces the desired markup (the above keypress event function switches Chrome cleanly to use p rather than its standard div)
So I am in a difficult position, and I would welcome any input from other Firefox enthusiasts as to how the above can be achieved elegantly if indeed it is possible (please don't invest time providing complex hacks though as we are unlikely to use them - in my limited experience complexity is diametrically opposed to reliability)
thanks in advance for any help!
(PS - after working with this, I'm really not sure that the Chrome div implementation is any better - see comments below)

Dynamically re-bind html.ValidationMessageFor html helper?

Some background information, I am using ASP.NET with the MVC framework and html helpers.
I currently have a dynamic table where each row has a series of input boxes. Each of these input boxes has a validation message. This works completely fine for the first row. However, when other rows are dynamically added (with the IDs' being changed along with other attributes to match the row number) the validation message no longer works.
Both the row and validation message span are being replicated properly.
In JQuery, this is usually just a problem with the binding, so for each row I would simply re-bind the IDs'. However I am not really to sure how to approach them in ASP.NET.
Any assistance would be appreciated.
Thanks
Alright, I have finally figured this out.
In MVC, in order to handle the validation, it import a JQuery file known as jquery.validate.unobtrusive.js.
However, similar to JQuery, this only occurs at the very beginning when the page is loaded. So, when you add a new dynamic element, you need to remove the bindings and the re-bind them again.
Basically, in your function for adding a new element, put the following lines of code AFTER you have added the new element:
$("#form").removeData("validator");
$("#form").removeData("unobtrusiveValidation");
$.validator.unobtrusive.parse("#form");
For example:
function addInfoDynamic()
{
document.getElementById("#myDiv").innerHTML += "New Content";
$("#form").removeData("validator");
$("#form").removeData("unobtrusiveValidation");
$.validator.unobtrusive.parse("#form");
}

shrink html help

I have an array of 2000 items, that I need to display in html - each of the items is placed into a div. Now each of the items can have 6 links to click on for further action. Here is how a single item currently looks:
<div class='b'>
<div class='r'>
<span id='l1' onclick='doSomething(itemId, linkId);'>1</span>
<span id='l2' onclick='doSomething(itemId, linkId);'>2</span>
<span id='l3' onclick='doSomething(itemId, linkId);'>3</span>
<span id='l4' onclick='doSomething(itemId, linkId);'>4</span>
<span id='l5' onclick='doSomething(itemId, linkId);'>5</span>
<span id='l6' onclick='doSomething(itemId, linkId);'>6</span>
</div>
<div class='c'>
some item text
</div>
</div>
Now the problem is with the performance. I am using innerHTML to set the items into a master div on the page. The more html my "single item" contains the longer the DOM takes to add it. I am now trying to reduce the HTML to make it small as possible. Is there a way to render the span's differently without me having to use a single span for each of them? Maybe using jQuery?
First thing you should be doing is attaching the onclick event to the DIV via jQuery or some other framework and let it bubble down so that you can use doSomething to cover all cases and depending on which element you clicked on, you could extract the item ID and link ID. Also do the spans really need IDs? I don't know based on your sample code. Also, maybe instead of loading the link and item IDs on page load, get them via AJAX on a as you need them basis.
My two cents while eating salad for lunch,
nickyt
Update off the top of my head for vikasde . Syntax of this might not be entirely correct. I'm on lunch break.
$(".b").bind( // the class of your div, use an ID , e.g. #someID if you have more than one element with class b
"click",
function(e) { // e is the event object
// do something with $(e.target), like check if it's one of your links and then do something with it.
}
);
If you set the InnerHtml property of a node, the DOM has to interpret your HTML text and convert it into nodes. Essentially, you're running a language interpreter here. More text, more processing time. I suspect (but am not sure) that it would be faster to create actual DOM element nodes, with all requisite nesting of contents, and hook those to the containing node. Your "InnerHTML" solution is doing the same thing under the covers but also the additional work of making sense of your text.
I also second the suggestion of someone else who said it might be more economical to build all this content on the server rather than in the client via JS.
Finally, I think you can eliminate much of the content of your spans. You don't need an ID, you don't need arguments in your onclick(). Call a JS function which will figure out which node it's called from, go up one node to find the containing div and perhaps loop down the contained nodes and/or look at the text to figure out which item within a div it should be responding to. You can make the onclick handler do a whole lot of work - this work only gets done once, at mouse click time, and will not be multiplied by 2000x something. It will not take a perceptible amount of user time.
John Resig wrote a blog on documentDragments http://ejohn.org/blog/dom-documentfragments/
My suggestion is to create a documentDragment for each row and append that to the DOM as you create it. A timeout wrapping each appendChild may help if there is any hanging from the browser
function addRow(row) {
var fragment = document.createDocumentFragment();
var div = document.createElement('div');
div.addAttribute('class', 'b');
fragment.appendChild(div);
div.innerHtml = "<div>what ever you want in each row</div>";
// setting a timeout of zero will allow the browser to intersperse the action of attaching to the dom with other things so that the delay isn't so noticable
window.setTimeout(function() {
document.body.appendChild(div);
}, 0);
};
hope that helps
One other problem is that there's too much stuff on the page for your browser to handle gracefully. I'm not sure if the page's design permits this, but how about putting those 2000 lines into a DIV with a fixed size and overflow: auto so the user gets a scrollable window in the page?
It's not what I'd prefer as a user, but if it fixes the cursor weirdness it might be an acceptable workaround.
Yet Another Solution
...to the "too much stuff on the page" problem:
(please let me know when you get sick and tired of these suggestions!)
If you have the option of using an embedded object, say a Java Applet (my personal preference but most people won't touch it) or JavaFX or Flash or Silverlight or...
then you could display all that funky data in that technology, embedded into your browser page. The contents of the page wouldn't be any of the browser's business and hence it wouldn't choke up on you.
Apart from the load time for Java or whatever, this could be transparent and invisible to the user, i.e. it's (almost) possible to do this so the text appears to be displayed on the page just as if it were directly in the HTML.

How is gmail source transformed?

I open gmail, click on an inbox item, and look at source of the page. It doesn't look like there isn't any proper html to relate to what is shown on the actual page.
How is the source getting processed into the actual page? Is there some javascript processing this information?
As Jay mentioned, my method of using FireFox's Web Developer Plugin doesn't actually work, it just shows the preview (first few lines).
However, using Firefox's FireBug plugin, you can click Inspect, then move the mouse and highlight what your interested in. When it has the outline around it click. Once the selection is shown in the HTML of FireBug, right-click on the HTML element (in my case a div class="YrSjGe"), and choose Copy HTML. Then go to your favorite text editor, and paste.
Finally, the HTML :)
GMail uses a large amount of java script to make its pages work. This javascript is manipulating the HTML DOM.
If you look at the page source you aren't seeing the current contents of the DOM. You need to use a tool that will show you the HTML DOM. I use Opera Dragonfly, but there are plenty of others for other browsers. Dragonfly will show the the scripts for the page, as well as the event handlers for each element of the DOM.
Edited 3 Nov 08:
In response to the request for access to the scripts, when I view the page the scripts all come up as inline. As others have said, they're obfuscated, so less than easy to read. Here is just a sample:
try{function aa(a,b){return a.appendChild=b}function ba(a,b){return a.textContent=b}function da(a,b){return a.stop=b}function ea(a,b){return a.toString=b}function fa(a,b){return a.length=b}function ga(a,b){return a.title=b}function ha(a,b){return a.position=b}function ia(a,b){return a.create=b}function ja(a,b){return a.className=b}function ka(a,b){return a.width=b}function la(a,b){return a.expand=b}function ma(a,b){return a.abort=b}function na(a,b){return a.data=b}function oa(a,b){return a.next=b}
function pa(a,b){return a.load=b}function d(a,b){return a.innerHTML=b}function qa(a,b){return a.onerror=b}function sa(a,b){return a.getDate=b}function ta(a,b){return a.value=b}function ua(a,b){return a.disabled=b}function va(a,b){return a.dispatchEvent=b}function wa(a,b){return a.currentTarget=b}function xa(a,b){return a.left=b}function ya(a,b){return a.hideFocus=b}function za(a,b){return a.removeChild=b}function Aa(a,b){return a.target=b}function Ba(a,b){return a.screenX=b}
function Ca(a,b){return a.screenY=b}function Da(a,b){return a.send=b}function Ea(a,b){return a.remove=b}function Fa(a,b){return a.start=b}function Ga(a,b){return a.cssText=b}function Ha(a,b){return a.keyCode=b}function Ia(a,b){return a.enabled=b}function Ja(a,b){return a.href=b}function Ka(a,b){return a.handleEvent=b}function La(a,b){return a.removeNode=b}function Ma(a,b){return a.detach=b}function Na(a,b){return a.type=b}function Oa(a,b){return a.contains=b}function Pa(a,b){return a.tabIndex=b}
function Qa(a,b){return a.cellSpacing=b}function Ra(a,b){return a.clear=b}function Sa(a,b){return a.setPosition=b}function Ta(a,b){return a.cellPadding=b}function Ua(a,b){return a.display=b}function Va(a,b){return a.execute=b}function Wa(a,b){return a.height=b}function Xa(a,b){return a.nodeValue=b}function Ya(a,b){return a.clientX=b}function Za(a,b){return a.clientY=b}function ab(a,b){return a.right=b}function bb(a,b){return a.visibility=b}
function aaa(a){var b=cb[i](db);(new Image).src=baa+eb(b)+"&jsmsg="+eb(a)+caa+fb+daa+(new Date)[gb]()}function _B_record(){cb[k]((new Date)[gb]())}function _B_prog(a){top.pr=a;if(hb===undefined){var b=top[ib][jb](eaa);hb=b?b[m]:null}if(hb){ka(hb,n[kb](a*0.99)+lb);if(a==100)hb=null}}function _B_err(a){aaa(a);throw a;}function mb(a,b){var c=a[nb](ob),e=b||pb;for(var f;f=c[rb]();)if(e[f])e=e[f];else return null;return e}function sb(){}function tb(a){a.lg=function $(){return a.bmc||(a.bmc=new a)}}
function ub(a){var b=typeof a;if(b==vb)if(a){if(typeof a[o]==wb&&typeof a[xb]!="undefined"&&!faa(a,gaa))return yb;if(typeof a[q]!="undefined")return zb}else return Ab;else if(b==zb&&typeof a[q]=="undefined")return vb;return b}function haa(a,b){if(b in a)for(var c in a)if(c==b&&Bb[r][Cb][q](a,b))return true;return false}function Db(a){return typeof a!="undefined"}function Eb(a){return ub(a)==yb}function Fb(a){var b=ub(a);return b==yb||b==vb&&typeof a[o]==wb}function Gb(a){return typeof a==Hb}
function Ib(a){return typeof a==wb}function Jb(a){return ub(a)==zb}function Kb(a){var b=ub(a);return b==vb||b==yb||b==zb}function Lb(a){if(a[Cb]&&a[Cb](iaa)){var b=a.closure_hashCode_;if(b)return b}a.closure_hashCode_||(a.closure_hashCode_=++jaa);return a.closure_hashCode_}
function s(a,b){var c=a.SSb;if(arguments[o]>2){var e=Array[r][Mb][q](arguments,2);c&&e[Nb][Ob](e,c);c=e}b=a.WSb||b;a=a.TSb||a;var f,g=b||pb;f=c?function(){var h=Array[r][Mb][q](arguments);h[Nb][Ob](h,c);return a[Ob](g,h)}:function(){return a[Ob](g,arguments)};f.SSb=c;f.WSb=b;f.TSb=a;return f}function Pb(a){var b=Array[r][Mb][q](arguments,1);b[Nb](a,null);return s[Ob](null,b)}function Qb(a,b){for(var c in b)a[c]=b[c]}
function t(a,b){function c(){}c.prototype=b[r];a.F=b[r];a.prototype=new c;a[r].constructor=a}function Rb(a,b,c){if(a[Sb])return a[Sb](b,c);if(Array[Sb])return Array[Sb](a,b,c);var e=c==null?0:c<0?n.max(0,a[o]+c):c;for(var f=e;f<a[o];f++)if(f in a&&a[f]===b)return f;return-1}function Tb(a,b,c){if(a[Ub])a[Ub](b,c);else if(Array[Ub])Array[Ub](a,b,c);else{var e=a[o],f=Gb(a)?a[nb](v):a;for(var g=0;g<e;g++)g in f&&b[q](c,f[g],g,a)}}
function Vb(a,b,c){if(a.map)return a.map(b,c);if(Array.map)return Array.map(a,b,c);var e=a[o],f=[],g=0,h=Gb(a)?a[nb](v):a;for(var j=0;j<e;j++)if(j in h)f[g++]=b[q](c,h[j],j,a);return f}function Wb(a,b,c){if(a[Xb])return a[Xb](b,c);if(Array[Xb])return Array[Xb](a,b,c);var e=a[o],f=Gb(a)?a[nb](v):a;for(var g=0;g<e;g++)if(g in f&&b[q](c,f[g],g,a))return true;return false}
When you do plain "View Source," you're looking at the source of the loading page. All the HTML there is dynamically replaced with the GMail app when it's all loaded.
EDIT: GMail also makes extensive use of iframes for God-only-knows what. If I remember correctly, there're about 5 or 6 (i)frame objects in GMail. Additionally, much of the Javascript is loaded dynamically, without even using tags. The URL for these scripts goes something like:
https://mail.google.com/mail/?ui=2&view=jsm&name=gm&ver=A7pcfYmUnLY&am=X_E5t8T3EkGpRf3deGMWZA
That exact URL won't work, though; the two variables at the end depend on your individual login information/session/phase of the moon.
Yes, they are using javascript to transform that data into the complete page that you see.
As others have already mentioned, Gmail uses large portions of obfuscated Javascript to manipulate the DOM. Although it is a lot of work to discover how all of this works (since it's a lot of obfuscated code to go through), the best way to finding out how it works is to use Firebug to look at the various AJAX-requests, included scripts and the rendered DOM.
Also, you could read the following article, which explains a short portion of the architecture used by Gmail.
To view the Javascript used to generate the email, use Firebug for firefox, click "script", then in the bar above that button there will be the name of one of the scripts, click on it to list all the scripts, choose whichever one you like.
gmail probably compresses it though, making it pretty much unreadable.
You can also select 'Show original' on the drop down where it says 'reply' or 'reply to all' to see the exact email text including headers.
In IE you get a blank page if you right-click and "View Source". If you use the Page menu > View Source, you see the actual page source. As Steve mentioned, in Firefox you see the actual source both from right-click "View Page Source" and from View menu > Page Source.
I suspect they're taking advantage of some IE-specific obfuscation to hide their secret sauce from 85% of the users.