Closed Bug 235244 Opened 21 years ago Closed 16 years ago

Shift should not be required to drag around folders on personal toolbar

Categories

(Firefox :: Bookmarks & History, enhancement)

Product:
Firefox
Component:
Bookmarks & History
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.6a1

People

(Reporter: bugs, Assigned: mak)

References

Details

(4 keywords, Whiteboard: [polish-hard][polish-interactive][polish-p2])

Attachments

(1 file, 2 obsolete files)

patch v1.0
5.82 KB, patch
asaf
: review+
beltzner
: approval1.9.1+
Details | Diff | Splinter Review 
If I try to drag a folder on the personal toolbar it opens, and I am unable to
move it. 

I understand the value of having the menu open on mousedown (for
click-drag-release bookmark opening) but I think there's room for some logic
that if the mouse begins to move over a geographic area that would imply the
folder was to be moved (i.e. outside the range of usual click-drag-release
bookmark opening) then the menu would be rolled up and the folder relocated on
the toolbar.
what I've been thinking for a long long time is to expose in the DND APIs the
angle of the initial (x,y) deltas that trigger the drag gesture.
The drag gesture should be aborted for angles between something like [-30°,30°]
around the downwards direction for buttons with menupopups and the rightwards or
leftwards direction for menuitems with menupopups.
Not being able to drag folders on personal bookmark is VERY annoying.
It requires "manage bookmark" to do that, but it would much more
confortable to restructure bookmark just my dragging items.
I would like to see this issue raise in priority.


you can hold SHIFT and drag folders in the personal toolbar folder.  Reworking
the drag and drop API as Pierre mentioned would require significant work and
isn't a priority at present.
And by significant work, I'm mostly thinking of the testing etc required to make
this feel "right"
I didn't know the SHIFT trick! It works.
Thank you, dismissing my vote for this bug.
Regards,

*** Bug 248588 has been marked as a duplicate of this bug. ***
In the bookmarks menu and bookmarks bar, bookmarks can be moved with the left
mouse button.
But bookmark-folders only can be moved if the user holds down SHIFT while
holding down the left mouse button.

This is inconsequent, not intuitive and bothering!


In IE boomark-folders can be moved in the same way as bookmarks, just with the
left mouse button. There is no need to press SHIFT.

They (IE) just close already open boomark-folders if the user begins to drag them...

I think you should also allow bookmark-folders (in the bookmarks menu and
bookmarks bar) to be moved without holding down SHIFT, like IE does.
Norbert: It's hard to avoid inconsistency here.  With Firefox's current
behavior, you can drag bookmarks but not folders.  With Internet Explorer's
behavior, you can access a main menu item with one click but items in menus on
the bookmarks toolbar require two clicks.  

That's why the drag-angle idea was proposed.  With the drag-angle idea, the only
thing you can't do that you can do with normal menus is look through all the
bookmarks toolbar menus with the mouse button held down.

