One of the most frustrating things in software development, when using third-party components, is unexpected functionality. I’m purposely distinguishing unexpected functionality from bugs because it comes down to context. Here is what I mean by that. If a given component does not work according to its design, that is a bug, a failure of functionality. However, when using a component in a manner that it may have not been expressly designed, it may exhibit unexpected functionality. What ends up happening is a bug report is opened and the waiting game begins, hoping that a fix will be released soon. In general, that is what happens. And, there is no guarantee that the deficiency will be addressed. That’s where I found myself this weekend while working on a project.
This past weekend, I started building a demo Blazor application using MudBlazor components. One of the requirements is an app menu located at the top of the page. My original plan was to use MudNavMenu, but it only supports vertical alignment. To satisfy both the menu location and horizontal layout requirements, I nested a MudNavLink in a MudNavMenu item and the menu items in an MudAppBar. So far, so good. Everything was looking great! Then, I needed to create menus that contained multiple links and sub menus. The MudNavGroup solved that problem. And that’s where things got…interesting.
The expected behavior for an app bar item is for its nested children to descend since the app bar is at the very top of the UI and any ascension would be off-screen. Remember earlier when I said things got interesting? Here’s what I mean. Imagine my surprise when I clicked the sub menu to open it, it opened as expected and then all the content scrolled up! All I could see were the sub-items, not the parent. To close the sub menu, the parent must be clicked. For that to happen, it must be on-screen to be clicked. In this case, it was off-screen and, therefore, unclickable. Unexpected functionality. That was new. I’ve never seen anything like that before.
I spent the next several minutes using the browser dev tools trying to figure out this odd behavior. I knew it was related to CSS, but didn’t know where to start. After an hour’s worth of trial and error, I finally found the root cause. There was a style applied “style=”height:auto”. And so began the mystery. How was this style being applied? The answer lies in the beauty of open source!
What is open source? You can find the definition here. MudBlazor is open source and the code is available on Github. I forked the code and started my research. Since the unexpected functionality was related to MudNavGroup, I began there. What I found is it has a child component, MudCollapse, which was applying the style that was causing the issue. Given that a lot of Blazor developers use MudBlazor components, I went to their message board to see if anyone else has already reported the issue. Eventually, I discovered that it had been reported last year. Not only that, but that it had not been acknowledged. So I took that to mean that there are no plans to do anything about the reported issue. Therefore, I took it upon myself to fix it.
