Repository navigation
Toplevel scrollbar appears, when mathlive elements exceed height window height in a fixed height container with scrollbars #971
Description
Description
Toplevel scrollbar appears, when mathlive elements exceed height window height in a fixed height container with scrollbars.
Screenrecording:
- https://www.loom.com/share/6f4a14da685040148012fa1a0a0d9146 (in Brave, bug happening)
- https://www.loom.com/share/0cd9d16e0b78433198fac26308c940b9 (in Firefox, handled correctly)
Steps to Reproduce
Actual Behavior
A window scrollbar appears, as if trying to accommodate for the mathlive elements, that are contained in a fixed-height HTML element with overflow-y configuration.
Expected Behavior
The window scrollbar should not be influenced by mathlive elements in a fixed-height HTML container
Environment
MathLive version
0.68.1
Operating System
macOS 10.15.7
Browser
- bug happens in Chrome, Safari, Brave. Firefox seems to handle it correctly though.
Metadata
Metadata
Assignees
Labels
No labels
Activity
mindreframer commentedon Jun 2, 2021
Also I want to apologize for reporting another bug!
This one seems to be somewhat tricky... I'm not sure how to explain this, took me some time to narrow down the cause of this issue. I was blaming it initially on CSS, until I have noticed that this does not happen if I am not rendering Mathlive elements.
I was happy, that it is reproducible. I hope this is not a major re-architecture issue (fingers crossed).
arnog commentedon Jun 2, 2021
The report is very clear. Thanks for taking the time isolating and documenting the problem. It appears that the height of a containers that contains mathfield influences the height of its parent. That seems incorrect, but I'm a bit concerned that this appears to be browser specific: this may indicate an issue that may need to be fixed in the browser engine (both Chrome, Safari and Brave share a lot of code). I'll have a look at it, though and see if I can get a handle on this and devise a workaround.
mindreframer commentedon Jun 2, 2021
@arnog Thanks for looking into it!
arnog commentedon Jun 3, 2021
OK, I have a fix for this but I don't like it very much.:
I'm inclined to think that Webkit/Blink is misbehaving, but I'm not 100% sure.
Anyway, you can use the workaround above for now, and I'll check-in a more permanent fix by setting the default position of the
MathfieldElementtoabsoluteas well, but this still doesn't feel quite right...mindreframer commentedon Jun 3, 2021
@arnog this does not work for me, I have a mix of
math-fieldand plain span text elements, rendered inline. I'm usingdisplay: inline-block;for the wrapping element ofmath-field. Withmath-field { position: absolute; }everything is just more distorted.I guess this is one of those
killerbugs, that is impossible to fix in the user-land. 😞 The app is still useable, it just looks weird, but I guess that can be one of thosefact-of-lifeissues.Thanks and maybe we have another working idea later.
arnog commentedon Jun 3, 2021
Sorry, I meant
relativemindreframer commentedon Jun 3, 2021
@arnog Yes, this works! :) Awesome, thank you very much! Not sure if this should be default, but good to know there is a way to handle it. 🙇
mindreframer commentedon Jun 3, 2021
From my perspective I consider this issue resolved.
It looks like there are 2 options: documenting it or making relative position default. Documenting it seems like a less "risky" approach, but maybe we try it as new default and wait for the bug reports pouring in? If there are no new bug reports - this change can be considered OK.
Life of an open-source software maintainer is hard...
arnog commentedon Jun 3, 2021
:)
Yes, I'm leaning towards changing the default to
position: relative. Like you said, it's a potentially a bit risky, but we'll see if it introduces any undesirable side effects if the bug reports start pouring in. In general, I like to avoid relying on documentation to work around problem as in my experience you cannot rely on people reading documentation.mindreframer commentedon Jun 3, 2021
Sounds like a reasonable decision. Thanks again for the quick resolution of this issue!