Archive for the ‘HTML’ Category

location.replace and Back button bug in IE

April 12, 2007

In our web application, after the user logs on, we display a “Please wait…” screen and then the user is taken to the main screen, using a “location.replace(URL)” function call.

Yesterday, due to another problem, we noticed that when the user clicks the Back button on Internet Explorer (6 & 7), he is taken to the “Please wait” screen, and then back to the main window, instead of being taken to the login screen, since the “location.replace()” method promises according to all the documentation we found not to put the current page in the browser history object, so pressing the browser Back button should take you to the previous page.

Both my colleague and I put up a clean sample HTML files to test it, but where in my test page the problem didn’t re-occur, it did with my colleague HTML files. A little search for differences showed that I wrote a simple HTML page from scratch:

<html>
  <body>
    <form>
      <input type=button value=click onclick=”location.replace(‘b.htm’)”>
    </form>
  </body>
</html>

But my colleague used a template to create her HTML file, so her files looked like:

<html>
  <head>
    <meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″>
    <title>EXAMPLE</title>
  </head>
  <body>
    <form>
      <input type=button value=click onclick=”location.replace(‘b.htm’)”>
    </form>
  </body>
</html>

Checking it further, we found out that when you use location.replace (and also window.open with the last parameter set to true) and the page you switch to has a Content-Type http-equiv <meta> tag that has a charset setting in its content attribute, Internet Explorer for some reason adds the current page to the history object, so pressing the Back button will take you to that page.

Note that for the bug to happen the new page to which you replace need to have this <meta> tag, and the current page content has no affect. Also, you must set the charset in that page – setting a content type without a charset (e.g. “text/html;”) doesn’t cause the problem. Finally, setting the content type using a real HTTP response header and not using an http-equiv <meta> tag also doesn’t cause the problem.

The fix was simple as the page we were opening was actually a frameset, so the charset setting in it could be safely removed.

This is indeed an interesting bug, to which I found no reference on the web.

Posted in HTML, IE, JavaScript | 10 Comments »

Funny unintended strikethrough in a HTML e-mail

June 18, 2006

I'm subscribed to a newsletter from Realistic Religious Zionism. In the last e-mail I got, there was a strikethrough styling in the middle of the text. At first, I thought it is some kind of a correction, but then I noticed it continued to the end of the e-mail, so I realized this was some sort of a bug.

Out of curiosity, I viewed the HTML mail source, but this was cluttered with many formatted <p>s and <span>s, so I couldn't find anything there. In particular, I didn't find the text "strike" in the text.

I saved it as an HTML file and opened it in Firefox, and the problem still existed, so I tried checking it with Firebug and saw that when the problem started, an <s> element was defined with a pan attribute. I tried to look for an "<s " in the source to find out where it is defined, but couldn't find it either.

So, having no other choice, I looked for the location of the problem in the source. This was a bit problematic since it was a mixture of an English markup and a Hebrew text. When I nailed it down, I realized what the problem is. It appears that the mail text is cut every 1048 characters, and a new line is entered. Normally, this is not a problem, since white-spaces don't count in HTML. But when it occurs in the middle of a <span> tag definition, it renders an <s> tag with a pan attribute. I didn't know that, but <s> HTML tag can be used as the <strike> tag to specify stricken-through text (BTW, both tags are deprecated by the HTML standard and the CSS alternative is encouraged). Since the <span> tag definition was truncated with a new-line after the "<s", it was considered as the definition of an <s> tag, which wasn't really closed, so it lasted till the end of the e-mail.

This problem of cutting HTML in the middle is not mentioned in the list of problems with HTML e-mails. I guess the simplest solution is just to make every HTML markup in a new line. This makes the e-mail a bit longer, but avoids such problems. However, I guess they are using some rich text editor that generates this HTML e-mail, so I don't really know what can be done with that tool.

Posted in E-mail, HTML | 3 Comments »

Problems with defaultValue

June 14, 2006

Today I found a problem in one of our screens (the filter screen) which only occurs on Firefox, but not on IE. After checking it further, I realized that the problem is with the defaultValue attribute of the <input type=text> element.

We use this attribute to store the default value of filter fields, and when the user wants to reset the filter, we set the value to the default value manually, without calling reset(). The default filter value can be set by the server administrator.

It appears that on Firefox, setting the defaultValue attribute causes the control to change its value if the user didn't change it yet. The logic is probably that if the user didn't change it, the control shows the default value, so changing the defaultValue attribute changes what the control displays, and the control's value attribute.

On IE, on the other hand, the MSDN clearly says that "The value of the property can be changed programmatically, but doing so has no effect on the appearance of the object or the submitted value."

I wanted to see what the HTML standard has to say about it, but apparently, the defaultValue attribute is a non-standard extension, supported by both IE and FF.

The solution to our problem is very simple. Use another custom attribute (e.g. defValue) to store the default value. This will have no affect, has the browsers have no special treatment for this custom attribute.

Posted in Forms, HTML, JavaScript | 4 Comments »

IE bug with a label related to select

September 6, 2005

Here is a nice IE bug I just found.
When a <label> is attached to a <select> element, and the user clicks the label, the <select> is selected (which is nice), but its selectedIndex becomes 0 (that’s not so nice).

Here is an example page.

Update: I found out that this is an MSDN report bug. See http://support.microsoft.com/default.aspx?scid=kb;en-us;314279&Product=iep. They also suggest a workaround – use the onfocusin event to store the current selection before the focus is actually moved to the list, and reset it later. However, they say “you can only work around this problem in Internet Explorer 6” – I’m not sure why, as the onfocusin event is said to be supported on Internet Explorer 5.5 and later.

However, I would suggest a much simpler solution – simply handling the label event ourselves, without IE to interrupt and destroy. In their sample, I would use:
<LABEL for=”test” onclick=”document.getElementById(this.htmlFor).focus(); return false;”>Citizenship Status:</LABEL>

In my tests, it does the job perfectly well.

Posted in From Blogger, HTML, IE | 4 Comments »