User Agent: Opera/9.80 (Windows NT 6.1; U; en) Presto/2.9.168 Version/11.52 Steps to reproduce: I enabled firefox sync. I clicked on "bookmark this page" in the bookmark drop down menu to create a new bookmark. The "edit this bookmark" dialog shows up, and I then clicked on the "new folder" button. Actual results: A new folder appears, but I am unable to name the new folder. Expected results: A new folder appears, and I should have been able to name the new bookmark folder.

The "edit this bookmark" dialog should be corrected to "page bookmarked".

I'm not sure how this could be related to sync... did you install the old Sync extension by chance?

fwiw, the bookmarks dialog I see in comment 2 is wrong, please try safe mode since the issue may be due to some other add-on: http://support.mozilla.com/kb/Safe+Mode

Err, yeah, nothing to do with Sync. Minh: did you try clicking in the name box for the new folder? I don't think it necessarily has focus by default (it doesn't on my Mac), so whatever you type won't have any effect.

I recently took a look at this issue I'm having with safe mode enabled. In response to Marco's comments, yes the bookmark dialog was from an extension that I have installed. However, the default bookmark dialog in safe mode still had the issue of losing focus on the "new folder", which stopped me from naming it. I then tried Richard's suggestion and double clicked the "new folder", which allowed me to rename it. I tried disabling "Firefox Sync", and creating a new folder did not lose focus on the name box. I realized this is a minor issue I'm having, but I would like someone else to confirm if this is a bug or not as Firefox Sync for me changes the focus effect when creating a "new folder" in the bookmark dialog.

I have a similar problem. When the "bookmarks" selection is checked in the Tools - Options - Sync menu page; I am unable to slowly type a complete new bookmark folder name before the dialog box highlights the typed letters and disappears as if the enter key were pressed. The partial name as typed does appear in the bookmarks list. When "bookmarks" is unchecked in the Sync menu, I can type in a new bookmark folder name without problem. If the Sync menu "bookmarks" option is unchecked and then rechecked without restarting Firefox, the "New Folder" menu button will not bring up the dialog box to enter the new bookmark folder name. I am running Firefox 9.01 under XP SP 3. This error appeared about a year ago when running an earlier version of Firefox. Disabling Extensions and Add-Ons has no effect on the problem.

Mozilla/5.0 (Windows NT 6.1; rv:13.0a1) Gecko/20120206 Firefox/13.0a1 Mozilla/5.0 (Windows NT 6.1; rv:12.0a2) Gecko/20120212 Firefox/12.0a2 Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 beta 2 Confirming that this issue is reproducible (with a clean profile): - with sync set up and bookmarks preference enabled in sync options, focus is lost when creating a new folder for bookmarks in "Edit This Bookmark" panel; you can rename the folder only by double-clicking to edit - if sync is not set up or bookmarks preference is disabled in sync options, there is no prblem in editing the new bookmark folder name in "Edit This Bookmark" panel (focus is not lost)

Probably something to do with Sync's observers. Let's put this somewhere we can keep an eye on it.

