--- title: "The bug on a browser we did not have" description: "Product titles overflowed on phones and nowhere else. Three environments that claimed to be the mobile rendering all said the page was fine. Counting one CSS value across the live page found the cause without ever reproducing it." date: 2026-08-27 lang: en canonical: https://goingstellar.ro/research/the-bug-on-a-browser-we-did-not-have/ author: Going Stellar publisher: GOING STELLAR S.R.L. topic: Debugging license: CC BY 4.0 alternate_ro: https://goingstellar.ro/ro/cercetare/eroarea-de-pe-un-browser-pe-care-nu-l-aveam/ --- # The bug on a browser we did not have *Product titles overflowed on phones and nowhere else. Three environments that claimed to be the mobile rendering all said the page was fine. Counting one CSS value across the live page found the cause without ever reproducing it.* > Debugging · 2026-08-27 · https://goingstellar.ro/research/the-bug-on-a-browser-we-did-not-have/ ## Key points - Mobile emulation changes the viewport and the user agent, not the engine that resolves the CSS, so it cannot reproduce a rendering difference between engines. - When a page renders wrong only on a device you do not have, stop trying to reproduce it and count values in the live HTML instead. - The declaration -webkit-line-clamp: 0 is invalid; desktop engines silently treat it as none, while one mobile browser applies it and collapses the text box to a single line. - A rare value is the cause only if the elements carrying it are exactly the broken ones; a value that also covers healthy elements is a weaker signal. ## What the page did On a shop's home page, product titles overflowed onto the badge and onto the price. Only on phones. On every desktop surface we had, the same page rendered correctly. The shape of the failure matters. This was not text wrapping awkwardly into a container that was slightly too small. The text box collapsed to a single line while the text carried on being painted across three or four lines, straight over whatever came next. The browser in question was not on any machine we owned. That is an ordinary situation, and the reflex is to reproduce the defect first. We took that route, and it cost us. ## Three environments, and all three were wrong First attempt: a desktop browser with mobile emulation. The page rendered correctly. Second: the page builder's own editor. Correct. Third: we wrote a small native app that wrapped the platform's web view and loaded the page inside it. Also correct. Three environments, each claiming to be the mobile rendering, and all three were wrong about it. Emulation changes the viewport and the user agent; it does not change the engine that resolves the CSS. The builder's editor runs inside the desktop browser you already have open. The web view we wrapped resolved the declaration exactly as desktop did. The general form is worth stating plainly: time spent trying to reproduce a bug is wasted whenever the bug is a rendering difference between engines, because the reproduction attempt is asking the wrong engine. Every *it works here* was a true statement about the wrong thing. ## Counting instead of reproducing So we stopped reproducing and started counting. We pulled the live page's HTML and built a histogram of one custom property across every text block on the page. 42 blocks carried the value **unset**. Every one of them rendered correctly. Exactly 6 carried the value **zero**. They were exactly the 6 broken ones. Same CSS rule, same page, same browser. The only difference between the healthy set and the broken set was the value. That is a controlled comparison, and the live page had already run it for us — we only had to read it off. ## Why zero collapses the box The builder's "maximum lines" setting, when left at zero, emits the declaration **-webkit-line-clamp: 0**. Zero is not a valid value for that property. Engines disagree about invalid values. Desktop browsers, the builder's own editor and the desktop web view all degrade this one silently to **none** and render as though it had never been written. One mobile browser applies it literally: the text box collapses to a single line while the text carries on being painted across three or four lines, overflowing whatever comes next. There is a second trap in the same control. The "off" switch writes zero as well, so "no limit" and "a limit of zero lines" reach the browser as the same declaration. The only safe state is "on" with a positive number. ## How to run the same check When something renders wrong only on one device class, and you do not have that device class, stop trying to reproduce it and start counting. Fetch the live HTML. Extract every value of the suspicious property or custom variable. Build a frequency table. Then look for the rare value and test membership: are the elements carrying it exactly the broken ones? *Exactly* is the word that does the work. A rare value that covers the broken elements and some healthy ones as well is a weaker signal, not a cause. If the match is exact, you have your cause without ever owning the device. All you need is the list of broken elements and the markup, which you can fetch from anywhere. ## Limitations This works when the failing elements are numerous enough to compare against healthy ones on the same page. A broken element with no healthy counterpart beside it gives you nothing to compare against. It also requires the difference to be expressed in the markup rather than computed at runtime. A value written by script after load, or resolved from a media query that the fetch never triggers, will not appear in the HTML you pulled. Finally, it identifies a correlation on one page. It does not by itself prove the mechanism. For that we still had to know that zero is invalid for that property, and that engines disagree about what to do with invalid values. ## Questions and answers ### Why does text overflow on phones when mobile emulation shows the page correctly? Text can overflow on phones while mobile emulation shows the page correctly because emulation changes the viewport and the user agent, not the engine that resolves the CSS. In one case, product titles collapsed to a single-line box while the text kept painting over the badge and the price. Desktop emulation, the page builder's editor and a wrapped web view all rendered correctly, because each asked the wrong engine. ### What does -webkit-line-clamp: 0 do? The declaration `-webkit-line-clamp: 0` is invalid, and browser engines disagree about what to do with it. Desktop browsers and the desktop web view silently degrade it to none and render as though it had never been written. One mobile browser applies it literally, collapsing the text box to a single line while the text carries on painting across several lines over whatever comes next. ### How can I debug a rendering bug on a browser I do not have? Debugging a rendering bug on a browser you do not have works by counting instead of reproducing. Fetch the live HTML, extract every value of the suspicious property or custom variable, and build a frequency table. On one page, 42 text blocks carried unset and rendered correctly, while exactly 6 carried zero and were exactly the 6 broken ones. An exact match identifies the cause without owning the device. ### Why does a page builder's maximum lines setting break product titles on phones? A page builder's maximum lines setting can break product titles on phones because, when left at zero, it emits -webkit-line-clamp: 0, which one mobile browser applies literally. The off switch writes zero as well, so no limit and a limit of zero lines reach the browser as the same declaration. The only safe state is to switch the setting on and give it a positive number. ### When does counting CSS values fail to find the cause of a bug? Counting CSS values fails to find the cause of a bug when there are no healthy elements on the same page to compare with, or when the difference is computed at runtime instead of written in the markup. A value set by script after load, or resolved from a media query the fetch never triggers, will not appear in the fetched HTML. The method shows a correlation; proving the mechanism needs more. ## How to cite **Cite this as:** Going Stellar (2026). *The bug on a browser we did not have*. GOING STELLAR S.R.L.. https://goingstellar.ro/research/the-bug-on-a-browser-we-did-not-have/ ```bibtex @misc{goingstellar2026the, title = {The bug on a browser we did not have}, author = {{Going Stellar}}, year = {2026}, url = {https://goingstellar.ro/research/the-bug-on-a-browser-we-did-not-have/}, note = {2026-08-27} } ``` Licence. Free to quote with attribution. ## Also available - This page as HTML: https://goingstellar.ro/research/the-bug-on-a-browser-we-did-not-have/ - Same article in Romanian: https://goingstellar.ro/ro/cercetare/eroarea-de-pe-un-browser-pe-care-nu-l-aveam/