Powertip offset when browser scrollbar appears after load

[Toutouwai]

There seems to be a bug where powertips are offset by the width of the browser scrollbar if Powertip is initialised when no scrollbar is visible but the scrollbar is visible when the tooltips are shown (e.g. due to some content being added or revealed after DOM ready that necessitates the scrollbar).

In the screenshots below Powertip is initialised on DOM ready before the scrollbar is visible. This is Chrome v70.0.3538.102 in Windows.

Incorrect position:

Correct position (by forcing browser scrollbar to be visible on DOM ready via overflow:scroll on body)

I'm working around this by initialising Powertip after the content (and scrollbar) is visible but it would be good if Powertip handled this.

[stevenbenner]

It may actually be a non-trivial project to support the document or viewport changing size.

Root cause

What is happening here is that you are using the ne-alt placement, which uses the CSS right property to place the tooltip in the document. When the document expands and forces the browser to display the scroll bar it will resize the viewport to accommodate the width scroll bar in the browser window. The effect will be that the viewport will become narrower, so an item that was originally, say, 100 pixels from the right edge of the viewport will now only be 95 pixels away from the right edge of the viewport.

Since PowerTip loads the window dimensions into a cache variable on initialization, the math used to calculate where to place a tooltip will use values that are incorrect after the viewport changed size for the addition of the scroll bar.

PowerTip does track window resizing via the resize event, but this only happens when a user resizes the browser window. It doesn’t catch when document content changes and causes the viewport dimensions to change.

Possible fixes that can be implemented in the plugin

1. I could just stop caching the viewport dimensions. This would mean that every time PowerTip tried to calculate a tooltip position it would check the window dimensions with a direct DOM calls. However, I am hesitant to do this because these values are used quite often, potentially dozens of times for each tooltip open request in the case of smart placement. I’m not sure if there is a performance impact to adding numerous DOM invocations to fetch these values.
2. I could refresh the cache on each tooltip open request. This would be the most reasonable middle ground which negates many of the downsides of the other options and probably only has a very minor performance impact.
3. Alternatively, it may be possible for PowerTip to update the viewport dimensions automatically. It would have to watch the DOM for any change that could cause the document to change size or shape. The only way I can think to do this directly would be with a MutationObserver hooked to the root element. But it doesn’t cover all cases (e.g. dynamic CSS effects, like size changes/transitions on :hover). It is also a feature absent from Internet Explorer prior to version 11 (this project is currently IE8 compatible).
4. Or I could just expose the function the refreshes to viewport dimensions cache in the API and ask developers to manually call it when they do something that may reshape the document. But I don't see that being something that would get much use.

Possible workaround for the current version

Other than what you are doing now, you should also be able to force PowerTip to refresh the cached window dimensions by triggering the window resize event. You should be able to call $('window').trigger('resize'); and PowerTip will refresh it’s cashed viewport dimension values. If you do this any time something happens that could cause the document to change shape, then PowerTip tooltips should use the correct values.

Where to go with this request

I'll consider the possible fixes. If you, or anyone reading this, can think of better alternative ways to fix this then please let me know. If I can verify that fetching viewport dimensions from the DOM doesn't add significant performance impact then it would be worth making that change.

[Toutouwai]

Thanks for the detailed reply! Interesting that appearance of the scrollbar does not trigger a window resize event - I wasn't aware of that.

I found a hacky workaround to detect viewport resize but I doubt you'd want to go there with Powertip.

For my case I'm fine with your suggestion of manually triggering a resize event, but for other users (or for cases where content is revealed via CSS only) maybe fix 2 is the way to go if the performance impact is not great.