Blogging is... contagious

Tuesday, August 05, 2014

It's not often I make the effort to blog (as you can tell from the date of my previous post!) but IE11's localStorage has got me to the point where I need to rant about it somewhere, and it may as well be to the Internet!

What's particularly disheartening about this is that IE11 seems to be worse than its predecessors.

These two issues together have both combined to cause me great headaches over the past week, but I've now found something that's arguably worse than both of them.

Setup I'm using: IE 11.0.9600.17207 on Windows 7 Professional SP1

You can test this here, but here's the code anyway if you want to try it yourself or if the link dies in future:

Overview

You can see for yourself from the code that clicking one of the "Store" buttons places a value into localStorage, and you can then retrieve this and display it with the "Show value" button. The value it stores is simply A or B (depending on the button you press), followed by the letter 'a' several times, based on the number supplied in the text box.

Steps to reproduce - part 1

Open the page in 2 separate tabs (or windows if you prefer) of IE11.

Leaving it at the default number (2000), click Store w/ A in Window 1.

Click Show value in both windows, and you should see that a long string beginning with A has successfully been retrieved and displayed in both windows.

Prove it again by this time clicking Store w/ B (again in Window 1), then repeat the last step to display in both. All looks good.

Now in Window 1, change the number to 2500, before clicking Store w/ A. Verify it's been stored away by clicking Show value in Window 1.

Finally, click Show value in Window 2, and see what happens.

Lolwut? That's right, absolutely nothing happens. Presumably the value was just too long for IE to be bothered to make it available to any other tabs.

Steps to reproduce - part 2

Using Window 1, reset the number back to 2000 and click Clear. You can click Show value in both windows to show it's been cleared (you'll see null on screen).

Repeat the very first test by clicking Store w/ A in Window 1. Prove this worked by retrieving/showing in both windows.

Now in Window 1, change the number to 2150, before clicking Store w/ B and verifying you can retrieve in both windows as usual.

Next, leaving the number at 2150, click Store w/ A in Window 1. Prove you can retrieve in Window 1.

Maybe this time, 2150 seemed OK first time round, but it didn't have enough energy left to move something the same size more than once? Who knows. All I know is that localStorage is broken in IE11, and it's not making my job any easier. :(

It also says:the data source will cache data until the XML file that it depends on is changedWhich would be fine, only my data source object isn't depending on a file, and I'm setting its Data property manually. Unfortunately, setting Data to what you want doesn't appear to invalidate the cache, and so you end up with what was there previously anyway.

But hang on a minute - the docs for XmlDataSource.Data specifically say:If caching is enabled and you change the value of Data, the cache is invalidated.I don't believe you!

Another bit of my life I'm never getting back, finding that little nugget...

Tuesday, May 18, 2010

After a slight *cough* gap since my last post, I figured I should at least come up with something potentially useful to people this time.

Having just started a new role working on a bespoke ASP.NET application, I thought I'd push the case for introducing jQuery into the codebase to help with any client-side requirements. I was asked to give a presentation it to the dev team to get their views, so I spent today coming up with a self-contained demo, using jQuery itself.

I'm by no means a jQuery expert - I've essentially read half a book on the subject and slideToggle()d a couple of <div>s before - but I came up with the rest of it in less than a day, which probably says at least a little about how easy it is to get to grips with.

Anyway, without further ado... I present my short and sweet jQuery Demonstration. A couple of points to note:

You step through the demo by clicking the "jQuery" title at the top of the page;

You can click on the first grey markup block at any point to update it to show the current structure of the DOM;

When you get to the Gallery part, once the click handler has been attached to load the gallery HTML in the background, do actually click the Gallery header to load it before clicking the main jQuery title to get to the next (and final) step!

Friday, April 27, 2007

I'm currently writing unit tests for some code that uses the information found in the Headers property of an HttpRequest object. As such, I want to be able to create my own HttpRequest object with the appropriate headers.

This isn't as easy as I'd like it to be, as presumably the intent for the class is that you're handed an instance of it at the appropriate time, rather than putting one together yourself (which is fair enough).

Tuesday, March 20, 2007

Had some fun tracking this one down today, fortunately someone else had already done the hard work in working out how to fix it.

Essentially I was trying out a basic AJAX page in an existing 2.0 web application project. The various additional required sections were added to the web.config and I followed the Introduction to the UpdatePanel control, where a label is updated when you click a button.

Simple. Or so you'd think. No AJAX behaviour for me - it was performing a full postback.

Fortunately I managed to find a post from "Rick" that explained what the culprit was - the <xhtmlConformance mode="Legacy"/> in the web.config. Commenting this out gives the desired behaviour.

I must admit I haven't bothered investigating any further to work out why that works - feel free to let me know.