299185 - Bookmark toolbar folder doesn't open when a url is dragged and dropped

Status: NEW

(Core :: Widget: Cocoa, enhancement)

Description

[Pete Hammer]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050627
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050627

Can't drag and drop url to the personal toolbar to place it where desired inside
the folder, or into a SUBfolder. 

Dragging a URL to a folder on the toolbar won't open the folders on the toolbar,
so you can't drag into sub-folders of the folders.  Dragging to the toolbar, and
to folders on the toolbar, works fine.  As far as I know, dragging to 
sub-folders has NEVER worked for me on the Mac, 1.0 - 1.7, OS9 and OSX.  

Creating a new profile doesn't help.

Reproducible: Always

Steps to Reproduce:
1. Drag link to existing folder on toolbar
2. Pause on folder to let it open to reveal subfolders
3. Wait forever.

Actual Results:  
Dragging a url and dropping it on a folder will put it at the end of the
contents of that folder, but the folders won't open to allow placing the
bookmark as desired within the folder, or in a subfolder. 

Expected Results:  
Should act like the Windows versions, where the toolbar folders will pop open
and let you position the bookmark exactly where you want it in that list,
including inside subfolders.

I tried to hijack bug 199998 to pick up this issue, but it is being ignored, so
I am creating this new one to goose it back to life.  I have not had this
feature on the Mac since the end of the OS9 builds.  

I do have a large bookmark file, and have been using decendants of the same file
for a long time, but I have tried creating new profiles, no help.  

This bug also exists in Firefox 1.0.3 also (Mozilla/5.0 (Macintosh; U; PPC Mac
OS X Mach-O; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3.)

Comment 1

[Pete Hammer]

OK, found some predecessors: bug 271891.  But never fixed on Mac...

Comment 2

[Pete Hammer]

I changed this to Core since I see it on OSX Firefox also.  I see lots of fixed
things that are similar, but this one still exists on OSX, and the basic
difference is that the top level toolbar folders won't open at all when a url is
dragged onto them.  So it is not like bug 271891 in being only SOME of the
subfolders not being accessible.  NONE of the subfolders are accessible, because
the top level folder never opens.

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to comment #2)
> I changed this to Core since I see it on OSX Firefox also.  I see lots of fixed
> things that are similar, but this one still exists on OSX, and the basic
> difference is that the top level toolbar folders won't open at all when a url is
> dragged onto them.  So it is not like bug 271891 in being only SOME of the
> subfolders not being accessible.  NONE of the subfolders are accessible, because
> the top level folder never opens.

hangdog, can you and whitely report:

a) this happens with one of the newest nightlies and using safe mode, just to be
sure it hasn't been affected by recent activity
 SM http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/
 FF http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
 
b) the theme are you using and what other themes you have tried.

c) are there reports of similar problems in any forums?

I won't confirm based on one report because I don't use MAC - but if there is
corraborative information, I could.

Also, not clear to me if this is a core bug, but leaving here and reassigning to
default owner and QA for now.

Comment 4

[John Whitley]

(In reply to comment #3)
> a) this happens with one of the newest nightlies and using safe mode, just to be
> sure it hasn't been affected by recent activity
>  SM http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/
>  FF http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

I repro'd the problem in both of these nightlies just now (2005-Aug-9).  I note
that SM seems to at least highlight the folder or toolbar position, which FF
doesn't do (per my closely related bug 300598).

> b) the theme are you using and what other themes you have tried.

Default themes for SM and FF, and FF themes Red Cats (green flavor) 3.0.1,
Brushed 0.9.9.5, Abstract Mac 1.0.

> c) are there reports of similar problems in any forums?

I believe that I've seen reports of this problem, but I'm having the darndest
time sifting them out of my search results.

Comment 5

[Pete Hammer]

(In reply to comment #3)
> a) this happens with one of the newest nightlies and using safe mode, just to be
> sure it hasn't been affected by recent activity
>  SM http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/
>  FF http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

same here.  Still not opening the toolbar folders for either program.  I also
see what John notes about FF/DP not even highlighting the top-level folder.  At
least Mozilla/SM shows the outline of the button when dragged over.

I have only tried this with the Modern theme in SM/M and the default in FF/DP.

I tried both my current profile and a new blank/default profile in each, no
difference.

I have identified a slew of other bugs that this behavior is mentioned in, but
the bugs have all been resolved as dupes or otherwise.  I think this behavior
has been mentioned in a few of them (I know I've tried to add/hijack this to a
few discussions), but I don't think it has ever been fixed.  I was serious when
I said I don't think this has worked for me since OS9...

Comment 6

[Pete Hammer]

Changed to more concise summary, bumped to Major...  I also dug up the oldest
version of Mozilla I had, and it also has the same behavior with a default user
profile (OS9 1.2b build 20021021).

Comment 7

[Pete Hammer]

Here's a list of bugs I have attempted to list this issue under:

bug 171582, bug 199998, bug 235243, bug 271891.  

Comment 8

[Andreas Wuest]

I can confirm this bug with yesterdays Firefox build: Mozilla/5.0 (Macintosh; U;
PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051005 Firefox/1.4.1

This is quite a heavy ui impairment on Mac platform!

Comment 9

[Wayne Mery (:wsmwk)]

*** Bug 300598 has been marked as a duplicate of this bug. ***

Comment 10

[Wayne Mery (:wsmwk)]

might this MAC bookmark bug (and some others from *) depend on and require fixing one of the many "mac click" bugs**, the oldest of which is bug 39192? [bug 108126 and bug 117589 may be another good examples]

*https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=anywordssubstr&short_desc=drag+drop+click&product=Core&product=Firefox&product=Mozilla+Application+Suite&product=Thunderbird&product=Toolkit&resolution=---&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&rep_platform=Macintosh&op_sys=All&op_sys=Windows+95&op_sys=Windows+98&op_sys=Windows+ME&op_sys=Windows+2000&op_sys=Windows+NT&op_sys=Windows+XP&op_sys=Windows+Server+2003&op_sys=Windows+CE&op_sys=Mac+System+7&op_sys=Mac+System+7.5&op_sys=Mac+System+7.6.1&op_sys=Mac+System+8.0&op_sys=Mac+System+8.5&op_sys=Mac+System+8.6&op_sys=Mac+System+9.x&op_sys=MacOS+X&chfieldto=Now
**https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=click&product=Core&product=Firefox&product=Mozilla%20Application%20Suite&product=Thunderbird&product=Toolkit&resolution=---&rep_platform=Macintosh&op_sys=All&op_sys=Mac%20System%207&op_sys=Mac%20System%207.5&op_sys=Mac%20System%207.6.1&op_sys=Mac%20System%208.0&op_sys=Mac%20System%208.5&op_sys=Mac%20System%208.6&op_sys=Mac%20System%209.x&op_sys=MacOS%20X&chfieldto=Now&field0-0-0=short_desc&type0-0-0=anywordssubstr&value0-0-0=double%20hold&order=bugs.bug_id&query_based_on=

Comment 11

[Karsten Düsterloh]

So, the problem here is actually bug 136524 resp. its "fix" which simply disables this feature on Mac. If I revert that patch, the bookmark menupopup opens, but it stays completely white as long as I hover the URL over the button. Moving the URL over the menupop then shows the bookmarks and a drop marker, but autoscrolling the bookmark list doesn't work...

Comment 12

[damacus]

I am also affected by this bug.  Mac OS X 10.4.8, Firefox 2.0RC3.

Build identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/2006101022 Firefox/2.0

Comment 13

[gb5150]

Hi there. Is there anything we can do to get this back on someone's radar? I wish I could do it myself. Alas, I'm mostly untechnical. But would gladly help in any way I can. Thanks!

Comment 14

[Wayne Mery (:wsmwk)]

you need to find a mac person perhaps from irc #developers

as noted by karsten in comment 11, this was caused by the patch to bug 136524. The patch was reviewed by [e-mail] and i don't quite understand why it passed review and was checked in, but 4 years ago the standards might not have been too high.

Comment 15

[timeless]

pch at the time owned bookmarks.

the standard for firefox was generally: if the ui is very broken, and removing something will improve the user experience at the cost of theoretically lost broken functionality, then it would be removed.

dnd for mac didn't work, you can load the tiff from the bug yourself and see.

as for the standard for becoming module owner in firefox, i really shouldn't comment. perhaps it was rewrite the module or work on it heavily for a few months and then disappear. i dunno, i don't care. modules are abandonned all the time.

i'm pretty sure that beltzner and mconnor would agree w/ the general spirit from when the broken feature was removed: trying to have a feature which when triggered doesn't work and looks very ugly is much worse than not having the feature. that really is a timeless rule (and not my own).

as for asking on irc. well, you can do it, but you have to do it properly. acting as if the people there have nothing better to do than bend to the whims of someone we've never heard of just isn't the way to do it.

karsten: please be careful about your word choice. you yourself clearly discovered that the feature if reachable doesn't work correctly. the fact that the feature is disabled isn't the problem, and accusing me or pch of removing it as if it's our fault isn't appreciated and is definitely not the way to get people to help.

i shouldn't bother cc'ing cbarrett since that might get this bug fixed and i don't want to reward any of the people who have touched it recently. but well, i'm a nice guy.

oh, i'm bumping the severity to enhancement. this is new feature work for mac, since it hasn't worked in years and requires someone to work on it.

while i'm complaining: [e-mail], me toos are not appreciated in bugzilla. if a bug is open, it is assumed to affect everyone who would try to use the feature on the affected os/version.

Oh, I suspect this bug doesn't belong in DOM not sure why it's there. qawanted: please find a more appropriate component (widget:cocoa?).

Comment 16

[Wayne Mery (:wsmwk)]

timeless, thanks for the background - since most of us, myself included weren't around here in 2002. My comment about standards was an observation based in part on the fact that the patch landed in 2002 and no regression bug (eg. this bug) was filed at the time - a lapse suggesting to me an incompleteness about the process used.  But more generally my comment was simply a restatement of the status and clarifying the source of the problem for anyone who cared to take up the cause.  And geez wiz, karsten's comment was simply stating facts in plain english - is there really an accusation or criticism in there? I don't see it.

Comment 17

[damacus]

> the standard for firefox was generally: if the ui is very broken, and removing
> something will improve the user experience at the cost of theoretically lost
> broken functionality, then it would be removed.

This is a great standard.  I agree with it.

> i shouldn't bother cc'ing cbarrett since that might get this bug fixed and i
> don't want to reward any of the people who have touched it recently. but well,
> i'm a nice guy.

lol, thx :)

> oh, i'm bumping the severity to enhancement. this is new feature work for mac,
> since it hasn't worked in years and requires someone to work on it.

Agreed.

> while i'm complaining: [e-mail], me toos are not appreciated
> in bugzilla. if a bug is open, it is assumed to affect everyone who would try
> to use the feature on the affected os/version.

Apologies, mate.  I'm new here.

> Oh, I suspect this bug doesn't belong in DOM not sure why it's there. qawanted:
> please find a more appropriate component (widget:cocoa?).

Is this something for those of us interested in this bug to do, or do you have a QA group that searches that tag?  See prior comment. :)