Minh Reporter
	Description • 13 years ago

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.

	Minh Reporter
	Comment 1 • 13 years ago

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

	Marco Bonardo [:mak]
	Comment 3 • 13 years ago

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

	Marco Bonardo [:mak]
	Comment 4 • 13 years ago

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

	Richard Newman [:rnewman]
	Comment 5 • 13 years ago

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.

	Minh Reporter
	Comment 6 • 13 years ago

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.

	tideview
	Comment 7 • 13 years ago

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.

	Mihaela Velimiroviciu (:mihaelav)
	Comment 8 • 13 years ago

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)

	Verdi [:verdi] Best to slack me
	Comment 10 • 12 years ago

https://support.mozilla.org/en-US/questions/927710

	Richard Newman [:rnewman]
	Comment 11 • 12 years ago

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

	Robert
	Comment 13 • 12 years ago

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.

	rstanderregs
	Comment 14 • 12 years ago

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.

	ipcnt
	Comment 15 • 12 years ago

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?

	Richard Newman [:rnewman]
	Comment 16 • 12 years ago

(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.

	Marco Bonardo [:mak]
	Comment 18 • 12 years ago

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

	rsbrux
	Comment 22 • 12 years ago

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.

	blondius
	Comment 23 • 11 years ago

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.

	Richard Newman [:rnewman]
	Comment 25 • 11 years ago

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

	Jan Kozanek
	Comment 27 • 11 years ago

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.

	Jan Kozanek
	Comment 28 • 11 years ago

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.

	Richard Newman [:rnewman]
	Comment 29 • 11 years ago

(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.

	David Bourguignon
	Comment 30 • 11 years ago

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!

	Richard Newman [:rnewman]
	Comment 31 • 11 years ago

(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

	David Bourguignon
	Comment 32 • 11 years ago

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.

	Germano Massullo
	Comment 33 • 11 years ago

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

	Richard Newman [:rnewman]
	Comment 34 • 11 years ago

Reopening for Linux.

	Marco Bonardo [:mak]
	Comment 35 • 11 years ago

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.

	Richard Newman [:rnewman]
	Comment 36 • 11 years ago

(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.

	Jan Kozanek
	Comment 37 • 11 years ago

(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.

	Marc OKrent
	Comment 38 • 10 years ago

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.

	Germano Massullo
	Comment 39 • 10 years ago

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

	Mordecai
	Comment 40 • 10 years ago

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.

	:Gijs (he/him)
	Comment 44 • 10 years ago

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

	chihwahli
	Comment 45 • 10 years ago

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?

	Germano Massullo
	Comment 46 • 10 years ago

+1

	chihwahli
	Comment 47 • 10 years ago

Additional info:

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

	Mordecai
	Comment 48 • 10 years ago

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.

	Richard Newman [:rnewman]
	Comment 49 • 10 years ago

(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.

	chihwahli
	Comment 50 • 10 years ago

@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. =)

	Germano Massullo
	Comment 51 • 10 years ago

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....

	Marco Bonardo [:mak]
	Comment 52 • 10 years ago

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.

	Germano Massullo
	Comment 57 • 9 years ago

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

	rsbrux
	Comment 58 • 9 years ago

@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.

	Jan Kozanek
	Comment 59 • 9 years ago

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.

	rsbrux
	Comment 60 • 9 years ago

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.

	Dão Gottwald [:dao]
	Comment 63 • 8 years ago

According to bug 1293454 this does happen on Mac.

	Alice0775 White
	Comment 64 • 8 years ago

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

	Oleksii Naumov
	Comment 65 • 8 years ago

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

	Kanchan Kumari QA
	Comment 66 • 8 years ago

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

	Julien Cristau [:jcristau]
	Comment 67 • 7 years ago

Mass wontfix for bugs affecting firefox 52.

	Germano Massullo
	Comment 68 • 7 years ago

(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.

	Germano Massullo
	Comment 69 • 7 years ago

(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

	Michael Ahumibe
	Comment 70 • 7 years ago

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

	Mark Hammond [:markh] [:mhammond]
	Comment 71 • 7 years ago

(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.

	Mark Hammond [:markh] [:mhammond]
	Comment 77 • 6 years ago

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.

	Mark Hammond [:markh] [:mhammond]
	Comment 80 • 6 years ago

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.