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)
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.
Comment on attachment 228284 [details] [diff] [review] patch (proposal) v1 This is actually a trunk regression, so this patch shouldn't be necessary.
Severity: enhancement → normal
Version: unspecified → Trunk
Can someone help in finding a range? Peter, Ria? Fails on 20060705 (that's all I know sorry).
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.
(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. :?
(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
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. ***
See related bug 338401.
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.
Another bug about not processing events during a drag.
Assignee: nobody → mats.palmgren
Depends on: 389931
Bug 406941 seems to be related to this bug.
(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
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
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.