Skip to main content

How the smallest bugs can take the most time to solve

For the past few weeks, I have been fixing problems that I run into while testing some of the new video tools that Michael Dale has been developing for the Wikimedia Foundation. As with any new software, especially Javascript tools, there are plenty of issues and since I can find them, I might as well fix some of them, instead of throwing it all back at Michael.

This week I ran into one particular annoying issue. For some reason the menu in the new mwEmbed mediaplayer (Demo of the player) was flickering under certain conditions on Safari. I created a video that demonstrates the problem.



So I was looking trough the code of the player, trying to come up with a reason on why this would behave like this and why only in Safari. I spent a few hours tracking all the events, assuming that some event (like mouseover) for some reason was incorrectly telling the menu to hide itself. I was validated in this line of thought by observing that manipulating some of the Javascript events of the player, would influence the time the menu would reappear. I could however not find something that influenced the hiding of the menu. The fact that jQuery uses anonymous functions everywhere didn't make the debugging process any easier.

My other idea was that perhaps it was a bug in the HTML5 <video> element of Safari, or in the XiphQT plugins used to decode the video in combination with z-index or relative positioning. I created a few testcases from scratch, but neither proved to be likely. I could not figure out what the problem was.

After some discussion with a few Webkit people, I decided to reduce the original HTML. The original HTML is a lot of code, which was why I was reluctant at first to take this path, but all other options had run out. After some heavy reducing, I figured out that Javascript was no factor here, pure HTML and CSS showed the same problem. This took me by surprise, since I had earlier observed how certain JS events were causing the menu to reappear. Cutting and weeding some more I finally found the cause. The three elements that are needed to reproduce the problem.

  1. An HTML5 video element
  2. An overflowing element in scroll mode, on top of the video element
  3. Opacity set on that overflowing element.

Finally I had traced the issue and it turned out to be a bug in Safari/Webkit. The reason as to why the Javascript event manipulation would influence the problem was easy to understand in retrospect. Such events were triggering redraw events in the browser, which for some unknown reason solves the drawing problem caused by the scrolling event.

Hours of debugging for a small issue, that had its root cause in a browser bug. A ticket has been filed with the Webkit developers, but it shows how developing for new browser features continues to be a time consuming process. All new code has bugs, and when the new code is relying on other new code, finding those bugs takes quadruple the time.

Comments

  1. "The fact that jQuery uses anonymous functions everywhere didn't make the debugging process any easier."

    You can "name" functions by setting their displayName property in Safari. jQuery event handlers are easily accessible via $(e).data('handle') and the original functions via $(e).data('events')['eventtype'][i].handler; it is easy to pass the name of the original function (or whatever else) as displayName to the handler.

    ReplyDelete

Post a Comment

Popular posts from this blog

kAMDReceiveMessageError

We kept running into a kAMDReceiveMessageError in our company, when trying to install adHoc iPhone apps with the iPhone Configuration Utility for Windows. Everything was fine if people tried to install using Windows iTunes. After much time it was tracked to the addition of UIRequiredDeviceCapabilities to the Info.plist. For some very strange reason it seems that the Windows ICU doesn't like that property at all and fails to install any app that carries it. Not sure if this will affect AppStore submission, iTunes handles it and so does the Mac version of ICU it seems, but it is at the very least mildly annoying that testers can't install our application using Windows ICU.

HTML 5 video player for mediawiki now with fullscreen support

Michael Dale has been working hard on a new media player for the mediawiki projects. This media player is based on the HTML 5 <video> tag . You can compare it to the demo players of Youtube and Vimeo and DailyMotion . It should support Firefox 3.5, Google Chrome 3, Opera 10.5 and if you install the Xiph QuickTime components it works with Safari 4 for the Mac. If your browser doesn't support HTML5, the player will use the JAVA cortado player , like it does in the old version of the Ogg player. Recently both Apple and Firefox introduced Fullscreen support for the <video> tag in their development versions of the browsers, and these features can now be used with the new player for Wikimedia. The controls automatically show and hide, and you can even add and display subtitles with it. How do I test it ? It is rather easy, you go to this example video . If you want to enable it for all videos, you need to be registered on Wikimedia Commons or the English Wikipedia . You

Template editor

The Wikipedia Usability Initiative is finally making good progress on their template folding and template editor. Much of what the project has been doing with the edit screen has been in preparation of this work. The editor now folds complicated templates into a small block. One of the sandboxes the project uses now has the code deployed and it seems to be working quite well. Be aware that this is a development platform, and that browser peculiarities might not be fully dealt with yet. It is also NOT final. The wiki editor with folded templates. You can unfold the block, by clicking on the arrow to show the template code, or you can click the block and you are presented with a template editor that makes it easier to change the values of the template. This should be very helpful, because research showed that much of the trouble people had with editing Wikipedia, was the complex code on the edit pages. The template code is by far the most obscure and complicated code of all our wik