Category Archives: Debugging

IE10 Gotcha: Optgroup Indexes and the Required Attribute

Leave a reply

I came across a rather interesting gotcha in Internet Explorer 10.0.9200.16519 this evening (via @dstorey, who showed me this question). Setting the required attribute on a select element that has various optgroup elements within may result in unexpected warnings upon form submission.


The above form will be “invalid” if the index of the selected option among its siblings matches the index of its parent optgroup among its siblings. So the first optgroup and the first option will trigger the unexpected results when the parent select has the required attribute.

This pattern is consistent with the second, third, and fourth optgroup elements. Selecting the second option in the second optgroup, or the third option in the third optgroup, will cause form submission to fail.

Workarounds

I have found only one way around this, but it may not work in most situations. Adding the multiple attribute to the same select will prevent the confusing behavior, but at the cost of affecting the presentation and behavior of your element. The size attribute could remedy this to some degree, but is not favorable.

Sometimes Chrome is the broken browser (Or, How Chrome failed me twice in one night)

6 Replies

For several years it’s been generally accepted by the web-development community that Internet Explorer is nothing more than a means by which developers are subjected a great deal of emotional and mental trauma. Well, that has changed in the last couple of versions, but most developers are still licking their slow-healing wounds.

One thing that bothers me though is how so many automatically feel as though these types of issues only exist with Internet Explorer, generally touting Google Chrome as the full-featured flawless alternative. Granted, Google has done an outstanding job with the Chrome browser, and I personally use it for most of my work, but Chrome is in no way special. It too is capable of causing a lot of upset – such was the case this evening for me.

I worked on a couple of marquee demos over the last few days which gave me another idea. I wanted to cover an element with its ::after pseudo-element, apply a transparent-to-black background on the pseudo-element, and then animate it off to the right using @keyframes. I didn’t want this to be visible as it moved off to the right, so I applied a parent element of the same dimensions, and set its overflow to hidden. Queue the tears.

Chrome 24, wouldn’t respond. It just sat there, frozen. I could have sworn I did something wrong, but the demo was so simple in its construction. Where was I going wrong? I ended up testing the same demo in Internet Explorer 10, and found it it immediately kicked off without any problems. So, back to Chrome – it turns out there was a question on Stack Overflow asked some time back regarding this very issue, which led me to news that Chrome had apparently fixed this in version 26 (unstable at the time of this writing).

Opening up Canary, I was pleased to see that my pseudo-elements were indeed being animated. Nice work Chrome! This was the first issue tonight where Internet Explorer 10 was working as expected, and Chrome was not. Next I noticed the pseudo-element bleeding out over the rounded edges of the parent; that’s not supposed to happen when you’ve got overflow:hidden set – right?

Back to Internet Explorer 10, I confirm that overflow:hidden does as it advertises, and the pseudo-element is not visible outside of its parents rounded corners – way to go Internet Explorer 10! But I still needed an unequivocal demonstration of this bug to confirm if Chrome was indeed busted, and misbehaving. That demo is now available online. As of today (January 20, 2013), this demo is broken in all versions of Chrome, but working in Internet Explorer 10 and Firefox.

So what’s the story here? The take-away is that Internet Explorer is no longer the browser it used to be. It’s a fully-qualified modern browser capable of some really killer things. It is well-built, and carries as much respect for standards as its competition. Chrome, on the other hand, did not come down to us from the gods of Mount Chrominus. It too is flawed in some ways, while brilliant in others.

Jumping on the one-browser-to-rule-them-all bandwagon doesn’t help the developer’s plight, it worsens it. Advocate standards, not browsers. Get behind good practices such as progressive-enhancement, feature-detection, and when necessary polyfills. Don’t champion a browser, champion the web.

Sometimes Chrome is the broken browser – it happens.

CHROME, Y U NO ANIMATE PSEUDO-ELEMENTS LIKE IE10?

Active-Filtering of the Session List in Fiddler2

Leave a reply

I use Fiddler2 daily – it’s one of the greatest debugging tools I’ve ever come across. You can hammer into the traffic coming and going across the tubes and tamper with the data as you like. You can substitute alternative local data in the place of remote server responses. You can modify headers on the fly. And this doesn’t even begin to scratch the surface of all you can do.

One of the problems I have is that, like many of you I’m sure, my browser is hardly ever doing one thing. Although I may be trying to debug a web-app, I may also be tied into my GMail inbox, streaming some music over Turntable, or watching the flow of tweets glide across @jonathansampson. All of these items cause sessions to be logged in Fiddler, adding a whole lot of noise to what I’m trying to work on.

So what do you do when you have specific hosts that you want to track? You make use of the Filters tab.

This highly-customizable tab will provide active filtering of the sessions coming across your screen. You can instruct it to show only intranet traffic, or only internet traffic. You can explicitly ignore particular hosts, or you can ignore everything but a select few. As my earlier summary of Fiddler didn’t begin to scratch the surface, neither does my explanation of this panel begin to touch on all that the Filter feature is capable of.

Have a look.

What I’ll be looking at here is the first part, the hosts section.

For starters, we need to click the “Use Filters” check-box to enable this feature. Now in my particular situtation all I want to see is anything that comes from a particular domain, such as microsoft.com. This would include any subdomains as well.

The first thing I will do is select “Show only Internet Hosts” from the first dropdown. From the second dropdown, I’ll select “Show only the following Hosts”. This enables the textarea below, which will take a series of expressions or explicit domains to watch for.

Insert *microsoft.com and you should see the textarea turn yellow, informing us that “Changes not yet saved.” At this point, click the Actions button to the top-right, and select “Run Filterset now”. If you already had sessions from your target domain in your session list, those should be all you see in there at this point.

From this you can infer how to go about blocking only particular domains, and various other things. You might even dare to venture into the rest of the filter options, creating a highly-customized instruction set. If you do, be sure to save your filter from the same Actions button we used to run the filterset.

I find this to be an enormously helpful feature, and I’m sure you will as well. Now if you’ll excuse me, I’ve got some work to do and very little noise preventing me from getting it done, thanks to Fiddler.