Closed
Bug 1434261
Opened 7 years ago
Closed 7 years ago
Unable to add/remove bookmarks after deleting a folder from the star UI
Categories
(Firefox :: Bookmarks & History, defect, P1)
Tracking
()
RESOLVED
FIXED
Firefox 60
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox58 | --- | wontfix |
firefox59 | --- | wontfix |
firefox60 | --- | fixed |
People
(Reporter: alice0775, Assigned: standard8)
References
Details
(Keywords: regression, Whiteboard: [fxsearch])
Attachments
(1 file)
No description provided.
Reporter | ||
Comment 1•7 years ago
|
||
Reproducible: always
Steps to reproduce:
1. Click Start icon
2. Expand folder tree (Click "Show all the bookmarks folders" doropdown button)
3. Select a sub folder
4. Press [Del] key
5. Click "Remove Bookmark"
6. Try to add/delete/move any bookmarks from Star/Sidebar/Library/toolbar/menubar
Actual Results:
Nothing happens.
The functions are no longer working until restart browser.
Expected Results:
Should be working properly
status-firefox58:
--- → fix-optional
status-firefox59:
--- → affected
status-firefox60:
--- → affected
status-firefox-esr52:
--- → unaffected
Keywords: regression
Summary: Unalbe to add/remove bookmarks are no longer work until restart browser → Unalbe to add/remove bookmarks until restart browser
Comment 2•7 years ago
|
||
Is anything printed to the Browser Console?
Priority: -- → P1
Whiteboard: [fxsearch]
Reporter | ||
Comment 3•7 years ago
|
||
(In reply to Marco Bonardo [::mak] from comment #2)
> Is anything printed to the Browser Console?
No error in Browser Console.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0da00124af43d44fed96133300ba5e32b0d821a8&tochange=0a4690dfd7b383e2f732210cf8906ce51a5b2433
Triggered by: 0a4690dfd7b3 Mark Banner — Bug 1071513 - Enable async PlacesTransactions for nightly builds. r=mak
setting browser.places.useAsyncTransactions = false fixes the problem on Firefox58.(Although, folders are deleted and "Remove Bookmark" button becomes disable)
Blocks: 1071513
Assignee | ||
Comment 4•7 years ago
|
||
I'm investigating this at the moment - I can reproduce it.
My initial instinct is that we could/should disable delete in the folder area - there's no real need, unless you accidentally create a folder which is less likely, and if you do accidentally delete a folder, you might be loosing more than you wanted.
However, I would like to understand what's going on, I think this is something in the transaction undo/redo handler but it is kinda strange.
Assignee: nobody → standard8
Assignee | ||
Updated•7 years ago
|
Summary: Unalbe to add/remove bookmarks until restart browser → Unable to add/remove bookmarks after deleting a folder from the star UI
Updated•7 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•7 years ago
|
||
I think what is going on here, is that the star UI/properties dialog has a batching mechanism which automatically batches all transactions. However, the places tree uses the separate controller which also has its own batching for removing items.
The combination of the two, means the delete can't be enacted straight away, as the properties dialog is holding the batch until it completes. When it does complete, the delete is enacted, but due to the remove bookmark, the actions can't be undone and the transaction system effectively blows up, and causes most bookmark actions to stop working.
Comment hidden (mozreview-request) |
Comment 7•7 years ago
|
||
mozreview-review |
Comment on attachment 8953492 [details]
Bug 1434261 - Disable user actions on the places trees not in the library window to avoid accidential/unintentional actions.
https://reviewboard.mozilla.org/r/222724/#review229522
Attachment #8953492 -
Flags: review?(mak77) → review+
Pushed by mbanner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/77d5fc984c50
Disable user actions on the places trees not in the library window to avoid accidential/unintentional actions. r=mak
Assignee | ||
Updated•7 years ago
|
Comment 9•7 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 60
I'd like to let this fix ride the trains with 60 unless someone feels strongly about fixing it in 59.
You need to log in
before you can comment on or make changes to this bug.
Description
•