User Actions Shouldn’t Interrupt Critical Stuff

closeThis post was published 10 years 8 months 11 days ago. A number of changes have been made to the site since then, so please contact me if anything is broken or seems wrong.

Yes, I know that’s a rather cryptic title. I’ll do my best to illustrate what I mean in the coming prose. This was all inspired by something that happened to me last night while using the Blackboard Learning System software (it’s Web-based) to try and take an assessment in one of my courses for school. (Inspiration from homework? It’s actually happened before, like when I blogged about annoying network-storage habits.)

All right, down to business. Specifically, what happened last night was that I tried to perform an action on the page before it had finished loading. The tests in Blackboard (at least recent versions of the software) have a bar near the top that contains status information on each of the questions, but it is collapsed by default. Clicking the header makes it open up and actually display useful information. Simple JavaScript, but the action of expanding that box had catastrophic results.

Oh, it expanded just fine; there’s no question that it functioned correctly. But that function wasn’t isolated. Immediately upon my click, the entire page (well, frame; Blackboard still uses that anachronistic design feature) ceased loading. Now, that was a problem, because the buttons to manage the test are at the very end. Uh-oh.

I had before me 25 out of 29 questions, with no way to save my answers and continue, nor to submit the test incomplete. My curiosity definitely caused a problem. But it didn’t have to be like that.

Unfortunately, I don’t have the luxury of scrutinizing the source code of the page for this post. That would necessitate sacrificing another test attempt (and would require me to send another email to my teacher requesting a reset). I can still theorize as to why the problem happened, and brainstorm possible solutions.

First, the cause. While I can’t access the page source, as I said, I suspect there was something in the way the expansion link was constructed that caused a navigation event in Internet Explorer (Blackboard doesn’t always play nice with Firefox, in my experience, so I use IE6).

Many JavaScript effects are created using an onclick attribute and href="#". I know that when I click a hyperlink on a page in Firefox, anything still loading on the current page is dropped and the new site begins to load. Internet Explorer probably does the same thing. By clicking the link to expand the box, I may have caused IE to try and find an unnamed fragment on the page; and since even navigating to a fragment counts as a navigation, I probably stopped the page loading myself.

I’m not saying that’s what had to happen — that there is no way to prevent it from happening. I’m merely theorizing. If the function or statement called by onclick returns false, the browser shouldn’t navigate. That’s what Firefox does, at any rate. So perhaps there was a missing or incorrect return statement in the function call. It’s also possible to use another tag, like a <span>, to create the link and style it with CSS. The onclick is valid on every element I can think of, and the superfluous href wouldn’t be a problem.

Aside from changing the way that box is coded, there is another easy solution to the problem: The “Save” and “Submit” buttons could be duplicated at the top of the assessment page. This is certainly not the first time I’ve had this problem; it’s just the first time it’s happened to me on the initial load of a test. (I can usually go back to a previous page and try again to load the refreshed version of the test.)

I believe this might be considered a race condition, in that the behavior of the assessment page is dependent upon when user interaction begins. Race conditions are nasty things, of course, and they’ve become the bane of any programmer’s existence. I’m new to the concept, though, since I’ve been fortunate enough to avoid them in my own work. I usually hear about them in the context of JavaScript, come to think of it.

The take-away message from this post is not that Blackboard itself has a big problem. I’ve gone quite a while without this being an issue (nearly four years, actually). The real issue is that this could happen in a more critical situation, like a Web-based management console for, say, a nuclear reactor or weapons system. (More realistically, flight-control or remote monitoring, but the others sound more dire. 😉 An error such as this could cause enough of a lag that an operator would be unable to correct a problem in time and the system could cause a disaster.

In short, the moral of this story is that user interaction shouldn’t interfere with critical internal functions in an application, whether Web-based or otherwise. The next time something like this happens, the consequences could be more than a simple locked test.

If you’re interested in a story created around a similar event, be sure to check out the fictionalized version of events on The Queiba Wars. CodingExperiments.com has a more general summary of this kind of problem as well, should you be interested in that.

dgw

I am an avid technology and software user, in addition to being reasonably well-versed in CSS, JavaScript, HTML, PHP, Python, and (though it still scares me) Perl. Aside from my technological tendencies, I am also a theatre technician, sound designer, violinist, singer, and actor.

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail (or subscribe without commenting)

Comments are subject to moderation, and are licensed for display in perpetuity once posted. Learn more.