Opened 5 years ago
Closed 5 years ago
#18753 closed defect (duplicate)
_HasDropDown shows in the wrong location on zoomed mobile device
Reported by: | pshannon | Owned by: | bill |
---|---|---|---|
Priority: | undecided | Milestone: | tbd |
Component: | Dijit | Version: | 1.10.4 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
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:
- Open Device Mode
- Change the device to the iPhone 6 Plus
- Open the Theme Tester page
- After the page loads move the right border in to create scroll bars
- Scroll right
- 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.
Attachments (1)
Change History (4)
Changed 5 years ago by
Attachment: | dijit_HasDropDown.png added |
---|
comment:1 Changed 5 years ago by
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.
comment:2 Changed 5 years ago by
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.
comment:3 Changed 5 years ago by
Resolution: | → duplicate |
---|---|
Status: | new → closed |
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.
example of bug