New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 595862 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Jul 2016
Cc:
█ tkonch...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

chrome.bookmarks.onRemove does not fire on nested directories

Reported by dill...@g.clemson.edu, Mar 17 2016 
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

Steps to reproduce the problem:
1. Install attached extension
2. Open inspector on extension and navigate to console tab

What is the expected behavior?
The extension creates a bookmark nested in two directories, then deletes the top level directory. As per [https://developer.chrome.com/extensions/bookmarks#event-onRemoved] This should cause the onRemoved listener to run twice (once for the top level directory & once for the other directory)

Output
[id]
[id]
[id]
Bookmark id [id] removed
Bookmark id [id] removed

What went wrong?
The listener is only called once.

(exact ids will differ)
Output
139
140
141
Bookmark id 139 removed

Did this work before? N/A 

Chrome version: 49.0.2623.87  Channel: stable
OS Version: 3.13.0
Flash Version: Shockwave Flash 21.0 r0
example.zip
711 bytes Download

Comment 1 by tkonch...@chromium.org, Apr 1 2016

Cc: tkonch...@chromium.org
Components: Platform>Extensions
Labels: -OS-Linux M-51 OS-All
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Linux chrome version 49.0.2623.110 - The listener is only called once

This is seen from M32 builds to latest dev

This issue is also seen in mac and win as well

Confirming the issue for further inputs on this

Comment 2 by tkonch...@chromium.org, Apr 1 2016 

Please find the screenshot
595862.png
15.8 KB View Download

Comment 3 by asargent@chromium.org, Jul 22 2016

Status: WontFix (was: Untriaged)
The documentation states "When a folder is removed recursively, a single notification is fired for the folder, and none for its contents", so I think this is actually working as designed/specified. 

To the original reporter: does this seem reasonable? I'm speculatively marking as Wontfix, but we can always reopen if need be.

Comment 4 by dill...@g.clemson.edu, Jul 25 2016 

Except a single notification is not being fired for the recursively removed folder. The third node is a url, so "none for the contents" applies there, and I don't expect an notification to fire for it. However the second node is a recursively removed folder, so "a single notification is fired for the folder" should apply, but no such notification is fired.
►

Sign in to add a comment