Hunting the Oasis Dropdown Menu Bug - A story and a message

Oasis Dropdown:

This infuriating visual abomination is in the game since early betas.


First let's try to figure out why it happens. If you are not interested in this skip to the end for the reason I am doing this whole thing.

Now I am not a front-end developer and I don't claim to know how to make good looking websites, hell I have to google how to center a div and my artistic talent is far below average. Hell if I made the front-end of Kingdoms, I could not make stuff properly align and scale. But the fact this overflow issue persists since the earliest betas of this game is a bit...sad. Now today I thought "Why the hell is that bug still around after so long" and took a look. In the end I more or less at least have some ideas what the core issue is, but my way of figuring that out was a bit roundabout (since I have no idea about the Travian source code), but I will take you on my little journey I think along the way we can see some places where improvements could be made.
Let's start:



By replacing the "5%" with "a", we can see that the issue disappears. We now know it is a issue with the length of the entry (as previously mentioned, an overflow issue).
Now we could just slap a "display: inline-flex" onto the whole <li> element or an appropriate div and that would fix it. Maybe even reduce the distance between the coordinates and the bonuses by changing this padding and one receives this. This is a solution, but not a great one, it is a fix to the symptom, not the cause. We have actually already seen why this issue occurs. The padding and text sizes is hardcoded in the stylesheet, as such if the box is too small, it overflows.
But why does the issue only happen sometimes? Also there should be enough space to make the box large enough to always fit. It has to do with how they calculate the width of these elements:

These are set from a script (if one changes the width, it will be reset, as such we can conclude it is set programmatically).
So let's dig a bit more. Now I am not gonna reverse engineer Travian's frontend code for every visual bug. I think showing that the width calculation is off should be enough for a dev who has the actual raw source code to go and fix it in very reasonable time. Actually figuring out that this is an issue with the width calculation and then fixing it should also be doable in very reasonable time.
Anyhow, what comes from now on is deducted from the game Javascript file the game links to in their HTML. As such stuff might be inaccurate in some instances, actually it is likely that I got something wrong.
We can see that the game creates the Drowndown menu here; I just searched for oasisDropdown since I saw that in the class of the scrollable class.


It seems that the dropdown system they use has a "resize" parameter, here set to true. I like that the "obfuscator" (it is very minimal) they use replaces true with "!0" and false with "!1" Back to the code; now it becomes a bit sketchy, because I really did not dig too deep. However if the bug lies in whatever automatically resized this dropdown menu, then the issue lies quite deep. Searching for ".resize" I found this function:


Cleaning the resize line up a bit (it was a pain actually), we get:

Essentially we are checking what is larger in width K (the dropdownHead) or I (the dropdownBody). We then take the difference and add it to the smaller one.

However if it is the head that we scale up, we consider it's outer width, in the case of the body, we use the "normal" width.

Now when the bug happens, we can see the width is considerably lower:

Now why could that be?
Initially I thought the issue essentially is that once the dropdown body is too small, it won't grow anymore. We are adapting the smaller to the bigger, but what if the content of the body grows bigger or are too large to begin with? Easy way to show this is if you make the window small and then open the embassy, then increase the window size:

Like this the bug occurs for every line.

Fun fact: when resizing it to larger again as in the screenshot above, it sometimes properly resizes the windows after resizing the game, sometimes it makes you incapable of moving the window and it is stuck in that size. That is a different bug all together.

I would argue one should replace the "width" overrides with "minimum width". But not only that, as seen when we limit the space to the right, the UI becomes almost unreadable.
Again I don't claim I have understood how the whole system works. I am more trying to make a point here. The dropdown menu should have a forced minimum size. There is some space to the left of it in all cases, we don't need to support squishing the UI to an unreasonable extend, but it should still be readable on small displays and windowed mode browsers.


Now I looked at a (at least for me) different way to trigger this bug. The bug occurs if there is no xx% | xx% oasis in the list.
See how the left one works, but the right one does not?

But this kind of goes against my initial assumption that the issue is based on the content growing. Because here the issue is "resolved" by the max2digits div being big enough and "pushing" the body to be big enough. The resizing itself works, however it contains a bug. And I am leaning far out of the window with my statements here, but on fullscreen, the width is off by exactly...1 pixel, which causes the overflow. In this case .width() and .outerWidth() round the result. So I will attribute this the individual elements width having a decimal < 5, but the sum of all having it later than .5. Is this the bug? Maybe? Maybe not? There is a more fundamental issue here. When the width derived

In conclusion, there are several flaws with this system that make it not work on several screen layouts, but most annoyingly, it breaks 100% of the time in fullscreen when there is no max2digits oasis element in the list, because the whole box is a single pixel off. Funnily enough thought, when in windowed mode, but still decently sized, the dropdown is off by more than 1 pixel though, so take my conclusions with a grain of salt. Overall the system itself needs an overhaul with proper scaling.

A temporary workaround for now is to add a "inline-flex" display style to the individual <li> elements. That fixes the full screen bug and still looks okay(ish). Fixing the rounding error would also be nice. However to fix the overflow issue on all reasonable resolutions, please rework the way the front-end rescales the dropdown menu in itself. It does not use all the space it could.

Conclusion:
Lastly, I really REALLY hope some of these old bugs can be fixed. Issues like this persisting give of the feeling of "nothing is being worked on", "the game developer company is not listening to the community", etc. The frustrating thing is that everybody has these bugs, without exception. They are easy to reproduce, we all know them.
Play your own game, we all face the same 30 bugs for the last 7 years, and half of them are really not that hard to figure out, or at least there are easy workarounds. Some of the big problems of the game are not stuff you can fix in a day or two, but these kind of small issues really should not last long after being reported.

(PS implement proper data encryption with a nice obfuscated and often changed cryptographic function please, thanks )

Cheers

I like the "cheat" endpoint they have for testing. I assume it is deactivated for normal users, but certainly bad practice to not remove stuff like that from release builds, as it just invites people to try to find exploits there