Hmm... subscript on the last line of topic text appears to make the scrollbar appear. That's a new one for the issues tracker. Thanks for discovering it. ;)
Hmm... subscript on the last line of topic text appears to make the scrollbar appear. That's a new one for the issues tracker. Thanks for discovering it. ;)
61.0.2 Just checked Chrome (68.0.3440.106) and Opera (54.0.2952.71) which are both the latest versions, and it shows up in those for me as well. Could this maybe be a system font issue rather than...
61.0.2
Just checked Chrome (68.0.3440.106) and Opera (54.0.2952.71) which are both the latest versions, and it shows up in those for me as well. Could this maybe be a system font issue rather than a browser specific one?
edit: My Firefox is rendering the text using Segoe UI. I have no idea how to check which of the fonts from the font family is actually being used in Chrome or Opera though.
Yeah, it appears to be Segoe UI subscript that is causing the topic-full-text div to overflow. I switched the text font to Arial and the scrollbar disappeared. How very odd.
Yeah, it appears to be Segoe UI subscript that is causing the topic-full-text div to overflow. I switched the text font to Arial and the scrollbar disappeared. How very odd.
Can you do me a favor and check which font Firefox is actually using for this page on your system? If you inspect the top-text element, in one of the inspector panes there should be a Fonts tab...
Can you do me a favor and check which font Firefox is actually using for this page on your system? If you inspect the top-text element, in one of the inspector panes there should be a Fonts tab that tells you the specific font being used from the font family. I am curious to know if yours is also using Segoe UI... and if it is but you're not getting the overflow then I have absolutely no idea what could be possibly causing this. :/
LOL... well, crap. I was hoping yours was different so at least the issue could be isolated. Now we're back to square one and I honestly have no idea what could possibly be causing the discrepancy...
LOL... well, crap. I was hoping yours was different so at least the issue could be isolated. Now we're back to square one and I honestly have no idea what could possibly be causing the discrepancy across the same browser on different systems and yet similar behavior on others.
Yeah something with the subscript text is clearly breaking the display: block scaling and triggering the overflow in some cases but not others. I don't know what could possibly be the cause if it...
Yeah something with the subscript text is clearly breaking the display: block scaling and triggering the overflow in some cases but not others. I don't know what could possibly be the cause if it isn't the font, although it probably doesn't help that I am trying to diagnose this while lying down flat on my couch using my TV as a monitor while also having been up for 20+ hours though. :P
So I guess I will have to shelve it for now until I get some sleep so can think straight and actually sit at my desk. I will let you know if I figure it out after I wake up (if you haven't already by then). ;)
I think you might actually be on the right track with this... I'm running Xubuntu 18.04.1 64-Bit for these tests. The browsers I have installed are Firefox Quantum 62.0 and Chromium 68.0.3440.106....
I think you might actually be on the right track with this...
I'm running Xubuntu 18.04.1 64-Bit for these tests. The browsers I have installed are Firefox Quantum 62.0 and Chromium 68.0.3440.106. As others have said, in Firefox I do not see the scrollbar, however it is visible in Chromium.
Upon comparing the differences between the two, the <p> tags in the topic text on my system are rendered using DejaVu Sans in Firefox, and Noto Sans in Chromium. Upon changing the font in Chromium to DejaVu Sans via the web inspector, the scrollbar disappears. Why the two browsers choose to render using different fonts, I don't know, but this seems to be the issue.
I will try to look into this if I get a chance later and make a merge request if I'm able to fix it. As a quick fix, disabling the below CSS rule also seems to alleviate the issue.
p:last-child{margin-bottom:0;}
This obviously has side-effects, so maybe a custom rule to eliminate it would be better...
I haven't had a chance to pursue any more fix attempts since this issue was initially discovered and all the ones I found were wonky CSS fixes as well, which had their own shortcoming. It's not a...
I haven't had a chance to pursue any more fix attempts since this issue was initially discovered and all the ones I found were wonky CSS fixes as well, which had their own shortcoming. It's not a super critical issue as it only happens when <sub> is used on the bottom line of a topic text, and only then in some browsers, but if you find a more permanent fix for it, that would be awesome. Thanks for looking in to it.
Hmm... subscript on the last line of topic text appears to make the scrollbar appear. That's a new one for the issues tracker. Thanks for discovering it. ;)
Weird, I'm on firefox right now and it shows the scrollbar for me.
61.0.2
Just checked Chrome (68.0.3440.106) and Opera (54.0.2952.71) which are both the latest versions, and it shows up in those for me as well. Could this maybe be a system font issue rather than a browser specific one?
edit: My Firefox is rendering the text using Segoe UI. I have no idea how to check which of the fonts from the font family is actually being used in Chrome or Opera though.
Yeah, it appears to be Segoe UI subscript that is causing the topic-full-text div to overflow. I switched the text font to Arial and the scrollbar disappeared. How very odd.
Can you do me a favor and check which font Firefox is actually using for this page on your system? If you inspect the top-text element, in one of the inspector panes there should be a Fonts tab that tells you the specific font being used from the font family. I am curious to know if yours is also using Segoe UI... and if it is but you're not getting the overflow then I have absolutely no idea what could be possibly causing this. :/
LOL... well, crap. I was hoping yours was different so at least the issue could be isolated. Now we're back to square one and I honestly have no idea what could possibly be causing the discrepancy across the same browser on different systems and yet similar behavior on others.
Yeah something with the subscript text is clearly breaking the
display: blockscaling and triggering the overflow in some cases but not others. I don't know what could possibly be the cause if it isn't the font, although it probably doesn't help that I am trying to diagnose this while lying down flat on my couch using my TV as a monitor while also having been up for 20+ hours though. :PSo I guess I will have to shelve it for now until I get some sleep so can think straight and actually sit at my desk. I will let you know if I figure it out after I wake up (if you haven't already by then). ;)
I think you might actually be on the right track with this...
I'm running Xubuntu 18.04.1 64-Bit for these tests. The browsers I have installed are
Firefox Quantum 62.0andChromium 68.0.3440.106. As others have said, in Firefox I do not see the scrollbar, however it is visible in Chromium.Upon comparing the differences between the two, the
<p>tags in the topic text on my system are rendered usingDejaVu Sansin Firefox, andNoto Sansin Chromium. Upon changing the font in Chromium toDejaVu Sansvia the web inspector, the scrollbar disappears. Why the two browsers choose to render using different fonts, I don't know, but this seems to be the issue.I will try to look into this if I get a chance later and make a merge request if I'm able to fix it. As a quick fix, disabling the below CSS rule also seems to alleviate the issue.
This obviously has side-effects, so maybe a custom rule to eliminate it would be better...
But ideally we can find and fix the font issue instead.
I haven't had a chance to pursue any more fix attempts since this issue was initially discovered and all the ones I found were wonky CSS fixes as well, which had their own shortcoming. It's not a super critical issue as it only happens when <sub> is used on the bottom line of a topic text, and only then in some browsers, but if you find a more permanent fix for it, that would be awesome. Thanks for looking in to it.