Wieso erhalte ich eine Fehlermeldung wenn ich eine Messung mit dem Smart Sensor auf den Sonden in London und Kiel ausführen will?

An den Standorten London und Kiel müssen noch Hard- und Softwareupgrades durchgeführt werden, bevor wir dort den Smart Sensor freischalten können.

Wieso werden viel mehr Grafiken mit dem Smart Sensor geladen, als vom Browser verwendet werden?

Sehr wahrscheinlich haben Sie im Style-Sheet sehr viele Styles mit Graphiken definiert und beim Smart Sensor den "CSS load mode" "get all images" ausgewählt, die Einstellung "only imports" sollte in diesem Fall eine bessere Browseremulation ergeben.

Kann ich Transaktionen, die für den "Standard Sensor" geschrieben wurden mit dem Smart Sensor ausführen?

Nein, solche Transaktionen müssen neu erstellt werden. Bitte setzen Sie sich mit unserem Support in Verbindung um dies zu veranlassen.

Errata (bekannte Einschraenkungen und Fehler, nur auf Englisch verfügbar)

• XHTML: use case sensitive comparisons for attributes (see above)
• Access to attributes is case sensitive ATM.
• Setting cookies with javascript on pages with effective uris without fully qualified hostnames (e.g. localhost) fails: (Maybe not a real bug and related to the way Cookie scopes work) Note that this is no problem with real-world web sites.
• document.createElement(): Firefox filters out forbidden characters instead of throwing DOMException, should we do the same?
• Scripting_Exception: If non-ascii parameters (e.g. values) are fed to Scripting functions, the message can get garbled since its currently created in ASCII (TODO: create in UTF8 or UTF16)
• In HTML4.01 and beyond checkboxes must have a value attribute. Firefox defaults to "on" if none is set (W3Cs doesn't enforce a default value), we do the same.
• the HTML parser can be confused by Javascript code containing HTML tags (not allowed, but used in the real world) in strings. For <script> we have a configurable hack, but not for attributes (onmouseover="..." etc.).
• Multibyte encoded (e.g. UTF16) HTML pages containing scripts which use document.write() currently don't work correctly, since depending on byte sex and encoding the new text might be inserted into the byte sequence representing one character. (Note that UTF16 web pages are rarely encountered in the real world)
• currently does not work like real world browsers with HTML fragments like this: <table> ... <form ...> </table> <input ...> </form>
  since the input element is no child of the form element in the DOMtree. There's hack that works around this problem.
• HTML Object elements can refer to both a code file AND a data object at the same time. We currently only load the code file and only if it's not present the data file.
• All external objects referred to in CSS property assignments are loaded. Real browsers only load objects (images) if they are actually used by the rendered pages.
• Script recorder (not the browser sensor) currently doesn't work well/at all with "noframes" and "noscript" options set. (Note that most current real-world webpages are not designed for browsers without script and frame support)
• Some horrible broken HTML pages (without body/html/head tags etc) may parse well in "real world" browsers but will fail with the sensor.
• HTTP auth credentials have to be given before they are used. For NTLM the auth mechanism has to be set manually.
• CSS Parser currently only accepts 8bit, ascii compatible charsets for external style sheets (does't matter for internal)
• Neither client side nor server side image maps are currently supported by the recorder and only limited supported by the server