Web Browser Control rendering mode

Mivel default-bol nem a legfrissebb IE szerint renderel a windowsos web browser control, ezert ha azt szeretnenk, hogy adott oldalt megis ugy renderelje akkor ezt kell megadni:

Defining Document Compatibility

WebBrowser control layout modok IE8-nal

Az IE8-ban 3 layout mod van:

• IE8 Standards
• IE7 Standards
• Quirks

Az IEBlog-ban irjak, hogy WebBrowser control eseteben a default layout mod az IE7 Standards (mig mas esetben az IE8 Standards). Ezt viszont valtoztatni is lehet, ha az IE8 Standards-ot szeretnenk WebBrowser control-nal is hasznalni:

When an executable loads an instance of the WebBrowser control it scans the registry to check whether the executable wants IE7 Standards or IE8 Standards mode.

To run a WebBrowser control in IE7 Standards Mode, insert the following values into the registry:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_NATIVE_DOCUMENT_MODE]

"MyApplication.exe"=dword:11170

To run in IE8 Standards Mode insert the following registry value:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_NATIVE_DOCUMENT_MODE]

“MyApplication.exe”=dword:13880

In both of these instances, MyApplication.exe should be replaced with the name of the executable that will be running WebBrowser controls in a specified mode.

To run instances of a WebBrowser control in IE5 Quirks Mode, insert the following value into the registry:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_NATIVE_DOCUMENT_MODE]

“MyApplication.exe”=dword:C350

Scott Mitchell: Two Common Pitfalls When Submitting a Web Form Using the Enter Key

Itt van az egesz, de ami a lenyeg:

A regular button has a type attribute value of “button”. By default, the ASP.NET Button Web control renders a submit button.

Multiple Submit Buttons on the Page
…when a user hits Enter in a single-line textbox, the browser submits the form. In most situations, the browser includes the submit button’s name/value pair in the form fields returned on submission (although this is not always the case, as we’ll see later on in this article). If there are multiple submit buttons on the form, the browser sends the first submit button’s name/value pair on form submission (the first one being the one that first appears in the rendered HTML markup, not necessarily the one that appears visually first on the page).

Imagine that you have a page that collects user input and everything works fine. The user can hit Enter to submit the form, which causes the browser to send the submit button’s name/value pair, which executes the corresponding Button’s Click event handler, where you process the user’s entered data. Great. But what would happen if you (or a coworker) updated the site’s master page and included an ASP.NET Button control that, when clicked, would, say, Response.Redirect the user to a Login page? With this change, if a user visited your form and hit Enter to submit it, the browser would send the Login submit button’s name/value pair, and the user would be redirected to the login page!

The net result is that the Login Button’s Click event is raised on postback, and the user is sent to the Login page. Talk about a confusing user experience! Everything works fine if they click the “Submit Form” button, but if they hit Enter, they are redirected to the Login page.

To fix this, we need to instruct the Login Button control that it should not render as a submit button, but rather a regular button. To accomplish this, set the Login Button’s UseSubmitBehavior property to False. This causes the Login button to render as a regular button along with the necessary JavaScript to submit the form when the button is clicked (along with sending additional information so that ASP.NET knows that that button was what caused the postback so that its Click event handler can be raised).

Using Enter to Submit a Form with Only One Single-Line TextBox
Another gotcha involving submitting forms with the Enter key arises with Internet Explorer and forms with just one single-line TextBox. Earlier I said that when hitting Enter in a single-line textbox, the browser submits the form and (usually) includes the first submit button’s name/value pair in the form submission information. Unfortunately, this is not the case when using Internet Explorer and a Web Form with just one single-line TextBox. A more thorough description of this problem is documented in an earlier article of mine, Enter and the Button Click Event.

In short, the workaround is to never create a Web Form with just one single-line TextBox. If your form only requires one single-line TextBox, then add another one but use Casecading Stylesheets (CSS) to hide it…Yes, it’s a hack, but it works.

7-es elotti IE-nel problemat okozhat a HEAD-hez uj elem hozzaadasa, ha van mar beolvasott BASE tag

A korabban itt es itt emlegetett dinamikus javascript betoltessel kapcsolatban Shaun Inman belefuott egy problemaba IE-nel (7-esnel regebbi):

Ran into a JavaScript problem with everybody’s favorite browser recently. Manipulating the head element from within (say by adding additional script or link elements before the page loads) was resulting in an enormously helpful “Operation Aborted” error message in versions of Internet Explorer prior to 7. Of course, like all things IE, this error’s appearance was inconsistent.