Per comment 8 I tried unchecking Preferences in the bookmark sync options but it had no effect. Unchecking Passwords worked, but only once. The second time I tried to create a new folder FF went back to trying to rename the current folder (the folder under which I'm creating the new folder). I rechecked Passwords and unchecked History and it worked once. On the second try it behaved as before, renaming the current folder. Unchecking Add-ins and Tabs had no effect. I couldn't make this process work a second time (maybe it will work after a reboot): I checked History, exited the menu, then unchecked History again and still couldn't create a new folder.

I have the same problem with the weird behaving bookmarks. It is driving me crazy and has been for months! The other thing this bug is causing: While I am naming the folder, the folder becomes fixed and I can't name it anymore. Then I have to double click it again and quickly type. If I wait to long this whole process starts over. NUTS! The problems go away if I configure Sync by unchecking "Booksmarks" under the "Sync My" section. That is normally the only option I have checked anyway. What is also strange, is that this bug is happening on 3 of my PC's that use the same bookmarks structure/data. So I guess something in my bookmarks is causing Sync to fall over. I am so glad I found this error report. It has been driving me crazy for months. Now I will only enable Sync every now and then.

This bug has been around for a long time. Does this mean mozilla doesn't care enough about it to fix it? It is highly annoying to have to deal w/ this problem. The work around of not using sync or of leaving sync turned on only periodically can't be considered mozilla's long term solution could it?

(In reply to ipcnt from comment #15) > This bug has been around for a long time. Does this mean mozilla doesn't > care enough about it to fix it? It is highly annoying to have to deal w/ > this problem. The work around of not using sync or of leaving sync turned on > only periodically can't be considered mozilla's long term solution could it? See Bug 600059, which is a dependency of this 'symptom' bug. This work will take place some time in the next two quarters. As bugs go, this is in the "annoying" category (you lose focus, and have to reacquire it), not "catastrophic", but the fix involves an enormous amount of work, so it hasn't yet been done.

I have restored the dependency and the component, cause my guess was wrong, this is still due to event spinning, sorry.

847176 is *not* a duplicate. I have experienced this behaviour on 4 different Windows PCs running everything from XP to Windows 7, where Firefox sync was disabled. I still have access to 3 of them, where the behaviour is more or less unchanged. With FF 19, focus/selection of the newly created folder name is sometimes maintained, but in this case, key strokes into the selection to enter a new name are ignored. More often the behaviour is as described in 847176.

Have readily experienced this bug across many versions of Firefox on many different computers with different versions of Windows over a number of years and tried all the tricks with disabling addons etc.

I do *not* see this with Australis. Resolving as WFM.

Unresolved and still observed on FF 25 - build: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0. Migrating to Australis or Nightly is unfornutaly not an option here. Enabling sync via a local server (1-2ms net latency tops) makes any bookmark editing to initially freeze for 4-5 seconds. An additional bug appears when a new folder is being created within an existing folder - directly dependent on enabling the sync option for bookmarksk - name provided for the new folder is wrongly applied as a rename job of its parent.

Richard Newman, how rigorous was your testing? On which Australis version did you *not* see this? What amount of bookmarks did your profile contain during the test? What was your latency to the sync server cloud? After many hours of testing this through and through in the past 2 days on Australis (Nightly 29.0a1) I must sadly conclude that nothing has changed from FF 25 or 26. Aside from having to fight with Australis's lack of UI to configure a self-operated sync server and painful API compatibility issues during account registering on the server, the bug still appears. See the below breakdown of scenarios. Trigger for this bug is the amount of bookmarks and possibly also latency, when the Firefox native cloud sync server is utilized. 1) Firefox native sync account, empty profile, only handful of bookmarks - symptoms: Delays in New Folder creation, loses focus, exactly as original reporter described. Delays during bookmark editing e.g. creating a new folder through Show all bookmarks - Library only marginal. 2) Weave local sync server - empty profile, only handful of bookmarks - symptoms: None apparent, works as expected. 3) Weave local sync server - filled-up profile, 1000+ bookmarks: Delays in New Folder creation, loses focus, exactly as original reporter described. Extreme delays (2-3 sec freezes) during bookmark editing e.g. creating a new folder through Show all bookmarks - Library. Asking you to kindly reopen the bug. I don't want to raise a new bug for something that has been around for 2,25 years.

(In reply to Jan Kozanek from comment #28) > Richard Newman, how rigorous was your testing? On which Australis version > did you *not* see this? Nightly in November, which is Firefox 28. > What amount of bookmarks did your profile contain > during the test? 1,154. > What was your latency to the sync server cloud? About 300msec according to my logs. > 1) Firefox native sync account, empty profile, only handful of bookmarks - > symptoms: Delays in New Folder creation, loses focus, exactly as original > reporter described. Are you seeing a modal sheet/dialog for New Folder, or something else? What platform are you using? If it's Windows, then it's possible that Classic Windows still has an interaction pattern that manifests as this bug, and we should reopen it for that platform.

I confirm that the lag observed when bookmarking or moving around bookmarks is still there in Firefox v26 with Sync enabled, and very significant (several seconds) when the number of bookmarks is large, which is a common use case, I think. (I don't know how many bookmarks I have, but my bookmarks.hmtl export file is around 3.3MB...) Of course, there is a trade-off: one could have online back up either for every single move (safe but very slow, the current situation) or only at the end of each (user-defined) time period (1 minute, 10 minutes, etc., as it is the case in traditional software). Of course, one could have, in addition to this, another automatic backup when the user closes the software (just in case). I suggest the user-defined backup solution. In fact, I think backing bookmarks up every minute for example is at safe as the current "instant backup" and a better use of both client and server resources. Thanks in advance for your attention!

(In reply to David Bourguignon from comment #30) > I confirm that the lag observed when bookmarking or moving around bookmarks > is still there in Firefox v26 with Sync enabled Firstly, we would expect that to be the case; Firefox 26 left the development stage several months ago, whereas this bug tracker tracks the current state of the software (currently Firefox 29, about to roll over into Firefox 30). I'm primarily concerned if you can reproduce using a current Nightly build. Secondly, please make sure to qualify your report with which platform you're using. > Of course, one could have, in addition to > this, another automatic backup when the user closes the software (just in > case). Doing work on shutdown is a no-no for various reasons. > I suggest the user-defined backup solution. In fact, I think backing > bookmarks up every minute for example is at safe as the current "instant > backup" and a better use of both client and server resources. Thanks in > advance for your attention! Firstly, Sync isn't a backup solution. (There's no good restore mechanism, no snapshotting, no history, no durability, no verification, etc. etc.) Secondly, the work here is not in doing a backup; it's largely overhead from syncing bookmarks at all. That doing so stalls the browser is an implementation flaw, not so much an issue with when we do the work. If you're interested in why the current approach was taken: https://wiki.mozilla.org/Firefox/Features/Instant_Sync

Thanks Richard for your explanations. Now, I better understand the situation. (I didn't know that this bug report was about nightly builds.) Thanks in advance for any improvement in the sync algorithm.

Richard Newman could you please reopen the bugreport? I am experiencing the bug on Firefox Nightly 30 on Fedora 20 KDE

Reopening for Linux.

the fact this was fixed for a while is likely due to bug 818399, when it was active we were not batching in some cases, now that has been backed out and the issue came back.

(In reply to Marco Bonardo [:mak] from comment #35) > the fact this was fixed for a while is likely due to bug 818399, when it was > active we were not batching in some cases, now that has been backed out and > the issue came back. That on Mac we use a sheet for naming new folders, rather than an edit box after creation, is probably also relevant. This is a platform-dependent bug -- it still doesn't repro on Mac.

(In reply to Richard Newman [:rnewman] from comment #29) I had my notifications configured to send reminders only upon a bug status change, hence apologies for responding just today. > > What amount of bookmarks did your profile contain > > during the test? > > 1,154. During my test it was similar - around 1200. Amounting for approx. 1.4MB of space for bookmarks alone on the sync server. > > What was your latency to the sync server cloud? > > About 300msec according to my logs. Even better at my end - around 230ms avg to the Mozilla cloud. To the local weave it didn't go beyond 10ms. > > 1) Firefox native sync account, empty profile, only handful of bookmarks - > > symptoms: Delays in New Folder creation, loses focus, exactly as original > > reporter described. > > Are you seeing a modal sheet/dialog for New Folder, or something else? I select an existing folder under which I want the new one to be added, then press the New Folder button. Instead of showing me an editable, blanket 'New folder' box inside the currently selected folder, FF/Nightly opens the very name of the currently selected folder for editing. Placement of the new folder and consequently the bookmark then becomes unpredictable. > What platform are you using? If it's Windows, then it's possible that > Classic Windows still has an interaction pattern that manifests as this bug, > and we should reopen it for that platform. Windows 7, 64bit. If yours is Mac, then it is probably a platform thing, once a particular size of the bookmarks file & latency thresholds are crossed.

FF 29.0.1, Win7, 64Bit - behavior as described by original observer. No add-on's here. Default Theme. Problem began as soon as Sync was enabled.. Doesn't change in Safe Modem. Looks like I'm stuck like everyone else lol until someone works on this.

The problem **does** appear even on Firefox 29 with the new sync enabled

I can confirm this is still happening to me years later in version 29.0.1 It's not a hard thing to get around, for when it stops accepting inputs and "sets" the folder name, you can simply double-click the folder name and then name it what you would like without it "timing out" as it does upon original folder creation.

I'm putting this in the backlog because what with our pushing new sync, I think we should investigate/fix this soon.

This bug has been active since 2011??? Wow.... Any bug that has not been fixed in like 3 years, sure has to get some priority, not? Come on 3 years! =( Most people even don;t know that they can ome to this website to vote.... or do they? they properly switched to Crome or something... To be honest I find this bug to be onnoying. I cannot bookmark normally... Please fix?

+1

Additional info: Firefox 30.0 Add ons: video downloadhelper, ABP, Noscript, Sync enabled. windows 7 SP1

Quick workaround for those just reporting this issue: double-click the folder name after it loses focus and you can resume naming. It's not elegant by any means, but it works.

(In reply to chihwahli from comment #45) > This bug has been active since 2011??? Wow.... > Any bug that has not been fixed in like 3 years, sure has to get some > priority, not? Come on 3 years! =( By that reasoning, there are tens of thousands of bugs and work items ahead of it, stretching back to 1999. Your interest is appreciated, but with limited developer time I don't know if or when this bug will be addressed.

@Richard newman I understand. 1999?? I wish the opensource community would realise that they are just too scattered. If people unite into less versions of this and that, windows and IE would be history way fast. Too many linux distros, too many browers..... it's a shame really. So much potential! Cheers to all opensource programmers. thanks so far. Like Firefox, will be using it for a loooong time. =)

I am saving in bookmarks some of the tabs I keep open in Firefox, and the bookmark managing activity is very frustrating: text boxes that lose focus, scrolling menu that does not scroll until you wait for some seconds, etc....

I figured I made a big mistake in comment 35. The bug I wanted to point out was bug 894331 that was in Nightly from August 2013 to January 2014. That bug made this one go away cause in some cases (like tags) we were not executing a batch anymore. So any Nightly from August to January would not show this bug, unfortunately they shown performance regressions in the UI, that is why the bug was backed out.

Will our heroes manage to get this ~5 years old bug fixed?

@Germano, While this is somewhat irritating, I can understand why it does not enjoy a high priority. There is an easy workaround: Install the add-on "Xmarks Sync" (https://addons.mozilla.org/en-US/firefox/addon/xmarks-sync/) and disable automatic synchronization. Use "Sync on Shutdown" instead. I have been using Xmarks for years and will continue to do so as long as this problem with Firefox Sync is unresolved.

Xmarks sadly delete the only advantage of Firefox - having control over privacy of your bookmarks & tabs and NOT storing them at a 3rd party. Where this aspect is of little concern, I suggest an upgrade to Chrome (https://www.google.com/chrome/browser/desktop/). It is faster in most scenarios, crashes less and provides out of the box bookmark sync on majority of platforms without bugs, as opposed to Firefox.

IIRC, both Xmarks & Firefox allow you to specify your own server. If you use the default setup, any of these services is entrusting your data to someone else, be it Xmarks, Mozilla (in the case of Firefox) or Google (in the case of Chrome). Of these, I trust Mozilla the most and Google the least. Xmarks is a compromise. I also prefer Xmarks to Google because they don't have as many other ways of collecting and aggregating data about me. I feel safer when the data I entrust to 3d parties isn't all under the control of a single party.

According to bug 1293454 this does happen on Mac.

I can still reproduce the problem on Beta50.b6, Aurora51.0a2 and Nightly52.0a1 Windows 10 if sync is enabled.

Happen to me on Mac El Captain and Sierra and Win 10, with sync on latest Firefox 50 (Mac) and 49.0.1 (Win).

This issue is reproducible on Version 53.0a1 Build ID 20161228030213 User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0

Mass wontfix for bugs affecting firefox 52.

(In reply to Julien Cristau [:jcristau] from comment #67) > Mass wontfix for bugs affecting firefox 52. Sorry????????? You come here and you close a 6 years old (and still valid) bugreport without a shred of explanation. We will not accept such behaviour, this is an insult to all people who contribute sending bugreports and helping the debugging process.

(In reply to Germano Massullo from comment #68) > (In reply to Julien Cristau [:jcristau] from comment #67) > > Mass wontfix for bugs affecting firefox 52. > > Sorry????????? > You come here and you close a 6 years old (and still valid) bugreport > without a shred of explanation. > We will not accept such behaviour, this is an insult to all people who > contribute sending bugreports and helping the debugging process. Oh damn my fault. I have not got that it was Firefox 52 related only. I am not used to such "release-targeted won't fix" Peace

Since about Firefox 54 b9, this nolonger happens. Thank you whoever fixed this bug.

(In reply to Michael Ahumibe from comment #70) > Since about Firefox 54 b9, this nolonger happens. Thank you whoever fixed > this bug. I can still reproduce some weirdness here, so I don't think it is fully fixed - but the good news is that we are working on bug 1210296, which we expect to resolve all strangeness.

We've removed most nested event loop spinning and I'm fairly sure we aren't spinning when this bug occurs. This is a bad experience for sync users, so I'm re-nominating for triage.

This is now working. We can't identify *exactly* what fixed it (so I'm not resolving it as a dupe), but we are confident that bug 1007448 played a big part and that bug 1448184 had some final impact.