As developers we find and troubleshoot bugs everyday. What was the strangest bug you've ever stumbled upon?
For further actions, you may consider blocking this person and/or reporting abuse
As developers we find and troubleshoot bugs everyday. What was the strangest bug you've ever stumbled upon?
For further actions, you may consider blocking this person and/or reporting abuse
Latest comments (36)
;
😂 And that's how to shorten battery life effectively.
Today I had a github bot go wrong and my all my Ci's ran 800 (not Kidding) times they all failed and ended up in my inbox.
🤖😜 Someday the bots will take over 😅
My favorite bug has to do with not software, not coding, but my last desktop build. Four hours later after two trips back to MicroCenter that day already, I had it "done" and booted it up, and got to install Windows. Another few minutes after getting things installed on my Windows profile, it blue screens. So, I do start it up again, and lo and behold, another blue screen. And I think even some memory dump, too.
The reason?
It overheated.
Because I forgot to buy a heatsink. And put it on a supercharged 4.2Ghz i7.
I literally nearly burned $2000 from heat in the first day I had created that monster.
Hearing the frequency of static in my headphones increase and decrease as I moved my cursor from top left to bottom right of my screen
This got a good laugh out of me for just the idea of doing sweeps with your mouse
Everytime I inserted headphones into my Huawei's headphone jack, Google Assistant was activated. I guess that there are some accessibility devices for disabled people that work through the headphone jack's connectors. Because there was some dust in my headphone jack, the connectors got either short-circuited or triggered in a wrong way, idk. After I cleaned the port and removed the dust, everything worked well again.
MYSQL insert with the correct time stamp in the correct format but SELECT the same record and it is wrong. To this day I haven’t found a solution.
The Stacking Context in CSS. More specifically, that there are a few CSS properties that can trigger a stacking context. And even more specific, that particular properties, in particular browsers, will give you very different results within that stacking context.
It'd started with a simple request to remove a double-scroll bar that was displaying in certain browsers. Over the course of a month I reviewed every CSS property on every element until I discovered that we'd unintentionally created a new stacking context, and that CSS we'd written accidentally handled that very well... until it didn't.
I ended up editing the mozilla developer network page on stacking contexts, and producing the most boring codepen ever that illustrates exactly how certain CSS properties totally bork stacking contexts.
took a month to discover that no one on the internet had, until then, documented that
perspectivewould change the behavior ofposition:absolute. That double scroll bar was the hardest bug I ever tackled, but is also one of my proudest moments.I've never heard of stacking context in css!
What is it?
The stacking context is the ... well "context" in which the browser determines how to layer things. We hardly ever think about stacking context and it hardly ever matters.
But stacking context is about paint order ; when the browser has elements that overlap, the browser has to know which element to draw first, and which to draw next.
contrary to popular belief, z-index hasn't anything to do with positioning but with painting. When we have overlapping elements, and the browser is painting them in an order that we don't want, we use z-index to change the order in which the browser draws them.
So, that means that "the order in which the browser draws them" has to be determined some how. So what the browser does is find "root contexts" to determine which elements need to have their drawing order sorted out. Think of these "root contexts" as buckets with sheets of paper.
The bucket is any element with
position:fixed,absolute,perspective,transform, etc. When the browser encounters those, it says, "aha! I need to make a bucket with this, and then figure out the order in which to paint things". That's your stacking context.You can live a happy and fruitful career never having to think about this.
But occasionally you will discover that the browser sometimes has some strange rules about how it creates stacking contexts. Sometimes the browser has to change the rules of the bucket just to figure out how to paint those sheets of paper.
A great example of this might be an element that's
position:fixed, with a parent container that hasopacity: .2.That
position:fixedchild element is _supposed to be` wherever you intend it to be, relative to the browser window.But you see, it's inside of an opaque parent.
The browser is supposed to show just a little bit of the element underneath that parent, because the parent is opaque. That means the grandparent is supposed to influence the look of the grandchild.
But how can it do that if the grandchild is
position:fixedand nowhere underneath this opaque parent? So the browser makes a decision:I will create a "Positioning context" that matches the stacking context.
So what happens is
position:fixedbreaks . It's no longer relative to the window, it's relative to that parent that hasopacity: .2.Again, you can live a fruitful live never knowing about the Stacking Context because it mostly never matters. But there will be rare times where the browser can't reconcile these CSS properties where layering matters with other CSS properties where positioning matters, and it creates a new "positioning context" that matches the stacking context.
In short: positioning and z-index. Paceaux provided a link with a detailed explanation. Here is an example:
Encounter strange bug:
git reset --hard, retype the exact same code, and it works. :shrug:I used to work on an application that colleges used to process certain types of applications. College could create their own forms. When the user was done, it would compile the answers into a PDF and mailed out to relevant people.
For one client, the PDF would come in empty, but only 10-20% of the time. We couldn't figure out why.
I spent three days tracking down a bug in legacy code that ended up being a bug in PHP itself. . Our system did a lot of parsing of the data to move in between different formats. When you did a Regex find/replace, the method should return the updated string. If there were no matches, it should have returned the original string.
BUT
If you passed in a string over a certain length, and there were no matches, it would return null instead. This one client ask a lot of essay questions. The script would only fail for the most verbose students.
We couldn't patch PHP, so we wrote some checks to strip useless markup and keep strings under the limit.
Good gracious. I've had to deal with similar bugs in APIs that have string limits as well, always very annoying to deal with. But never anything that strange.