_HasDropDown shows in the wrong location on zoomed mobile device

[pshannon]

When using a DropDownButton? or another widget that extends _HasDropDown it is possible for the drop down to not be correctly centered around the button when the browser is pinch/zoomed on a mobile device. This bug can be seen on the theme tester in Google Chrome's device mode.

Repro steps are:

1. Open Device Mode
2. Change the device to the iPhone 6 Plus
3. Open the Theme Tester page
4. After the page loads move the right border in to create scroll bars
5. Scroll right
6. Click on the Drop Down

Expected: The drop down should be positioned directly below the button Actual: The drop down is scrolled to the right and continues to follow the scroll center as the page is scrolled

I have had some success in setting domGeometry.position(around, true) to false. This seems to fix the issue, but I'm afraid that will adversely affect other popups. I believe the final fill will require passing a flag to popup to instruct it to not include scroll offsets in some way.

[pshannon]

example of bug

[pshannon]

I have tracked down the exact problem to a bug in Chrome that is under active development (​https://code.google.com/p/chromium/issues/detail?id=489206 and ​https://code.google.com/p/chromium/issues/detail?id=543474).

The problem is that Element.getBoundingClientRect() returns a rectangle that is relative to the layout viewport and Element.scrollLeft returns a value that is relative to the visual viewport. These two frames of reference are usually the same except when pinch-to-zoom is used to zoom in on a page. The difference makes it practically impossible for dom-geometry.position() to correctly offset an absolutely positioned dialog in a zoomed viewport.

This issue should be resolved once the fix makes it into Chrome on Android. There is a suggested workaround available in the Chrome ticket if someone would like to attempt a fix, but it involves injecting an element into the body of the document.

[bill]

Ah, the joys of layout viewports. Thanks for the links.

I see the workaround at ​https://code.google.com/p/chromium/issues/detail?id=489206#c19. Not too bad, but not ideal either. I guess using that workaround would make everything work according to the layout viewport, which means that a dropdown might extend past the visual viewport, and dialogs might be [partially] out of the visual viewport. Not sure if that's what we want or not, but anyway it would be an improvement because at least this bug would be fixed.

I think another approach would be to change dijit/place to call geom.position(node, false) rather than geom.position(node, true), and then nobody would access Element.scrollLeft and Element.scrollTop at all.

[bill]

Duplicate of #18763.
On second thought, even if I changed dijit/place to work internally in (layout) viewport coordinates, for the final step it needs to set node.style.left and node.style.top, so it still needs to know the (layout) viewport's scroll.

Seems like the only way to fix this is to do the suggested workaround. I filed #18763 since this is really a core issue.