#9024 closed defect (fixed)
dragging to edge of viewport causes window to start scrolling
Reported by: | Ilginy1 | Owned by: | bill |
---|---|---|---|
Priority: | high | Milestone: | 1.8 |
Component: | DnD | Version: | 1.3.0rc2 |
Keywords: | Cc: | Eugene Lazutkin | |
Blocked By: | Blocking: |
Description (last modified by )
When a dijit.Dialog or dojox.Floating Pane is dragged out of the main window (viewport) the current view starts scrolling in the opposite of the moving direction.
For example:
Move dialog to the right and cross right window edge => window content starts to scroll to the left.
Move dialog down and cross bottom window edge => window content starts to scroll to up.
This problem is also stated in dojo forum:
This can be easily fixed by disabling dojo.dnd.autoScroll call in ../dojo/dnd/Mover.js
I can provide our simple patch in Mover.js if you are interested
Attachments (3)
Change History (18)
comment:1 Changed 12 years ago by
Component: | General → Dijit |
---|---|
Owner: | anonymous deleted |
Summary: | Dialog Windows can be moved out from viewport → Dialog: windows can be moved out from viewport |
Changed 12 years ago by
Attachment: | Mover.patch added |
---|
comment:2 Changed 12 years ago by
No actually we only made the patch to Mover.js
It is simply based on disabling dojo.dnd.autoScroll call
Yes I do have a CLA and attached you can find the patch.
comment:3 Changed 12 years ago by
Cc: | Eugene Lazutkin added |
---|---|
Milestone: | tbd → 1.4 |
OK thanks for the patch... that dojo.dnd.autoscroll() code is there for a reason though (like when you are trying to reorder nodes in a tree and you need to scroll down in the viewport to get to the drop point), so I don't want to disable it altogether.
Maybe can find some way to disable it just for Dialog though. Eugene, any ideas?
comment:4 Changed 12 years ago by
Milestone: | 1.4 → 1.5 |
---|---|
Summary: | Dialog: windows can be moved out from viewport → Dialog: dragging to edge of viewport causes window to start scrolling |
comment:5 follow-up: 7 Changed 11 years ago by
Description: | modified (diff) |
---|---|
Milestone: | 1.5 → 1.6 |
I think there are three separate issues conflated here:
- request to disable auto-scroll when (while dragging the dialog) mouse is near top or bottom edge of the viewport
- from the forum post, request [for option] to restrict dialog dragging within bounds of viewport, using constrainedMovable
- some other issue I see when moving the mouse to the right; even when autoscroll is disabled, having the dialog at the right makes the document wider, showing a horizontal scrollbar. Not such a big issue.
I have a patch for #1
which I'll attach, although I'm not sure I should check it in, maybe the auto-scroll is actually useful when there's a Dialog? In any case I don't see how the current behavior is a problem, maybe you can explain?
For #2
, I don't see the urgency either, actually being able to move the Dialog partially off-screen is often important so the user can see the content behind the dialog.
As for #3
that doesn't seem important.
So, I'll leave this open to consider for 1.6, but will likely close as wontfix.
Changed 11 years ago by
Attachment: | dialogNoAutoScroll.patch added |
---|
disables auto-scroll just while Dialog is being dragged
comment:6 Changed 10 years ago by
Milestone: | 1.6 → future |
---|
comment:7 Changed 10 years ago by
Replying to bill:
I think there are three separate issues conflated here:
- request to disable auto-scroll when (while dragging the dialog) mouse is near top or bottom edge of the viewport
- from the forum post, request [for option] to restrict dialog dragging within bounds of viewport, using constrainedMovable
- some other issue I see when moving the mouse to the right; even when autoscroll is disabled, having the dialog at the right makes the document wider, showing a horizontal scrollbar. Not such a big issue.
I have a patch for
#1
which I'll attach, although I'm not sure I should check it in, maybe the auto-scroll is actually useful when there's a Dialog? In any case I don't see how the current behavior is a problem, maybe you can explain?For
#2
, I don't see the urgency either, actually being able to move the Dialog partially off-screen is often important so the user can see the content behind the dialog.
If you drag the dialog out of the window by the top, then you loose the dialog handle bar, so you cannot, then, rely on it to get back your dialog into the viewport. I attach a screen capture.
comment:8 Changed 10 years ago by
The dialog must have the same behaviour than the Jquery's dialog http://jqueryui.com/demos/dialog/ or the YUI's dialog : http://developer.yahoo.com/yui/examples/container/panel_clean.html
comment:11 Changed 9 years ago by
Component: | Dijit → DnD |
---|---|
Milestone: | future → 1.8 |
Owner: | set to bill |
Status: | new → assigned |
Summary: | Dialog: dragging to edge of viewport causes window to start scrolling → dragging to edge of viewport causes window to start scrolling |
Changing category since this is an issue with DnD in general, reproducible via dojo/tests/dnd/test_dnd.html and dojo/tests/dnd/test_moveable.html.
I have a fix.
comment:13 Changed 8 years ago by
Feels like this isn't fixed completely for dojox.layout.FloatingPane? in 1.8.3 -- if you drag object to edge of the screen, release it, and then start dragging it again, it increases size of the window, and starts scrolling outside it. This can be seen in here, for instance: http://download.dojotoolkit.org/release-1.8.3/dojo-release-1.8.3/dojox/layout/tests/test_FloatingPane.html
comment:14 Changed 8 years ago by
I guess it depends what you mean by "this". The problem you are describing sounds like FloatingPane needs the fix done to Dialog in [25306]. You can file another ticket for that if you like, if there isn't one already. Fair warning though: no one is maintaining FloatingPane.
comment:15 Changed 8 years ago by
The workaround to this issue (for dojo versions <= 1.7) is to disable auto-scroll altogether:
dojo.dnd.autoScroll = function(){ };
Or if you need auto-scroll, then just temporarily disable auto-scroll when the dialog is shown, and then restore that method afterwards.
I looked at backporting this change to 1.7 but it's a little large, so I want to avoid doing that if possible.
Hmm, it sounds like the change should be to dialog, rather than mover? We want this functionality in general.
If you've signed a CLA then please provide a patch of what you are thinking of.