1317334 - Closing a bookmark folder in bookmark sidebar can select/trigger another bookmark

Status: NEW

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

Description

[bikerunner74]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20161019084923

Steps to reproduce:

- bookmark sidebar is open and contains (for test) from top 40 bookmark links (B1-40), one bookmark folder (BTF) at the bottom with 10 extra bookmarks (BTF1-10)
- open the bookmark folder scroll to the bottom that the last is displayed
- select one bookmark from the folder and close the folder immediately



Actual results:

- the browser starts to load the selected bookmark BTFx
- the displayed bookmarks are moved down after close the folder BTF
- the bookmark replacing the folder item BTF is selected and replaces the BTFx folder in browser

It seems that the folder close click event is somehow distributed to the item replacing the bookmark folder. The computer is an aged WinXP with an Dual P4 D945.

Remark: This does not happen if there exists items below the folder in the bookmark sidebar. The sidebar display is filled from the botton and the folder item remains at the same position. The event is not distributed to another item.


Expected results:

- close the bookmark folder
- do not open the bookmark moved to position of the folder item

Comment 1

[bikerunner74]

Attachment: Display of the bookmark sidebar before close folder "Games"

Comment 2

[bikerunner74]

Attachment: Display of the bookmark sidebar after closing "Games". Folder "ScienceBlogs.de" is opened at the position there "Games" was.

Comment 3

[bikerunner74]

Attachment: Combined before (right) and after (left side) to show the same position of the click location.

I can reproduce the behavior on a Windows 7 system and a current Windows 10 system with the same release version. Does not affect WinXP only.

Comment 4

[bikerunner74]

I made some more tests on the issue. May help to find a cause or solution hopefully.

The "Feeds" folder from the "AfterClose" image shows a lot of feeds. The problem of the extra click happens while closing the elements of a feed if the resulting element is on top of the "Feeds" folder.

The extra click does NOT happen if the resulting element is part of the "Feeds" folder (close a feed with fee elements).

Comment 5

[bikerunner74]

Attachment: Bookmark file example for tests

The strange behavior starts with FF version 46 or 47. Tested with 45 on an old installation and 47 on another one. FF46 not tested.

I can provide a small video (approx. 3MB) to show the behavior. I'm not sure to upload the video as attachment.

Comment 6

[bikerunner74]

Reproduced with:
Mozilla/5.0 (Windows NT 5.1; rv:50.0) Gecko/20100101 Firefox/50.0
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
MacOSX (version 49 or 50)

Comment 7

[Loic]

I can't reproduce it with the bookmarks.htm file you attached.

Could you repost detailed steps to reproduce according to this file, it was confuse in your first comment.

Comment 8

[bikerunner74]

You are right. The explanation is bad. I hope the following is better.

Steps to repeat:
I assume a new browser instance/profile. Only the example bookmarks are imported.

Preparation;
- Open the bookmarks sidebar (Ctrl+B)
- Open the "Bookmarks Menu" folder only.
- The vertical size of the FF window should be changed to view all bookmark content now (from "Bookmarks Toolbar" till "Unsorted bookmarks". This is necessary to allow the bookmark list to scroll on close later.
- Expand the "BFClick" folder and the "BFClick4" sub folder
- Scroll the "Bookmarks" sidebar to the bottom to see the "Unsorted bookmarks" item again
- set the current tab content to "about:blank" (or any other page)

Trigger problem:
- Now click on the arrow (?) left to folder icon of the "BFClick4" folder
- "BFClick4" folder closes.
- The item "Download firefox..." below the "BFTarget" should be scrolled to the current mouse location and the bookmark should be selected. The URL of the bookmark is normally triggered and replaces the tab content.


You can repeat the same with "BFClick/BFClick3" folder:
- Close the "BFClick3" folder
- Now the "BFTarget" folder should be scrolled to the mouse location ...
- ... and the "BFTarget" folder is opened while it was closed before.



I placed an example video (sorry for wrong orientation) here:
https://dl.dropboxusercontent.com/u/21762410/firefoxbug/bookmark_test.m4v

I hope this help to unterstand the issue. I reproduced the same behavior with a Linux version and a friend with a MacOSX version.

Comment 9

[bikerunner74]

One more:
The behavior does not seem to work if you repeat the test with "BFClick/BFClick9":
- Close "BFClick9" folder
- The folder "BFClick/BFClick1" scrolls to the mouse position
- "BFClick1" is not opened

The "extra" click/event seems not to trigger if the resulting item is part of the same parent folder ("BFClick" here).

Comment 10

[Loic]

I can reproduce the issue with FF30, therefore I doubt it's a recent regression.

Comment 11

[bikerunner74]

So it's an old issue and found after bookmark cleanup.

But should not happen from my point of view. It may be a bookmark sidebar issue or a general event handling issue.

A simple workaround may be to add a lot of useless bookmark entries or separators at the end of the list.

But may cause strange side effects or data issues if the user uses bookmark-lets containing java script. These can be triggered with a matching bookmark list.

Comment 12

[Loic]

Yes, it's definitively a bug, maybe already reported due to its old age.

Comment 13

[Joe illen]

You are correct. The clarification is terrible. I trust coming up next is better.

Steps to rehash:

I expect another program occasion/profile. Just the model bookmarks are imported.

Arrangement;

• Open the bookmarks sidebar (Ctrl+B)

• Open the "Bookmarks Menu" envelope as it were.

• The vertical size of the FF window ought to be changed to see all bookmark content now (from "Bookmarks Toolbar" till "Unsorted bookmarks". This is important to permit the bookmark rundown to look on close later.

• Expand the "BFClick" organizer and the "BFClick4" sub envelope

• Scroll the "Bookmarks" sidebar to the base to see the "Unsorted bookmarks" thing once more

• set the current tab substance to "about:blank" (or some other page)

Trigger issue:

• Now click on the bolt (?) left to envelope symbol of the "BFClick4" organizer

• "BFClick4" organizer closes.

• The thing "Download firefox..." underneath the "BFTarget" ought to be looked to the current mouse area and the bookmark ought to be chosen. The URL of the bookmark is typically set off and replaces the tab content.

You can rehash something similar with "BFClick/BFClick3" organizer:

• Close the "BFClick3" envelope

• Now the "BFTarget" envelope ought to be looked to the mouse area ...

• ... furthermore, the "BFTarget" organizer is opened while it was shut previously.

I set a model video (sorry for wrong direction) here:

https://completedraincare.co.uk/drain-cleaning-crawley/

I trust this assistance to unterstand the issue. I repeated a similar conduct with a Linux rendition and a companion with a MacOSX form.

Comment 14

[patrick.philippot]

Hi,

This problem is here since years and observed under various versions of Windows and on various systems. I'm currently using Firefox 110 under Windows 10.

It seems that the folder close click event is somehow distributed to the item replacing the bookmark folder.

Yes. That's the problem. The mouse up message appears to be sent twice and the new bookmark tree organization resulting from the closure of the folder and probably happening between the "normal" click and the superfluous one doesn't seem to be taken into account. So, the folder located at the original click location is opened.

This could be related to the behavior of the bookmark tree when a subfolder has been selected and when the user clicks on the ">" sign at the left of another folder name lower in the tree hierarchy and starts to drag. That's not the clicked folder that is moved but the folder currently selected. Very strange. Maybe a problem with the mouse down event handling influencing the folder close/open process.

Comment 15

[patrick.philippot]

Hi,

The status of this bug should not be UNCONFIRMED. It was confirmed 6 years ago and is still as irritating as it was at that time.

Thanks.