I was eventually able to track the problem down to the presence of a base tag. It didn’t matter if it was an open <base> or a self-closing <base />, if it came before the <script> that was manipulating the head, then IE stopped everything and issued the error. (At this point in script execution document.getElementsByTagName('head')[0] is a valid HTML element so testing for its availability before attempting to appendChild() doesn’t avoid the error. try/catch() is also of no assistance.)…

Tenni Theurer: Maximizing Parallel Downloads in the Carpool Lane

Itt van az egesz, de lenyeg, hogy a HTTP/1.1 specifikacioban leirt ajanlas szerint az IE es a Firefox is max 2 dolgot tolt le parhuzamosan ugyanarrol a hostrol (IP cimet nem nez). Ezt meg lehet valtoztani kliens oldalon.

Az IE-nel a registy manipulalasaval:

1. Start Registry Editor (Regedt32.exe).
2. Locate the following key in the registry:
   HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
3. On the Edit menu, point to New click DWORD Value, and then add the following registry values:
   Value name: MaxConnectionsPer1_0Server
   Value data: 10
   Base: DecimalValue Name: MaxConnectionsPerServer
   Value data: 10
   Base: Decimal
4. Quit Registry Editor.

Firefoxban pedig az about:config oldalon a
network.http.max-persistent-connections-per-server atallitasaval.

Kimertek, hogy mennyit huz a sebessegen, ha tobb hostname aliast hasznalnak amivel arra szorithatjak a browsert, hogy egyszerre tobb elemet toltson le, de az jott ki, hogy 2 aliasnal tobbet nem erdemes hasznalni, mert csak meglassabb lehet az egesz, de gyorsitani biztos nem fog.

Ryan Bran merese szerint viszont siman megeri 3 kulonbozo subdomaint hasznalni.

Reload IE-ben a cahce kiiktatasaval.

Ha ugy akarunk ujratolteni egy oldalt IE-ben, hogy ne hasznalja a cache-t, akkor nyomni kell kozben a controlt es a shiftet.

Fritz Onion: Beware trailing comma in JavaScript prototypes

Itt van, de rovid ugyhogy be is masolom:

When defining a number of functions in a prototype in JavaScript, do not include a trailing comma after the last

MyType.prototype = {
foo : function() {
// ...
},

bar : function() {
//...
}, //<- fails in IE!
}

function:What was especially tricky about tracking this problem down was that FireFox works with or without the trailing comma, so it only fails in IE!

Row Swan: Conflicting Absolute Positions

Ez a problema:

“On two separate occasions this month, I’ve been required to produce a layout in which a fixed-width scrolling side “pane” and flexible scrolling main “pane” must resize to fill all available space in a browser window.”

Vegigjarja a dolgot es vegul Div-ekkel es CSS-sel oldja meg. Persze most is az IE bonyolitja a megoldast.

Honnan tudjuk, hogy az utolag include-olt javascript mar betoltodott. [2]

Az elozo problemara a codingforums.com-on callback-es megoldast javasolnak a firefoxban az element.addEventListener, IE-ben pedig a onreadystatechange event segitsegevel:


function loadScript(src, callback) {
var node = document.createElement("script");
if (node.addEventListener)
node.addEventListener("load", callback, false);
else
node.onreadystatechange = function() {
if (this.readyState == "complete") callback.call(this);
}
node.src = src;
document.getElementsByTagName("head").item(0).appendChild(node);
node = null;
}


// load 30k script.
// Listener.cleanUp is defined at the bottom of drag.js
callback = function() {
var self = this;
alert("Loaded: " + this.src + "\nListener.cleanUp (nested):" + Listener.cleanUp);
};
loadScript("http://dhtmlkitchen.com/editor/js/drag.js", callback);


[Update]
Ahogy Jan Volter is emliti jobb vigyazni ezzel a readyState propertyvel es onreadystatechange eventtel, mert:
The “this.readyState == ‘complete’” test doesn’t actually entirely work. The readyState theoretically goes through a series of states:

0	uninitialized
1	loading
2	loaded
3	interactive
4	complete

But in fact, states may be skipped. In my experience with IE 7, you get either a loaded event or a completed event, but not both. It may have something to do with whether you are loading from cache or not but there seem to be other factors that influence which events you get. Sometimes I get loading or interactive events too, and sometimes I don’t. It’s possible the test should be “this.readyState == ‘loaded’ || this.readyState == ‘complete’“, but that risks triggering twice.

aspfaq.com: Why won’t my session variables stick?

Itt van 10 dolog, ami miatt “elveszhet” a session valtozo.

Mi a 4-esbe futottunk bele, azaz: “If you are using IE 5.5 or IE 6.0, and your local server name has an underscore or other non-alphanumeric character (other than a dash) in the name, then cookies will not work correctly.”