trees no longer scroll when dragging over first or last visible item

VERIFIED FIXED in mozilla1.9beta4

Status

()

P2
normal
VERIFIED FIXED
13 years ago
10 years ago

People

(Reporter: regis.caspar+bz, Assigned: mats)

Tracking

(Blocks: 1 bug, {regression})

Trunk
mozilla1.9beta4
x86
Windows XP
regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dbaron-1.9:RpCo], URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
In the search engine manager, drag and drop is supported since bug 335086 landing. However, dragging a search engine (S.E.) from bottom to top is a bit boring if you have a decent number of S.E. 

Actual results: you have to drop the S.E. once every 10 S.E. then scroll by hand then drag again and so on.

Expected: when dragging over the first or last visible item of the tree scroll should "automagically" occurs. (like explorer does when moving something with drag and drop)
(Reporter)

Comment 1

13 years ago
Created attachment 228284 [details] [diff] [review]
patch (proposal) v1

This patch do the job. However I'm not sure this is the most efficient way to implement that.
Attachment #228284 - Flags: review?(gavin.sharp)
Comment on attachment 228284 [details] [diff] [review]
patch (proposal) v1

This is actually a trunk regression, so this patch shouldn't be necessary.
Attachment #228284 - Attachment is obsolete: true
Attachment #228284 - Flags: review?(gavin.sharp)
Severity: enhancement → normal
Keywords: regression
Version: unspecified → Trunk
(Reporter)

Comment 3

13 years ago
Can someone help in finding a range? Peter, Ria?
Fails on 20060705 (that's all I know sorry). 
(Reporter)

Comment 4

13 years ago
Fails on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060629 Firefox/3.0a1 ID:2006062907 (homemade debug build) too
I think it is not a regression. Once the dragging was implemented, it did not scroll.
The first build with the new dragging feature was 1.9a1_2006060912 and it did not scroll.
(Reporter)

Comment 7

13 years ago
(In reply to comment #6)
> The first build with the new dragging feature was 1.9a1_2006060912 and it did
> not scroll.
Thanks for the help Ria :) 

Created attachment 228370 [details]
test extension

This extension can be used to test drag and drop in pre-engine manager builds (or builds which don't have drag and drop). To use it, just install the extension and load chrome://test/content/engineManager.xul.
(In reply to comment #8)
>
I should see any difference in behaviour between branch and trunk but I don't. When I drag 1 below 11 they change position but I don't see it scroll. :?
(Reporter)

Comment 10

13 years ago
(In reply to comment #9)
> I should see any difference in behaviour between branch and trunk but I don't.
> When I drag 1 below 11 they change position but I don't see it scroll. :?
Gavin, I don't see any scroll in your extension too. If you reduce FF window height so much that you only see 8 in chrome://test/content/engineManager.xul then click drag 1 over 8 you can't go further down without dropping 1, scrolling by hand and then drag and drop again..

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060706 Minefield/3.0a1 ID:2006070604 [cairo]

(In reply to comment #10)
>
OK, in that case branch scrolls. :)
When there is no reason to scroll, it can't scroll, that's true.
In trunk it is a regression between 1.9a1_2006051010 and 1.9a1_2006051022.
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-05-10+09%3A00&maxdate=2006-05-10+23%3A00
Bug 326273?
(In reply to comment #11)
> OK, in that case branch scrolls. :)
> When there is no reason to scroll, it can't scroll, that's true.
> In trunk it is a regression between 1.9a1_2006051010 and 1.9a1_2006051022.
> http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-05-10+09%3A00&maxdate=2006-05-10+23%3A00
> Bug 326273?

Great, thanks for finding the regression range Ria! Bug 326273 certainly looks most likely, I'll try a couple of builds from just before the checkin, and just after.
Assignee: nobody → search
Component: Search → Search
Product: Firefox → Core
QA Contact: search
Assignee: search → Jan.Varga
Component: Search → XP Toolkit/Widgets: Trees
QA Contact: xptoolkit.trees
I've confirmed that this is a regression from bug 326273.
Blocks: 326273
Summary: Search engine drag should scroll the tree (in the Search Engine Manager window) when draging over first or last visible item → trees no longer scroll when dragging over first or last visible item
*** Bug 349344 has been marked as a duplicate of this bug. ***

Comment 15

12 years ago
See related bug 338401.
Flags: blocking1.9?

Comment 16

12 years ago
October 2006 seems to be the last update on this or any of its related bugs as far as I can see.  I keep downloading nightly builds hoping the problem might be solved, but as of 12/31/06 there is no change.

Perhaps this is a more significant flaw to me than to others, but I doubt mainstream users are going to use a browser/e-mail client without the scroll feature?  It is a real nuisance to have to drag an address, bookmark, folder, etc. one screen at a time, drop it, roll the cursor up a screen and then move the item again.  I keep to returning to an older version that does scroll even if it means giving up some of nice newer features in more recent builds and I suspect others will do the same.  I have tried to get many others to use SeaMonkey, but as soon as they see it won't scroll they reject it (or use a much older build).

The loss of the scroll feature appears to have happened right after the 8/2/06 build since that is the last one that works for me.  If I read comment #11 correctly it suggests the problem started in May.  I originally couldn't get any builds since April to work, but now I find that the 8/2/06 build I had downloaded back then does scroll, but nothing subsequent.  What changed after 8/2 that may have caused this?  I wish this would become a high priority fix since I think that is what it deserves.

I have tested the builds on four windows XP SP2 machines and find the same results in all cases.   I hope I am not the only one that thinks this is a big issue.
Blocks: 339474
Flags: blocking1.9? → blocking1.9+

Updated

12 years ago
Duplicate of this bug: 382384
Duplicate of this bug: 385621

Updated

11 years ago
Blocks: 378426
Whiteboard: [dbaron-1.9:RpCo]

Updated

11 years ago
Assignee: Jan.Varga → nobody
Blocks: 381699
Duplicate of this bug: 402697
Another bug about not processing events during a drag.
Assignee: nobody → mats.palmgren
Depends on: 389931

Comment 21

11 years ago
Bug 406941 seems to be related to this bug.

Comment 22

11 years ago
(In reply to comment #16) 
> Perhaps this is a more significant flaw to me than to others, but I doubt
> mainstream users are going to use a browser/e-mail client without the scroll
> feature?  It is a real nuisance to have to drag an address, bookmark, folder,
> etc. one screen at a time, drop it, roll the cursor up a screen and then move
> the item again.  

Sometimes you can't even do one screen at a time, if the object being dragged can only be dropped in certain locations.

In NewsFox RSS reader, you can drag articles from an article tree and drop them only on storage feeds in a different feed tree.  If the storage feeds are not visible in the feed tree, you'd need to start over by first making the storage feed visible.

In some ways this is easier than the screen-by-screen problem, but it is much less intuitive(the user is more likely to just give up and think there is no solution).
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022702 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

R.Fixed, by bug 389931:
tested in Browser bookmark manager and MailNews folder pane.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4
No longer blocks: 339474
Duplicate of this bug: 339474
No longer blocks: 378426
Duplicate of this bug: 378426
(Reporter)

Comment 26

11 years ago
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022714 Minefield/3.0b4pre ID:2008022714

-> Verified ?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022823 Minefield/3.0b4pre

Verified fixed too (bookmarks sidebar and library window).
Status: RESOLVED → VERIFIED

Updated

10 years ago
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: xptoolkit.trees → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.