Yesterday, I saw some unusual behavior in Internet Explorer. I had a window.onbeforeunload
set and added href=”javascript:void(0);”
to an anchor tag. This works fine in Chrome, but in Internet Explorer, the onbeforeunload
message gets triggered. The only way I could accomplish what I needed was by adding that specific attribute, so I tuned to the best resource for programming ever invented: Google.
I was able to find the answer within 15 seconds of searching. This was the first result Google gave, and had a great answer to the problem:
The only solution I can see is to add returning of false
to the onclick
event handler of the links. It will tell Internet Explorer that you’re not planning to change the page by clicking on the link.
That was easy enough. I scanned the rest of the responses to see if they agreed with the suggested response. What I found was shocking:
My solution is, you need to add onclick
attribute to every chosen dropdown list anchor tag and call window.onbeforeunload = null
. In my case, I’ve put:
$(".chzn-single").attr("onclick", "window.onbeforeunload = null;");
Whenever I search Google for a question related to programming, the first few results usually come from StackOverflow.com. If you’ve been living under a rock, StackOverflow allows people to post questions, and the responses can be up-voted or down-voted depending upon their quality. Over the last few years, I’ve come to rely on it more and more to quickly answer a question.
Because of the increased popularity, there are many programmers who attempt to answer complex questions. This is not necessarily bad by itself, but can lead other programmers down a very bad path. If I was the person who asked the question, and the shocking response above was the first given, I would try it out and see that in the short term, it works. I would up-vote it, and mark it as the preferred answer.
The response does address the issue the programmer was asking for help with, but it has an unintended consequence. After clicking on the dropdown, the onbeforeunload
will be disabled. If implemented on production, end-users are going to have no idea why this behavior is happening, so they will not be very helpful in diagnosing the issue. Unless the developer is the only one working on the project and remembers they added in that assignment, they may get so frustrated that they start from scratch.
The response quoted above thankfully has no up-votes. The hypothetical situation I’ve described may not have happened in this case. But if I had a nickle for every time it did happen, then I would have a lot of nickles.
Giving programming advice is very difficult. It requires the person answering to know a lot about the context of the question, the system requirements of the person asking the question, and a whole host of other nuances.
Before implementing anything you find recommended online or even from a coworker, make sure you understand the ramifications of the solution. Programmers as a whole are given an enormous amount of trust when it comes to our jobs. One wrong commit could cause an entire website to crash for hours, causing thousands of dollars in lost revenue.
Programmers have a responsibility to understand their code. I am a big believer the programmers should take ownership of their code. When I see a bug, even a simple one, I believe it is to tell the programmer who wrote the code than fix it.
Creating a culture of responsibility is difficult, but I have found that programmers who feel responsible for their code tend to research fixes in a deeper manner than taking the first recommended solution blindly.
The post StackOverflow is the Wikipedia of Programming appeared first on Zach Gardner's Blog.