Some more details about this. Regression from the patch https://hg.mozilla.org/mozilla-central/rev/84708a4f040d Especially here, it's caused we are updating the left position of the tooltip at the very end of the calculation. The HTMLTooltip calculates its position so that it never crosses the edge of the screen, because trying to draw a XUL panel outside of the screen can lead to weird behaviors (as this bug attests). So if we want to "shift" the position of the tooltip, we need to do it _before_ we check for constraints: - before here for horizontal constraints: https://searchfox.org/mozilla-central/rev/35873cfc312a6285f54aa5e4ec2d4ab911157522/devtools/client/shared/widgets/tooltip/HTMLTooltip.js#250-255 - before here for vertical constraints: https://searchfox.org/mozilla-central/rev/35873cfc312a6285f54aa5e4ec2d4ab911157522/devtools/client/shared/widgets/tooltip/HTMLTooltip.js#146 Adding pixels after those steps can lead the panel to be displayed off screen, as it does here. I think that if the calculations are "off", there is probably a flaw in the calculation. For instance I think the tooltip is displayed too "high" because the arrow is created by rotating a non-square element, so the tip of the arrow is not on the edge of its container, there's a gap. Using highlighters is a good way to investigate such issues (but it's still a pain...). If we add negative margins to acknowledge that in .tooltip-top .tooltip-bottom: ```diff .tooltip-top .tooltip-arrow { margin-top: -1px; + margin-bottom: -2px; } .tooltip-bottom .tooltip-arrow { + margin-top: -2px; margin-bottom: -1px; } ``` then the calculation will be correct because the size of the arrow element will match the "visual" size of the element. For the 1px horizontal offset, I didn't manage to find where the discrepancy was coming from though. Maybe a border not taken into consideration? I think we should first provide a simple fix here to address the regression and uplift this to 71. Maybe remove the code that touches the left position for now until we have a better solution? Mike since you wrote the original patch, do you have a preference/suggestion?
Bug 1590408 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Some more details about this. Regression from the patch https://hg.mozilla.org/mozilla-central/rev/84708a4f040d Especially here, it's because we are updating the left position of the tooltip at the very end of the calculation. The HTMLTooltip calculates its position so that it never crosses the edge of the screen, because trying to draw a XUL panel outside of the screen can lead to weird behaviors (as this bug attests). So if we want to "shift" the position of the tooltip, we need to do it _before_ we check for constraints: - before here for horizontal constraints: https://searchfox.org/mozilla-central/rev/35873cfc312a6285f54aa5e4ec2d4ab911157522/devtools/client/shared/widgets/tooltip/HTMLTooltip.js#250-255 - before here for vertical constraints: https://searchfox.org/mozilla-central/rev/35873cfc312a6285f54aa5e4ec2d4ab911157522/devtools/client/shared/widgets/tooltip/HTMLTooltip.js#146 Adding pixels after those steps can lead the panel to be displayed off screen, as it does here. I think that if the calculations are "off", there is probably a flaw in the calculation. For instance I think the tooltip is displayed too "high" because the arrow is created by rotating a non-square element, so the tip of the arrow is not on the edge of its container, there's a gap. Using highlighters is a good way to investigate such issues (but it's still a pain...). If we add negative margins to acknowledge that in .tooltip-top .tooltip-bottom: ```diff .tooltip-top .tooltip-arrow { margin-top: -1px; + margin-bottom: -2px; } .tooltip-bottom .tooltip-arrow { + margin-top: -2px; margin-bottom: -1px; } ``` then the calculation will be correct because the size of the arrow element will match the "visual" size of the element. For the 1px horizontal offset, I didn't manage to find where the discrepancy was coming from though. Maybe a border not taken into consideration? I think we should first provide a simple fix here to address the regression and uplift this to 71. Maybe remove the code that touches the left position for now until we have a better solution? Mike since you wrote the original patch, do you have a preference/suggestion?