Closed Bug 406269 Opened 17 years ago Closed 15 years ago

Bookmark is visited when collapsing a folder or feed in the Bookmarks Sidebar

Categories

(Firefox :: Bookmarks & History, defect, P3)

x86
All
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: u286998, Unassigned)

References

Details

Attachments

(1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007113005 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007113005 Minefield/3.0b2pre

Collapsing a folder near the bottom of the Bookmarks Sidebar will make the tree control scroll up a bit to fill up the space. The bookmark that is now under the pointer will be visited.

Reproducible: Always

Steps to Reproduce:
1. Open the Bookmarks Sidebar
2. Make sure you have a vertical scrollbar (open some folders or create more bookmarks if you don't)
3. Scroll to the very bottom of the list
4. Open a folder
5. Click [+] to collapse the folder again
Actual Results:  
The control will scroll up a bit and the bookmark that is now under the mouse pointer will be visited.
If there is a folder under the pointer it will open if its parent is not the same as the folder you were collapsing in the first place. (not too sure about that)

Expected Results:  
The folder should close without any additional opening of bookmarks or folders.

Bug 237259 and Bug 261307 seem related but cover behavior in the Mozilla Suite.
Could not reproduce with Firefox 2.0.0.9 so it seems to be a regression.
I hacked my jar files up a bit and adding this line:
   this.parentNode.changeOpenState(row.value);
 + event.stopPropagation();
   return;
to chrome\toolkit\content\global\bindings\tree.xml in line 990 seems to do the trick.
But I don't have any idea if this is the right thing to do.
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Status: UNCONFIRMED → NEW
Component: Bookmarks → Places
Ever confirmed: true
Flags: blocking-firefox3?
QA Contact: bookmarks → places
Version: unspecified → Trunk
(In reply to comment #2)
> Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2)
> Gecko/20060308 Firefox/1.5.0.2
> 
Sorry, I had my User Agent Switcher extension still on :).
I meant: Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120100 Minefield/3.0b2pre
Note: the trick here is making sure you have plenty of folders expanded so that when you close a folder or feed the resulting shift of the sidebar leaves a bookmark under the current mouse position.  If the mouse happens to end up over another folder, nothing happens.

Summary: Bookmark is visited when collapsing a folder in the Bookmarks Sidebar → Bookmark is visited when collapsing a folder or feed in the Bookmarks Sidebar
(In reply to comment #6)
> If the mouse happens to end up over another folder, nothing happens.

I believe this depends on the parent of the folder, as I already wrote in the description. If both folders, the collapsing one and the one over which the mouse ends up on, share the same parent folder nothing will happen, but if they are subfolders of separate parents the default action (opening the folder) will be executed.
Priority: -- → P3
Target Milestone: --- → Firefox 3 M11
Flags: blocking-firefox3? → blocking-firefox3+
OS: Windows XP → All
Attached patch patch (maybe) (obsolete) — Splinter Review
I don't know if this is the right thing to do, but it seems to work.
Attachment #300867 - Flags: review?(mconnor)
Attachment #300867 - Attachment is obsolete: true
Attachment #300867 - Flags: review?(mconnor)
Okay, that patch was pretty stupid, sorry for the spam.
I digged a bit deeper and the problem seems to be that the onclick handler is called after the widgets click handler. Shouldn't it be the other way round so the onclick handler has a chance to cancel the default action?
Anyways, the issue here is that the onclick handler has no chance to detect what pseudoelement was hit by only using the coordinates when the widget was scrolled, which is exactly what happens in this bug.
I guess this could be fixed by registering mouseup and mousedown handlers to check if any scrolling occurred but I probably should be writing my diploma thesis instead of messing with firefox code... :)
Target Milestone: Firefox 3 beta3 → ---
WFM on current trunk.  Minusing.
Flags: blocking-firefox3+ → blocking-firefox3-
wfm current trunk, closing
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: