Browser peculiarities

From Helpful

For more webdev-related articles, see the webdev category.
Among the more interesting are general webdev notes, Javascript related notes, CSS notes, browser peculiarities, jQuery

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

[edit]

IE (/Trident)

[edit]

Peculiarities and bugs

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

[edit]

Layouting (IE≤6)

Internet Explorer 6 and before had some significant problems in its implementation of the box model standard, which led to a few different types of layouting bugs (most of the well known IE layouting problems, in fact) that popped up with some regularity, some almost unsolvable.

[edit]

:hover

IE6 and earlier only supported :hover on <a> tags. IE7 supports it on any element, but only in standards-compliant mode (apparently for backward incompatibility reasons), and there are still some (mostly minor) bugs in this new :hover support.

Perhaps more interestingly, usage of :hover seems to sometimes cause IE7 to render quite sluggishly, where the slowness is apparently proportional to the amount of elements that use hover in a particular way.(verify)

It seems that avoiding :hover and using CSS class toggling may run into the same slowness or not, depending on the exact implementation, which points to implementation problems specific to IE7 DOM manipulation, rendering, or such.

[edit]

sluggish IE7

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

While IE is generally acceptably fast, there are a number of things that seem to trigger sluggishness, which in some circumstances can be fairly extreme. The causes are probably not all known yet, and also depend a little on exactly what is being slow.

Slow scrolling is often IE's rendering, for example known IE/IE7 issues like
- using :hover rules (an IE7 bug; IE6 does not seem to have this problem)
- IE7's handling of small transparent PNGs as background images(verify) (a bug, but you can regularly work around it by having larger transparent PNGs)
- Slower response during AJAX fetches
- Some browser plugins. For example, Shockwave/Flash sometimes holds up page rendering and scrolling, simply by being something (potentially) complex that has to be drawn.

Pages rendering slower than before might be some malware scanner, swapping, or even by someone lagging your broadband connection.
- antivirus software that scans all retrieved content will slow thigns down a little. More noticeable on sites with many frames. (a past bug in the IE Phishing Filter made it unnecessarily slow in the presence of frames; see [1]).

[edit]

Error pages

Apparently, IE uses it own customized error pages when the error document's size is less than, apparently, half a KB.

This means that to ensure your own error pages will be displayed, it may have to have some padding -- some commented Lorem Ipsum, perhaps.

This may also apply when gzip compresses the page below the threshold(verify)

[edit]

Other IE notes (semi-sorted)

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

[edit]

Running multiple versions of IE for testing

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

Use Virtual PC, VMWare, parallels, virtualbox, or similar to install a hosted windows to install a (single) other IE

and/or

[edit]

IE debugging

This article/section is a stub — probably a pile of half-sorted notes and assertions some of which may well be wrong, and not verified as a whole. Feel free to add or refine.

To developers, Internet Explorer Developer Toolbar is mostly just a DOM inspector. Although it has some potentially useful visual design tools, it is nowhere near Firebug yet.

Firebug Lite is still mostly an in-page javascript console. It can be useful to see your debug logging, but is not too interesting beyond that.

For real script debugging, you first enable IE's script debugging via: 'Tools' , 'Internet Options', 'Advanced', and look for two items mentioning Script Debugging. ((verify) what the difference beween the two are)

You can start debugging by choosing 'View', 'Script Debugger', 'break on next statement', or by using the IE-only debugger statement -- although there are suggestions that that statement is not entirely reliable.

This should show you a Runtime Error dialog and, if you choose to debug, a list of debuggers.

Debuggers UIs you can use include:

Microsoft Script Debugger (ancient, minimal)

Microsoft Script Editor (MSE) (a decent stand-alone utility, that comes with Office 2003, XP and 2007)(verify)

Visual Studio's Web Developer (including Express Editions, though they need more manual labour)

[edit]

Microsoft Script Editor

MSE is actually nicely complete debugger and allows you to attach debug scripts in existing IE processes.

Note that you should detach, continue the script, or close the debugger to leave IE in a running state. Some windows features rely on IE, so you can hang your system like this.

If MSE starts but does not show a window, this usually means part of the office webdev is missing, perhaps because you have a default Office 2007 install. You'll want to install the 'Web Debugging' option, via Control Panel, (Add/Remove) Software, Office, Change, the add/remove option and find the item in one of the office-tools type menus.

[edit]

Visual Studio

When you are developing ASP apps, debugging them will cause them to be run in a local IIS web server, and owns the IE process allowing VS to debug both sides at the same time.

However, many of us will not want to purchase a pricy complete VS package just to be able to figure out what IE is tripping over.

It seems that you can in fact, use VS Web Developer (Express Edition), even though it does not register itself as a debugger. (TODO: Figure out when it works)

"Open Web Site", "Remote Site", and such will require the remote server to have Frontpage Extensions enabled. However, this is not an option you'ld really want on non-IIS web servers, which describes most of us.

Many of us want a more general solution than either of these options.

[edit]

Technical notes

Script debugging consists of the interaction of various components:

a script host, the thing that wants to run a script, and will manage the relation between what the script should do for it, and the script's its eventual execution. Hosts include mshtml.dll, asp.dll, and wscript.exe.

a script engine: actually executes a specific type of script. Interacts with the host, and optionally a debugger. The two major script engines are jscript.dll and vbscript.dll.

pdm.dll (Process Debug Managed), a debug helper that keeps track of script state, sets breakpoints, marshals between the debugger and the script engine, etc.(verify)

a debug engine, which interfaces between a debugger UI and a pdm instance.

(and a few less interesting details, such as how a debug engine chooses pdm instances; see e.g. source the source of this list)

[edit]

Gecko, Firefox, etc.

Gecko is the layout engine used in Firefox, and also Flock, Camino, SeaMonkey, K-Meleon, Netscape 9, Epiphany, and some other places.

Theorhetically, all should react the same in terms of layouting, but Camino seems to break that theory.

http://en.wikipedia.org/wiki/Gecko_(layout_engine) http://en.wikipedia.org/wiki/Camino

[edit]

Opera (Presto)

[edit]

WebKit, Safari, Google Chrome, etc.

WebKit, effectively a fork of KHTML, is used by Safari, Google Chrome, iPhone and some other phones, and others including Adobe AIR, iCab, Omniweb, Shiira

[edit]