Closed Bug 1397387 Opened 4 years ago Closed 4 years ago

No longer able to edit bookmark item after closing New Bookmark or New Bookmark Folder dialog by [x] button

Categories

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

57 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 57
Tracking Status
firefox-esr52 --- unaffected
firefox55 --- unaffected
firefox56 --- disabled
firefox57 + fixed
firefox58 --- verified

People

(Reporter: alice0775, Assigned: standard8)

References

Details

(Keywords: regression, Whiteboard: [fxsearch])

Attachments

(1 file)

[Tracking Requested - why for this release]:

+++ This bug was initially created as a clone of Bug #1397369 +++

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170905220108

Steps to reproduce:

STR
1. Enable Bookmarks toolbar
2. Right click on the toolbar and Choose "New Bookmark/Folder..." and then click on [x] button

3. Try delete, rename, move a bookmark item


Actual results:
New Bookmarks/Folder are created at step2.
No longer able to edit bookmark item at step3 until restart browser.


Expected results:
New Bookmarks/Folder should not be created at step2.
Eble to edit bookmark item at step3.


Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0da00124af43d44fed96133300ba5e32b0d821a8&tochange=0a4690dfd7b383e2f732210cf8906ce51a5b2433

Regressed by:
0a4690dfd7b3	Mark Banner — Bug 1071513 - Enable async PlacesTransactions for nightly builds. r=mak
I can reproduce this, and I think I know what it is - it looks similar to bug 1396888 - the dialog is going away whilst we're resolving the batch for the async transactions so it all goes out of scope and leaves the transaction manager in a bad state.
Assignee: nobody → standard8
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [DUPEME] → [fxsearch]
The patch here should fix it, but I'm on Mac and I need to test on Windows, so I'll push it to try and give it a run in the morning.
Duplicate of this bug: 1397369
I tested the try build on Windows and it seems to work fine.
Comment on attachment 8905249 [details]
Bug 1397387 - Move async actions out of the opening/closing cycles of the bookmarks dialog to ensure they finish.

https://reviewboard.mozilla.org/r/177044/#review182288

::: browser/components/places/PlacesUIUtils.jsm:671
(Diff revision 2)
> -    return ("performed" in aInfo && aInfo.performed);
> +
> +    let performed = ("performed" in aInfo && aInfo.performed);
> +
> +    if (this.useAsyncTransactions) {
> +      batchBlockingDeferred.resolve();
> +      batchBlockingDeferred = null;

nit: this nullification should not be necessary
Attachment #8905249 - Flags: review?(mak77) → review+
Pushed by mbanner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c0735e51d280
Move async actions out of the opening/closing cycles of the bookmarks dialog to ensure they finish. r=mak
https://hg.mozilla.org/mozilla-central/rev/c0735e51d280
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
I have reproduced this bug with Nightly 57.0a1 (2017-09-05) on Windows 8.1, 64 Bit!

This bug's fix is verified on Latest Nightly 57.0a1.

Build ID :  20170910100150
User Agent : Mozilla/5.0 (Windows NT 6.3; WOW64; rv:57.0) Gecko/20100101 Firefox/57.0
QA Whiteboard: [bugday-20170906]
Build ID: 20171016220427
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0

Verified as fixed on Firefox Nightly 58.0a1 on Windows 10 x 64, Windows 7 x32, Mac OS X 10.12 and Ubuntu 16.04 x64.
Status: RESOLVED → VERIFIED
Flags: in-qa-testsuite+
You need to log in before you can comment on or make changes to this bug.