User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729) How I get this bug- I am trying to edit a bookmark by clicking on the book icon in the address bar of Firefox.A "Edit this bookmark" dialogue box then opens under the address bar. I then click on the "+" sign to expand this dialogue box to include the "New Folder" button. I click on the "New Folder" button and a new folder appears in the expanded menu as it should with the New Folder text highlighted and ready for your input to change. This is where the bug happens. I start entering a new folder name and the characters will not appear changed in the dialogue box for at least 20 seconds after I am done typing. I can speed this up by taking my mouse pointer and moving it back and forth inside the dialogue box but even with this strange step it requires a second or two for the text to change. Reproducible: Always Steps to Reproduce: 1.See details above. 2. 3. Expected Results: Highlighted text should change with new keystrokes.

I have since discovered that this issue does not happen when using the default Firefox theme. This issue is occurring when I use the "Walnut for Firefox 1.8.48". I apologize for not catching this before initially posting this bug.

please contact the theme author, this is not a Firefox bug. Thanks

This *is* a firefox bug (or more precisely toolkit/core). The problem does occur in FF3.0.8, but NOT in the current FF3.5b4pre. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090419 Shiretoko/3.5b4pre GTB5 (.NET CLR 3.5.30729). As bug 413053 that changed this part of this panel, I am going to mark this bug fixed by that bug. So, anyone facing this bug please switch to FF3.5b4pre (or wait for FF3.5).

Are you saying the hang happens on default theme? since bug confirmation rules are usually based on default theme and no add-ons.

It is not happening in the default theme, but that doesn't mean that bug cannot be caused be something in the toolkit code. Like some internet pages work in Firefox (particularily the mozilla.org pages), but if some non mozilla page crashes in Firefox it is not the blame of that page but of that browser. Same thing for themes. A theme is eseentially a bunch of CSS's and images, and no code what so ever. What the underlying issue here is that the update event triggered by typing is probably not handled fast enough by FF/toolkit/core/gecko to cause a correct redraw and then dropped. Overall, no worries, as the issue is fixed in 3.5/1.9.1.

This has definitely not been fixed by the checkin on 1.9.1 by bug 413053. The problem still persists with Shiretoko and build id 09031205. Another patch has fixed this problem. Marking WFM.

(In reply to comment #4) > Are you saying the hang happens on default theme? since bug confirmation rules > are usually based on default theme and no add-ons. The hang does not happen in the default theme.