Closed Bug 389445 Opened 14 years ago Closed 8 years ago

The view doesn't scroll with the mouse if I drag start/end time to a hidden hour display


(Calendar :: Calendar Frontend, defect)

Not set


(Not tracked)



(Reporter: spam, Assigned: Fallen)


(Whiteboard: [needed beta][no l10n impact])


(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv: Gecko/20070713 Firefox/
Build Identifier: lightning 2007072403 on thunderbird (20070716)

When I edit the end to a hidden hour display, the view (week or day) doesn't scroll

When my cursor leave the window, I actually gain the ability to release the mouse button et use the scroll bar... the modification of the event is only set when I click again in the view.

Reproducible: Always

Steps to Reproduce:
1. Create an event on the day/week view.
2. Edit the event by dragging the start and/or end time of the event and try to go to the hiddent hour display...
Actual Results:  
the view doesn't scroll

Expected Results:  
the view should scroll
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070804 Calendar/0.7pre.
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Attached patch Fix - v1 (obsolete) β€” β€” Splinter Review
Assignee: nobody → philipp
Attachment #568404 - Flags: review?(bv1578)
Flags: blocking-calendar1.0+
Whiteboard: [needed beta][no l10n impact]
Philipp, there isn't any code in the patch.
Attached patch Fix - v1 (obsolete) β€” β€” Splinter Review
Oh man I almost thought I lost a patch but it was just hidden in the next patch I was creating! :-)
Attachment #568404 - Attachment is obsolete: true
Attachment #568466 - Flags: review?(bv1578)
Attachment #568404 - Flags: review?(bv1578)
Comment on attachment 568466 [details] [diff] [review]
Fix - v1

The patch works and we can give it a r+ because it adds a useful feature for the release.

However, IMHO, the functioning results a bit unusual i.e. it's strange it needs the mouse to be moved in order to get the view scrolled.
It results also a bit difficult to manage the scroll when the view is much zoomed (there are few hours shown in the view) because the zone sensible to the automatic scroll is wide and the scroll speed increase rapidly even when the mouse is far from the top/bottom view.

I would prefer a fixed zone (e.g. 30-40 pixels) near the top/bottom of the view and a timed scroll when the mouse goes into that zone, maybe  with a time interval reduced (faster scroll) when the mouse is closest to the borders (e.g. 15-20 pixels), but this is just an idea.

I understand it's too late to do changes, maybe could we think to a possible correction after the release?
Attachment #568466 - Flags: review?(bv1578) → review+
Given this patch didn't make the release, I agree we should make it work like you proposed. I was having the same issue but the problem was getting the right events. This solution is easy since it just waits for mousemove events. If I do it differently, then I'd need to set an internval timer that scrolls the event. I tried this but had trouble finding a timeout value that made it seem smooth but not too fast.

I guess I'll try this again.
Version: unspecified → Trunk
Attached patch Fix - v2 (obsolete) β€” β€” Splinter Review
This patch does it a bit better. Give it a whirl and let me know what you think.
Attachment #568466 - Attachment is obsolete: true
Attachment #754574 - Flags: review?(bv1578)
Comment on attachment 754574 [details] [diff] [review]
Fix - v2

Review of attachment 754574 [details] [diff] [review]:

The patch works fine, the scroll is smooth and the speed easily controllable by moving the mouse pointer closer to the border of the window.

The only thing I would change is the area where the scroll has to start, because at the moment it is equal to the room taken by an hour, hence it depends on the numbers of hours displayed in the view.
With a much zoomed view this area is much larger, e.g. when you display only three hours in the view, you have 2/3 of the view where the "magic" scroll takes place and, with only two hours, you have no place without scrolling and this is a problem that must be avoided. 
Moreover a different zone for the same kind of action could confuse the user.
I would propose something like this:

    const SCROLLZONE = 60; // Top/bottom part of the view (pixels) where the
                           // scroll automatically starts while dragging.
    let scrollSpeed = 0;
    let pxPerHr = * 60;
    if (diffStart < SCROLLZONE) {
        scrollSpeed = Math.floor((diffStart - SCROLLZONE) * pxPerHr/SCROLLZONE);
    } else if (diffEnd < SCROLLZONE) {
        scrollSpeed = Math.floor((SCROLLZONE - diffEnd) * pxPerHr/SCROLLZONE);

I also attach your patch with a modified way to scroll in case you want to try it. It scrolls with a variable _timeout_ (depending on the distance of the pointer from the top/bottom of the view) but with a fixed part of an hour as movement at every scroll.
Attachment #754574 - Flags: review?(bv1578) → review+
Attachment #754574 - Attachment is obsolete: true
Comment on attachment 8334590 [details] [diff] [review]
Fix - v2 with a scroll with variable timeout

I like your version, lets take it :) I will adapt my comment a little because its no longer accurate and then push.
Attachment #8334590 - Flags: review+
Pushed to comm-central changeset eb971b974099
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.0
You need to log in before you can comment on or make changes to this bug.