Rich S wrote:
> In IE8, Vista Home Premium SP2, I'm not able to open Kodak Gallery to
> access my account. It gives the error message " Message from webpage:
> 'DOMParser' is Undefined" . I click "OK", error popup disappears, and the
> Kodak webpage gives an eternal animated "Loading" icon. As far as I
> know, this is the only site I have this problem . Works just fine on
> Firefox 3.5.
I'm guessing it is either a "userData persistence" or "DOM storage" issue in
the settings configured in IE8, or bad code at the web site (their trying to
use code that only works for some web browsers). By default, both these
options should be enabled (Microsoft wants to embrace sites that want to
store info on your host and disregard privacy).
Is "Enable DOM storage" enabled in advanced options for IE8? I disabled
this due to privacy and security concerns. It is a means of letting a site
store information (supposedly about your account with them) on your host.
This lets a site have persistent data that it can store on your site rather
than trying to use cookies (which many users delete either through web
browser settings or privacy/cleanup utilities). DOM storage is new to IE8
(wasn't in IE7). For info on DOM storage, see:
http://msdn.microsoft.com/en-us/libr...62(VS.85).aspx
http://en.wikipedia.org/wiki/DOM_storage
https://developer.mozilla.org/en/DOM/Storage
For both IE7 and IE8, under the Security tab in Internet Options, and for
the security zone, there is a "userData persistence" option (enabled by
default). This creates a subfolder under "%userprofile%\Application
Data\Microsoft\Internet Explorer\userData" to persist data between web
sessions with a site. Again, this lets a site save information (files) on
your host. Although it is innocuously called user data, it contains
whatever a site wants to store on your host. The premise is that they store
information about your account for ease of use when revisiting their site.
From the definition found at
http://www.microsoft.com/windows/ie/...ty/setup.mspx:
Userdata persistence. This option determines whether a Web page can save a
small file of personal information associated with the page to the
computer. This option has the following settings:
¡E Disable, which prevents a Web page from saving a small file of personal
information to the computer.
¡E Enable, which allows a Web page to save a small file of personal
information to the computer.
Here is an example of how the "userData persistence" feature can be
implemented by a site:
http://support.microsoft.com/kb/836914
However, as an example, and with "userData persistence" disabled in IE7 (for
Windows XP Pro SP-3 running in a virtual machine), I can elect to hide an
update and it gets remembered in a later Windows Update site session.
Perhaps that's because the entry is recorded in the catalog saved on my host
for the WU service. So I'm not sure what "settings" will be forgot between
WU site sessions.
The idea is that "good" info gets stored on your host. Well, we've seen
what happens when a trust model is employed regarding a program or protocol.
Spam is rampant in e-mail because of the trust model used by SMTP.
Both of the above methods to store persistent site-defined data on your host
are to counter the diminishing use of cookies due to users not keeping them
around usually due to privacy concerns or for cleanup of the host. However,
just like cookies, they can be used by the sites for their own purposes,
like tracking your web navigations. Sites that are coded to use this
persistent data may fail if they're not allowed to use it; however, they
should issue a web page explaining the cause for their refusal to allow you
to use their site rather than just spewing a nonsense error message. Most
times they don't check if the DOM object they created using Javascript
actually got created (no check on the error code) and then later they try to
use that object but the web browser pukes because it can't find that object.
A site should using something like "if(typeof(DOMParser) == 'undefined')" to
test if the method is supported (I don't think it is in IE); see
http://www.van-steenbeek.net/?q=expl...arsefromstring. They
should test which web browser is connecting to their site. See
http://www.webreference.com/programm...nitive2/2.html on
differences in handling an XML document, section 21.1.3. The site shouldn't
be using code for methods that aren't supported by the web browser that is
connecting to them. All you can do is notify the site that they ****ed up.
I disabled both DOM storage and userData persistence. If a site wants to
record information about my use of their site then they had better have me
register to create an account with me in which to store that data and then
have me login to make use of that stored information. I'm not letting store
on my host whatever files they feel inclined to save there. If they
permitted me an option to specify an expiration period for that persistent
*site* data then I might rethink my choice.
If the site demands that you enable DOM storage (or userData persistence),
you have a choice to make: enable DOM storage and let them store what they
want on your host, or disable DOM storage and don't use that site's
"service". As AJAX-enabled online services become more numerous and more
accepted by users (i.e., as they become more pervasive), the more DOM
storage becomes important. Both IE and Firefox (and probably other web
browsers) support DOM storage. So perhaps you have different settings for
it in each web browser. There are also some extensions (add-ons) to Firefox
that alter how DOM works within that web browser.
Similar Threads
Linear Mode