Opera does the drag-angle thing for menus on the bookmarks toolbar.
See also bug 206987, same bug for Seamonkey.
(In reply to comment #8)
With Internet Explorer ... but items in menus on
> the bookmarks toolbar require two clicks.  

Do you mean IE's "Links"-button?
I think I cann open all bookmarks with a single click in IE.



I hope you have recognized that I also mean the bookmarks in Firefox'
"Bookmarks"-menu, not only the bookmarks bar. There folders also cannot be
moved, while this is possible in IE.
Severity: normal → enhancement
Summary: Cannot drag around folders on personal toolbar → Shift should not be required to drag around folders on personal toolbar
Why is this an enhancement and not a bug?  Click-drag is used to move things
around in general.  Shift-click-drag is not a standard I'm familiar with.
(In reply to comment #11)
> Why is this an enhancement and not a bug?  Click-drag is used to move things
> around in general.  Shift-click-drag is not a standard I'm familiar with.

I agree. I also think this is more a bug than an enhancement.
I disagree.  The prefered behavior is for Bookmark Toolbar folders to NOT be
draggable.  They are special and should function as dropdown menus, and they
would be too easy to move by accident if you could freely drag them around.

This is why the Shift-click-drag (and ALT-click-drag) option is available.  As
for BOTH the ALT OR Shift use working here, I think the devs need to choose one
or the other.
I still don't understand why this wasn't changed yet. Especially since "Live
Bookmarks" are treated like folders and are also affected by this
"SHIFT/ALT-click" nonsense.
This is inconsistent with almost every other application or desktop environment
(basically all non-Gecko-browsers, Windows, KDE etc.), this is not intuitive or
expected behaviour (why would live bookmars be treated differently from regular
bookmars).

This is not even documented! The only way I found out about it was to really
search deep in Bugzilla, noone even knew that it was possible to drag and drop
folders and live-bookmarks in the "Bookmarks Toolbar", not even very experienced
users at mozillazine.org.

I understand that at one time this must have been a design decision that seemed
plausible. But with the introduction of live bookmarks and due to the
inconsistency with everything most users are used to this needs to be changed.
And I hope it will be before the 1.5 release.
Please remove the drag- and drop-limitation for folders and live bookmarks, its
unneccesary and annoying.
I am in total agreement here, there is no doubt Firefox is out on it's own here,
this is un common, and not user friendly.  Virtually all products even ones for
more advanced users are consistent in these respects, yet Firefox a supposed
novice user friendly browser, with easy to use bookmarks and interface as said,
does not allow the user to move live bookmarks and folders in the dropdown.

It's simply ludcacrous.  Virtually everything else can be done in the drop down
meaning most people don't have to worry about going into manage bookmarks, until
when they've just created a new folder and it automatically goes to the bottom
of somewhere equally as un suitable, it cannot be moved right there and then. 
To not allow this is just madness.  

Normal bookmarks are not moved around accidentally, why would folders when
people are organising they're work, hobbie and sports etc. sites into
conveniently organised folders?  It's not a problem anywhere else, why would it
be here?  It is only a problem blocking this simple user friendly functionality.
 Also, many programs, and an example if windows all programs screen in start,
sets it so icons can be clicked for a split second and dragged, where as folders
require a slightly longer hold, to then move the folder elsewhere.  That
completely removes the chance of mistakes.

This is just not practical.  I heard the bookmarks area was being re build and
coded from scratch as its quite old, so this really needs attention, its far
behind other software, and is holding back Firefox's otherwise easy to use
interface.
(In reply to comment #8)
> Norbert: It's hard to avoid inconsistency here.  With Firefox's current
> behavior, you can drag bookmarks but not folders.
I think we all agree that this is an inconsistency.

> 
> That's why the drag-angle idea was proposed.  With the drag-angle idea, the only
> thing you can't do that you can do with normal menus is look through all the
> bookmarks toolbar menus with the mouse button held down.
> 
> Opera does the drag-angle thing for menus on the bookmarks toolbar.

I dont really understand why we need such an complicated drag-angle system.
If you look at the normal Windows XP UI that people are used to, we see exactly
the same things we talk about here in the "Start Menu". There is a setting to
completely disable drag'n'drop (might be a good idea to have such a setting for
people with Mouse "disabilities"), but once you allow drag'n'drop, you are
allowed to do this with items AND folders.
Everything else is similar to Fx:
Menu has single items, folders with items and subfolders etc.
One click on an item opens (starts) it, one click on an Folder opens it (faster
than hovering above it), double click on an Folder opens the Folder in an extra
Folder-View (this could be our Feedview, see also bug #303106), why not simply
stick to this Windows UI behavior People are used to (at least for Fx for Windows)?

(In reply to comment #13)
> I disagree.  The prefered behavior is for Bookmark Toolbar folders to NOT be
> draggable.  They are special and should function as dropdown menus, and they
> would be too easy to move by accident if you could freely drag them around.

Dont really see the difference between normal items (Bookmarks) on Bookmark
Toolbar folder that are allowed to drag'n'drop and open upon click, and Folders
that also open upon one click (but are not allowed to drag'n'drop).
I dont see why there should be any difference in chance to move them by
accident...  
> I dont see why there should be any difference in chance to move them by
> accident...  

See comment 0, paragraph 2.
Ah thanks, needed a while to get that ;) (dont use click-drag-release bookmark
opening)

Sorry, also didnt see until now that this bug is specifically about "personal
toolbar", my comments where about Bookmarks/Folder drag'n'drop in general (and
still valid there imho)...going to add it to (hopefully right) bug 249505 

I agree now with that paragraph 2, but unless we have that functionality, could
personal toolbar not be an "no drag'n'drop" exeption?
I understand that this is NOT what this Bug is about, so sorry again for some
Spam . 
(In reply to comment #13)
> I disagree.  The prefered behavior is for Bookmark Toolbar folders to NOT be
> draggable.  They are special and should function as dropdown menus, and they
> would be too easy to move by accident if you could freely drag them around.
> 
> This is why the Shift-click-drag (and ALT-click-drag) option is available.  As
> for BOTH the ALT OR Shift use working here, I think the devs need to choose one
> or the other.

While they should could choose Shift or Alt, just one or the other, instead I
have changed my mine on the overlying issue.  The top level folders should be
made drag and droppable on the Bookmark Toolbar Folder, at most add some sort of
hover timer to remove accidental drags, but I really don't think it would be
much of an issue, even if it DIDN'T have a hover timer.
Attached patch patch (obsolete) — — Splinter Review 
Well, this would fix it, but finding the fix was not the problem, I guess.
I believe you were saying this causes undesirable side-effects. But I'm afraid,
I don't really understand what the side-effects are, from the comments.
Maybe, someone who understands, care to elaborate?
Would this patch also fix Bug 249505?
Basically they are the same bugs, so yes.
*** Bug 249505 has been marked as a duplicate of this bug. ***
Dont know how your patch works, but I think the basic Problem is a "conflict"
with the "click-drag-release bookmark opening" functionality (see comment# 0)
This "feature" allows it to open an Folder in Bookmarks Toolbar by left-click,
keeping Mouse-Button pressed, go down to the wanted Bookmark and release the
Mouse-button to open it (it's a "shortcut": otherwise you need 2 clicks)
Naturally this does not work if shift is pressed (and now with your patch too?)
because you will move the whole folder then. There where also some concerns
about accidentally clicking and dragging Bookmark Toolbar folders.

But since none of these (potential) Problems concerns normal Bookmark Menu, at
least a similar Patch only for Bookmark Menu (while keeping shift status quo for
Toolbar) should be feasible before 1.5 ships.
I don't know the feasibility of this, but something along the lines of:  click
and hold for under 3 seconds, with this timer restarting any time there is mouse
movement, would allow one to produce the drag-down-and-release behavior, while
click and hold stationary for 3 or more seconds would allow drag and drop of
folder?  Visual notifiction of drag-ability after 3 stationary seconds would be
by the dropdown disapearing?
(In reply to comment #25)
> I don't know the feasibility of this, but something along the lines of:  click
> and hold for under 3 seconds, with this timer restarting any time there is mouse
> movement, would allow one to produce the drag-down-and-release behavior, while
> click and hold stationary for 3 or more seconds would allow drag and drop of
> folder?  Visual notifiction of drag-ability after 3 stationary seconds would be
> by the dropdown disapearing?

Personally, I'd say make it work like the start menu.  Make it pop up when you
press the mouse button down (as it currently does).  If you move it, however,
the dropdown stays in the same spot while the folder moves like a file does.
Martijn, as noted above, in normal menus, you can mousedown anywhere, including
the menu head, and navigate the menu with the mouse down; mouseup on an item
will launch that item. It's hardly an ergonomic way to browse large or
unfamiliar menus, but it's something you may end up getting in the habit of with
short and familiar menus where you know the position of the menuitem you want to
hit beforehand. Bookmark toolbar folders are likely to fall into that latter
category, so I don't think it's nice to make them draggable without some extra
inference about user intent.

A second concern I have is that I don't think I've ever met a draggable-items
menu that reliably works correctly. A solution candidate should at least be
tested against variants of the following problem:
  - mousedown on menu head
  - move mouse onto menu popup area before the popup materializes
  - see if moving the mouse will start dragging an item (it shouldn't.)

As for the bmtb folder behavior specifically, mmortal03's idea is interesting,
but it doesn't really fix the root subject of this bug, that the way to move
bookmark toolbar folders directly is undiscoverable. Comment 0 has it right, I
think. If the bookmark toolbar menu opening drag enters a point where, if it
were a bookmark toolbar item moving drag, it would move the item -> kill
menupopup and switch to item move dragging. That could be a reasonable way to
handle draggable menuitems, too.
Ok, I understand now the issue involved here. Thanks!
Not that it's always best to emulate IE, but most folks use IE anyway, so
leaning toward the familiar might help draw a few IE users over the fence...

It looks like IE6 makes you hover the mouse over a folder on the Favorites menu
until the submenu has displayed before you can drag it away. This delay is
customizable in Windows. If you try to drag the folder before that delay has
elapsed then IE just ignores the mousedown and mouseup events, it seems.

What if we just expanded on that a little, so that:
1) you can drag a folder after the submenu displays (which would require
building a delay into the bookmark toolbar, at least), and
2) if you have the mouse down before the submenu displays thured thien the menu
behaves like a standard top-level menu that will select whatever item is under
the cursor when the button is released.

This would be more like IE and the Start Menu than the shift-drag method... but
we still wouldn't behave identically to MS so we might confuse some folks anyway...

At the very least we have to figure out some way to make the shift-drag more
well known. I've been using FF for ages and I somehow just figured this out. But
maybe I'm just special :-)
I voted for this bug, and thought that comments will end sometimes, as this is
not forum place.

I would like to point to the fact that Asa has recently written on how Linux
should be changed, and it his opinion that Linux should not brake Windows users
habits if there is not good reason for that. Also, this bug was reported by Ben
Goodger, Firefox leading developer.

I would like to also point that I am more experienced than 99,9% of computer
users, and I have still never used that option one sort through menus.

So, one question for all those people that are against this bug: how can you be
so jealous and ask something for yourself on behalf on more than 90% of other
users? For the hell, someone will make extension that will restore current state
and you will be able to install it.

And please don't reply if it is not really incredibly necessary. This is
bugzilla, not forum.
Ivan - none of the discussion on this bug looks out of line to me, with the
exception of your own comment. I suggest removing yourself from this bug or
adjusting your bugzilla prefs if you don't want to get mail about discussion
here. Please do not attempt to put down discussion on this bug again. If you
have any concerns about bugzilla etiquette, feel free to email me.
Ok, can someone update as to how seriously this really is being looked at.  It
is not a basic Windows/IE/ or most other application type of behaviour, for that
reason alone it is very warranted to enable the same, to keep with Firefox being
easy to understand for all users of basic programs such as IE.

What is the serious extra harm in moving a folder/live bookmark over a standard
page bookmark anyway?  Litte to none.  It happens rarely, and can be moved right
back anyway.

In any case it is very easy to allow a delay to clicking on a folder to when it
becomes moveable, this happens in many programs, and avoids moving things
accidentally.

There is simply no reason not to allow this.  Unless your trying to move a
folder of live bookmark, you wont find be able to move it, as you would probably
have to holder click on it for 2 seconds or so.  Literally zero reason.

So...update please.  Also would like some communication as to when this might
happen, who's aware of it within Mozilla, and I would certainly hope the dev/s
rebuilding the Bookmarks code is aware of it also, at least.
I think it is getting now rather obvious that it's simply too late for adding
such new functionality for FF 1.5, let alone there is still no such enhanched
patch in view...

@Martijn Wargers: But it would be really great if you could try to modify your
patch to allow Folder and Live Bookmark Drag'n'drop without Shift, but in
Bookmarks Menu only (afaik nobody mentioned Problems with this).
So we would have a patch ready that might be checked in on trunk and later on
branch before FF 1.5 ships. Time is running short and we should at least try to
somewhat ameliorate this issue and then open a new Bug which adresses Bookmark
Toolbar and future added functionality.
Attached patch patch2 (obsolete) — — Splinter Review 
Like this?
This disallows dragging of folders that are a direct child of the personal
toolbar
Attachment #194093 - Flags: review?(mconnor)
*** Bug 307107 has been marked as a duplicate of this bug. ***
The standard on Mac OS X is to use the Command key to move something, e.g. hold
down the Command key while dragging one of the menu icons in the top right
corner (other than the Spotlight menu, which can't be moved) to change the order
on the menus, or drag it out of the menubar to remove it permanently (with a
little puff of smoke).  Alt (not Shift) would be a sensible equivalent on other
platforms.

The drag-angle idea seems reasonable too.

Please don't break the click-drag-release behavior. :-)
*** Bug 312833 has been marked as a duplicate of this bug. ***
*** Bug 317036 has been marked as a duplicate of this bug. ***
*** Bug 324108 has been marked as a duplicate of this bug. ***
*** Bug 331638 has been marked as a duplicate of this bug. ***
Read the whole thread. Slightly surprised it was not fixed in 1.5.

To give you all a 'neutral user's viewpoint', I have created a bugzilla user account, downloaded the latest version of Firefox and read about the rules of bugreporting only because I am not able to move my bookmark folders.

I then had to find out through extensive search that there is a SHIFT option. 

This IMHO is a totally unacceptable solution as nobody except bugzilla members me will ever find out about the workaround.

Suggested solution:

1 Implement this functionality instead of the current drag-click thing or whatever it is called that seems to be hindering this functionality. It is not used anyway, at least not by me, the 'average user', who has more need for being able to move bookmark FOLDERs just like the way you move BOOKMARKS.

2 Alternatively I suggest to add a hint that shows after mouse is moved up or down while being down, (or some other activity that obviously shows the user is trying to get at something) saying something like "hold SHIFT key to move bookmark folder up or down".

*** Bug 344679 has been marked as a duplicate of this bug. ***
*** Bug 344530 has been marked as a duplicate of this bug. ***
*** Bug 346386 has been marked as a duplicate of this bug. ***
Assignee: p_ch → nobody
QA Contact: mconnor → bookmarks
Version: unspecified → Trunk
*** Bug 350086 has been marked as a duplicate of this bug. ***
This totally would have been awesome for 2.  Poking my husband so maybe this can at least get to trunk.
*** Bug 359695 has been marked as a duplicate of this bug. ***
Attachment #194093 - Flags: review?(mconnor)
This seems to be fixed in Gran Paradiso alpha 5 but this introduced another bad behaviour:

In FF2 you could click on a folder and keep the mouse button pressed, select an entry in the folder and select it by releasing the mouse button.
This does not work anymore but rather some folder drag'n'drop is started.
Ok, just do it like the Windows Start Menu.  The first click and drag on a folder allows one to select a bookmark inside on release, and any click and drag on a folder after that allow folders to be moved around.  Try it in the Windows XP Classic Start menu.  It works great.
I think it would be enough to start the drag'n'drop only if a folder is dragged outside itself. Don't know how hard it is to implement (i'm not a developer...)
So, according to the action of making 350086 a duplicate of this bug, this bug is now supposed to also deal with the fact that dragging of feeds is no longer possible in the current trunk builds.  Seems to me that 350086 should be a separate bug, described as a regression caused by work on this one, and should be set to be dependent on this one, instead of being a duplicate of this one.
In all this discussion, I may have missed it, but I don't think anyone has brought up the way that Safari handles this very problem, which I kinda like...

For bookmarks toolbar menu buttons, if you click on the dropmarker (in Windows, this would have to be the folder icon in Windows), then the menu pops immediately. If the menu is open, you can't drag. Same as what Firefox does currently.

But if you click on the rest of the button, there's about a 1 s delay in the menu opening. And if you drag before it pops, it'll stay closed and you can move it like any other button. The delay time seems just right... enough time to start dragging if you so wish, but not so slow as to be painful if you're waiting for the menu to open (and you can always click on the dropmarker for instant gratification).
OMG this has been an issue for so long!? I am glad to see so many fellow foxes having the same need as me for dragging bookmark folders around in the toolbar (without shift) just like the bookmarks themselves.

Crossing fingers for ff3!
This is partially fixed now, the folders in the menus don't need shift anymore, only folders on the bookmarks toolbar still needs shift to drag.
For consistency's sake I suggest this to be fixed before Firefox 3 ?
Flags: blocking-firefox3?
Sadly, no, not a regression, not a blocker.
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-
If Bug 334244 would be backed out, the problem would be solved.
this issue seems to be solved on fx3b5
(In reply to comment #62)
> this issue seems to be solved on fx3b5
> 

You sure about that?  I think dragging still only works on folders within menus that drop down, not on folders visible on the Bookmarks Toolbar.
I'd be happy to use shift...if it worked.  Unfortunately that only works on Windows.  In Linux and OSX there is NO WAY to move those folders without going to organize bookmarks.
As I written in Bug 439923, I think the simplest solution is to start a drag action when a bookmark folder or a live bookmark in bookmarks toolbar remains clicked for X milliseconds.
Also the idea at comment 53 is not bad. If you click on folder - or live bookmarks - and mouse pointer is moved more than X pixels without releasing mouse click, a drag action should start.

Anyway I must say I had much problems with drag&drop in bookmarks menu. If I'll have time I'll find steps to reproduce the problems.

This bug now affects only toolbar. Can it be moved to Toolbars component?
Keywords: polish, ue
As I wrote in https://bugzilla.mozilla.org/show_bug.cgi?id=439923:
/me too, in FF2 it was not necessary. I liked it to drag'n drop a web site to
my personal toolbar folder without shift, I even did not know that it still
works when shift is pressed. So I came here to file a bug and found this one.
There are currently no tool tips for toolbar folders. If that's not a bug, how about showing "Hold shift to drag"?

I know it's no ideal solution but tool tip hints are widely used and may serve as a workaround until the drag angle solution can be implemented.
Component: Bookmarks & History → Places
Keywords: uiwanted
QA Contact: bookmarks → places
Whiteboard: [polish-hard][polish-interactive]
Target Milestone: --- → Future
>uiwanted

I think the UI is pretty clearly specified in comment #0, the variables here are the threshold for when to switch over to a drag operation.  That will take some playing around with as connor notes so that it feels right, but overall I agree with the proposed UI.
Keywords: uiwanted
i'm trying to implement the threshold thing, taking for now
Assignee: nobody → mak77
Attached patch patch v1.0 — — Splinter Review 
this implements opening when dragging toward down, is a bit "hacky" though, i tried implementing a delayed drag but that di not work, i also tried to not have to prevent popups, but on Linux as soon as we receive a popupShowing the drag is interrupted.
So i ended up preventing popupshowing when dragging containers and opening the popup based on the drag direction or on a delay. This could potentially fail if the user drags really fast, since we don't receive a mousemove, but testing on Windows the behaviour appear good to me.

Btw, i'm generating trybuilds for testing.
Attachment #192765 - Attachment is obsolete: true
Attachment #194093 - Attachment is obsolete: true
(In reply to comment #74)
> builds will appear here:
> https://build.mozilla.org/tryserver-builds/2009-01-14_06:45-mak77@bonardo.net-try-8e3bca092d9/

Marco, I did a test-run with your tryserver build and noticed following issues:

* Pressing the button and move down the mouse some pixels the menu will be displayed promptly. I ended up myself in seeing the menu more often as I wanted to see.

* Snap area by placing a folder/bookmark in-front of the first tab is too narrow. Is there already a bug for that issue?

* Other bugs independent from this patch: bug 229219, bug 473735.

Otherwise it feels great on OS X.
Flags: in-litmus?
(In reply to comment #75)
> * Pressing the button and move down the mouse some pixels the menu will be
> displayed promptly. I ended up myself in seeing the menu more often as I wanted
> to see.

Alex, this is different from the behavior of Safari on OS X. It also has a threshold but ~1s and let users move the folder directly downwards. IMO this is the better way without nagging users.
>Alex, this is different from the behavior of Safari on OS X. It also has a
>threshold but ~1s and let users move the folder directly downwards.

Sorry about the confusion, I thought we were working on a mouse movement direction and distance threshold, as opposed to a time threshold.  Time thresholds can be problematic in that some users are very slow with the mouse, and some users are very fast (people who play first person shooter games for instance).  So it for the first set of users the interface feels non-deterministic (because they don't think about how super slow they are), and for the second set of users the interface feels sluggish.
Alex, could you please test one of the above builds and comment upon it?
Implementing a delayed drag operation is not so easy, i wasn't successful in doing that, even if i tried in different ways.
The zips from comment 74 don't import bookmarks and show no default browser dialog.
thanks for the notice, i probably pushed to trybuild while a bad push was on trunk (there have been a lot of backouts these days)
Tested on Windows XP I see no issues at least not related to this patch; the only difference I noticed is that the shift key is not required anymore.
The try server build works well enough.  There are a few follow up bugs with the way the folder draws itself (probably at a platform level) that I need to file.  Also, if we find a way to solve the issues preventing a threshold approach we should go back and add that, but I think this is certainly an improvement and good enough to land.
Comment on attachment 356946 [details] [diff] [review]
patch v1.0

I hope Mano has some time to take a look at this
Attachment #356946 - Flags: review?(mano)
Attachment #356946 - Flags: review?(mano) → review+
Comment on attachment 356946 [details] [diff] [review]
patch v1.0

I assume you've tested this.

I would rather simplify this by using setTimeout, but r=mano either way.
(In reply to comment #84)
> (From update of attachment 356946 [details] [diff] [review])
> I assume you've tested this.

I did quite some tests and generated trybuilds, i'll do more before pushing.

> I would rather simplify this by using setTimeout, but r=mano either way.

setTimeout for the drag or for the opening? i tried to drag delayed, but i didn't find a good way to do it, emulating events is not enough for starting a complete drag, would be cool if drag code would allow for setting a custom delay before starting the drag operation.
While for the opening, i need to cancel the opening timer if a drag starts in the meantime.
local tests were good, nightly users could give us more informations
http://hg.mozilla.org/mozilla-central/rev/d6a38f6a72b2
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: Future → Firefox 3.2a1
Verified with:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090127 Minefield/3.2a1pre ID:20090127032613

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090126 Minefield/3.2a1pre ID:20090126020316

Any chance to get it into FF3.1?
Status: RESOLVED → VERIFIED
Aakash, if this fix will land on 1.9.1 branch, we have to update your newly added litmus test: https://litmus.mozilla.org/show_test.cgi?id=7454
Comment on attachment 356946 [details] [diff] [review]
patch v1.0

no regressions reported for now, asking for approval.
In case we go for 1.9.1, will need to update user-doc.
Attachment #356946 - Flags: approval1.9.1?
Comment on attachment 356946 [details] [diff] [review]
patch v1.0

a191=beltzner
Attachment #356946 - Flags: approval1.9.1? → approval1.9.1+
user-doc-needed: on all platforms is no more needed holding any key to drag folders/containers on the toolbar, the drag gesture should be toward sides or up of the container.
Keywords: user-doc-needed
Verified with builds on OS X and Windows:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090312 Shiretoko/3.1b4pre ID:20090312034554

I've updated https://litmus.mozilla.org/show_test.cgi?id=7454 too.
Flags: in-litmus? → in-litmus+
Keywords: fixed1.9.1 → verified1.9.1
Depends on: 495675
This bug's priority relative to the set of other polish bugs is:
P2 - Polish issue that is in a secondary interface, occasionally encountered, and is easily identifiable.

effects the main window, but is only occasionally encountered since users don't move folders around that often.
Whiteboard: [polish-hard][polish-interactive] → [polish-hard][polish-interactive][polish-p2]
Depends on: 500143
Oops, looks like I missed this bug when marking 3.5 user-doc-needed bugs as user-doc-complete. The text regarding holding down Shift was removed before Firefox 3.5 was released wherever appropriate in the knowledge base. The main article for this is <https://support.mozilla.com/en-US/kb/Bookmarks+Toolbar?bl=n>.
Keywords: user-doc-needed → user-doc-complete
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
Comment 41 is private: false
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: