644529 - Bookmarks toolbar submenu disappears when dragging new URL to it.

Status: RESOLVED FIXED

(Firefox :: Theme, defect)

Description

[Adrian Schmidt]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0

When I'm visiting a page, and want to bookmark the current URL, I usually drag it from the address bar, by grabbing the favicon, and drag it to my bookmark bar.
In the bookmark bar I have a couple of folders, with subfolders in them.
If I hover over a folder on the bookmark bar, a menu opens.
However, since upgrading to Firefox 4.0, very often when I move the mouse downwards over the open submenu, it closes, just as the mouse leaves the folder "button" in the bookmark bar.
This also happens when dragging an existing bookmark from the bookmark bar to a folder.
It does not happen when "empty handed" and clicking on the folder "button" to open the menu.
It also only happens to top level folders on the bookmark bar. Any subfolder menus work as expected.

It seems like the problem is constant when moving the mouse slowly, but it can sometimes be mitigated by moving the mouse very fast.

Reproducible: Always

Steps to Reproduce:
1. Drag the current URL or an existing bookmark from the bookmark bar
2. Hover over a non-empty folder in the bookmark bar, so that its menu is displayed
3. Move the mouse from the folder "button" towards the open menu
Actual Results:  
The open menu disappears when the mouse moves over a small area between the folder "button" and the corresponding open menu.

Expected Results:  
The open menu will be kept open, to allow the user to drop the bookmark in a certain order, or in a subfolder.

I'm using the default theme.

Comment 1

[Ed Morley [:emorley]]

Could you see if the issue occurs if using Firefox in safe mode:
http://support.mozilla.com/kb/Safe+Mode

How about with a new, empty testing profile? (Don't install any addons into it)
http://support.mozilla.com/kb/Basic+Troubleshooting#w_8-make-a-new-profile

Comment 2

[Adrian Schmidt]

The problem persists with a new profile, and with using safe mode with that new profile.

Comment 3

[Marco Bonardo [:mak]]

I can reproduce on snow leopard.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Adrian, lots has changed since this was filed. Does this still reproduce for you?

Comment 5

[Adrian Schmidt]

I can confirm that this does still reproduce in Firefox 39.0 on Mac OS X 10.11 El Capitan.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Paul, can you please try to track this down with mozregression?

Comment 7

[Paul Oiegas [:poiegas], PM for Ecosystem QA (OMC, New Tab, Contextual, Nimbus, Experiments), Services QA (VPN, FxA/Subplat, Relay, Monitor), WebCompat QA, and Solo QA teams)]

Hi Ryan,

Managed to track this old fossil down. The bug first appeared in the 2010-03-06 Nightly build and it perfectly worked in 2010-03-05 one.
Here is the pushlog for the two builds 
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ab85a037d0a6&tochange=db38e530c170

Enjoy :)

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Bug 549988 seems like the only relevant-looking commit in that range.

Comment 9

[Dão Gottwald [:dao]]

Attachment: patch

Obviously this will partly regress bug 549988, but this seems like the right trade-off...

Comment 10

[:Gijs (he/him)]

Comment on attachment 8690020 [details] [diff] [review]
patch

Review of attachment 8690020 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah, r=me

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/489332006384

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/489332006384