Fixup/compensate for chrome zoomed offset bug #154
Conversation
|
Could you go into more detail on this comment:
I'm really hesitant to add additional elements to the page if there is any other option. My concern is that we don't know if there will be CSS or JavaScript acting on it, and if it causes bugs on some peoples sites it would be very hard to diagnose. |
|
I understand your concern. To avoid inadvertently breaking code, perhaps we can make it an optional feature that could be enabled for those who encounter the problem and need a workaround. I had a usually working technique that did not require adding an additional element by using the body element as its reference point. The technique was insufficient when (if memory serves) there was a margin applied to either html or body. Adding an absolute element worked even in those cases. |
|
Could you submit a pull request for the alternate version? This problem is a bug that is likely affecting people right now, so it's higher priority than supporting unexpected body styling. If there is a safe fix that doesn't have backwards compatibility issues then I'd like to get it in for the next release. |
Reference getBoundingClientRect behavior in https://bugs.chromium.org/p/chromium/issues/detail?id=489206
Rather than using an element absolutely positioned at 0,0, compute compensation value based on offset of body. This should be tested more rigorously but on the upside it does avoid further manipulating the DOM.
Rather than rely on the change in body position to compute the mobile zoom compensation introduce a hidden, absolutely position element whose offset can be measured. The body element can be offset due to vertical margin collapse even when the element itself is positioned at the origin. When this happens the body offset measurements become unreliable.
jasco
force-pushed
the
fixup/compensate-for-chrome-zoomed-offset-bug
branch
from
5cad830 to
f89c15c
Compare
Issue #153