occasionally lose caret in text fields and url bar, occasionally lose the ability to type in text fiends (after cocoa widgets enabled) I don't have a reproducable test case yet, but I have seen this come and go in various browser windows (in the url bar) and within html text areas.

for the problem with entering text, see bug #354746 for this bug, I lose the caret but I can still type. fwiw, the selection highlight appears to come and go as well. (meaning, when the caret is gone, if I do "cmd a" to select all, the text does not appear selected, but it is.)

Is there a reason you're not filing all these cocoa regression bugs in Core::Widget: Cocoa?

> for the problem with entering text, see bug #354746 sorry, I meant bug #354751 > Is there a reason you're not filing all these cocoa regression bugs in Core::Widget: Cocoa? no good reason. I'll switch them over.

about this bug, when I see it, when I type (and nothing shows up) the mouse cursor goes from pointer to nothing on every key stroke. to get out of the situation, opening a new window (like the error console) seems to help.

switching to another application (like iChat) and back also seems to help. am I the only one see this?

I think I've seen the behavior where the caret goes away, but you can still type. Do you have any reproducible steps?

(In reply to comment #4) > to get out of the situation, opening a new window (like the error console) > seems to help. FWIW, a lot of problems that are solved by switching away from the problematic window and back are caused by 'focus suppression' going awry. Switching to a window cancels all focus suppression (due to the NS_ACTIVATE that is sent). I'm not sure if that's related here, though.

STEPS TO REPRODUCE 1. Start Firefox 1.5.0.7 2. Quit Firefox 1.5.0.7 (Cmd+Q) 3. Start Minefield (notice the update check and that the window has two "Minefield Start Page" tabs). 4. Click on the yellow button on the window title bar (Minimize) 5. Click on a window of some other application 6. Click the minimized Minefield icon (Open) (notice a quick flash of the page before the window is fully restored) 7. Click in a text field and type some text => text is entered, but no caret This is 100% reproducible for me. NOTE: if you skip step 5 the window won't restore in step 6, which is also a bug (most likely all the noted oddities have the same underlying cause).

(In reply to comment #8) > STEPS TO REPRODUCE > 1. Start Firefox 1.5.0.7 Note that this bug only regards cocoa widgets, and therefore only trunk. However, maybe your steps are also valid on trunk?

(In reply to comment #9) > (In reply to comment #8) > > STEPS TO REPRODUCE > > 1. Start Firefox 1.5.0.7 > > Note that this bug only regards cocoa widgets, and therefore only trunk. > However, maybe your steps are also valid on trunk? Note that his third step is to start Minefield; the fire up older version step is just to force the you've-updated-firefox set of tabs to appear.

Upping severity, this is really painful dogfood.

note, I'm seeing this with my cocoa cairo debug build from Mon Nov 20 13:06:25 PST 2006 at the same time that I am seeing bug #360032 with the same build.

note, I'm still seeing this with recent trunk, debug builds.

fwiw, I really seem to be hitting this with my Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a3pre) Gecko/20070208 Minefield/3.0a3pre build

I also see this. Something else interesting to add to the mix. I often see this when switching to minefield and triple-clicking the url bar to select it all. Nothing appears to happen. I then click the desktop, then click back on minefield and lo and behold the text in the url bar is all selected like I wanted.

I believe this bug is fixed by the patch in bug 376811.

(In reply to comment #17) > I believe this bug is fixed by the patch in bug 376811. > Sadly this does not appear to be the case. I think it might have helped but I definitely just hit this bug again.

fwiw, just saw this again with my own trunk debug build: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a5pre) Gecko/20070502 Minefield/3.0a5pre note, when I see this bug, I see bug #360032 as well

I just saw this with the latest trunk. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a5pre) Gecko/20070531 Minefield/3.0a5pre ID:2007053105 Clicked in the URL bar, couldn't see the caret but could add/remove text. Clicked away from Minefield and the caret started flashing.

Note bug 383579, which has a later regression range than this bug, but had a reproducible way to cause the "can't type in text field" effect, but not the other symptoms of this bug (missing caret but can type, etc.). It seems to have been fixed with the recent move to libxul, though.

Possibly some extra info. I've experienced this bug happening where Firefox is still receiving inpiut from the keyboard, it just never enters into a textbox. Specifically hitting "/" brings up the find bar just fine, but typeing doesnt enter any text into it.

On a the nightly build from 20070615, I can get a 10-20% success rate of hitting this focus issue by.. 1) Load a url from the location bar 2) Immediately switch to another app (cmd-tab) before the page starts loading 3) Switch back to the browser after 1-2 seconds 4) Hit cmd-L and the location bar might not focus I would suggest "merging" step 1 and 2 by doing.. "mozilla" cmd-enter + tab. I've had a 0% success rate for the 20070620 build. And the 20070610 build sometimes results in a crash if I do this many times (hit the focus bug, click the page, switch apps and back, regain focus with cmd-L, repeat).

I think my most common way that I reproduce this (and even then its not guaranteed) is when I have another app focused then I immediately triple click in the location bar. If you hit the bug then nothing gets selected and you have to refocus the window. You can just focus another firefox window and it will solve it.

This usually happens for me if I switch from one tab that's loading to another tab, then try click in an edit field.

I notice this most often when I hit apple-T to open a new tab. It may also be related to using fast-find a lot. But a couple minutes of playing around didn't help me reproduce it reliably :-(

Well, this might be helpful: I never use fast-find, and it still happens to me.

When I trigger the bug with steps from #c23, fast-find will only show the last character typed if accessibility.typeaheadfind = true. (Pressing / brings up the find bar, but typing shows nothing.) So it might not be causing the bug, but if you run into a fast-find only showing a single character, you've likely run into this bug. Also, step 1 of #c23 can be replaced by choosing an entry from the location bar autocomplete (start typing and press down OR clicking the down arrow). The number of tabs don't seem to affect much - I can get this to happen on multiple tabs as well as a single tab.

This is not the fix that fixes this bug, but it clarifies a lot of our focus code and is more efficient in some cases. The main thing is a smaller and more fine-grained internal API for sending focus events.

This fixes the bug but I'm not comfortable requesting review yet as I think this may regress things elsewhere, particularly with embedding.

Josh, I don't know if this matters, but you changed the firing order of the DEACTIVATE and LOSTFOCUS events.

I can reproduce this bug 30%-50% of the time following Edwards's procedure from comment #23 and using an old Minefield nightly of about the same vintage as Edward used (I used the 2007-06-18-04-trunk nightly). But I can't reproduce it at all in recent nightlies (today's and yesterday's), or in my own debug builds (using source pulled from CVS yesterday morning). Can anyone else reproduce this bug in current nightlies or debug builds? Has this problem become WFM?

I hit it a few times yesterday from an hourly I had gotten in the morning.

metoo. *Maybe* the frequency has dropped a bit, since I seem to be bitter and resigned instead of enraged, but it ain't gone.

I can now reproduce this bug pretty reliably, but only on Minefield builds with the debug flag set (--enable-debug) and optimization completely disabled (--disable-optimize). I use the following procedure that Josh gave me: 1. Open a browser window, make it the key window 2. hit apple-L to select all text in the URL bar 3. type "mozilla" 4. hit enter 5. hit apple-tab 6. hit apple-tab again, slightly varying the timing of this step but usually I do it immediately after the URL bar switches to "http://www.mozilla.com/" from "mozilla" 7. go back to step 2 (if step 2 doesn't work, you've hit the bug).

When I see this bug, I also often see the following assertion: ASSERTION: win is null. this happens [often on xlib builds]. see bug #79213: (This happens in nsEventStateManager::PreHandleEvent() (in content/events/src/nsEventStateManager.cpp), while processing an NS_ACTIVATE event. Just prior to the assertion, a call to nsDocument::GetWindow() fails because mDocument currently has no "script global object".) But this doesn't happen all the time. Generally I see it only if I perform step 6 (in comment #36's procedure) very quickly after step 5. If I wait a few seconds between steps 5 and 6, I generally still see the bug, but not the "win is null" assertion. In both cases, though, a call is made to [ChildView viewsWindowDidBecomeKey:] (in widget/src/cocoa/nsChildView.mm) from [TopLevelWindowData windowBecameKey:] (in widget/src/cocoa/nsWindowMap.mm). When I added NSLog statements to viewsWindowDidBecomeKey:, I found that the currently focused view (the browser window's "first responder") fills the window's entire "content region". So it appears that (in this case) viewsWindowDidBecomeKey: dispatches NS_GOTFOCUS and NS_ACTIVATE events to the "wrong" Gecko nsView (the one corresponding to the native NSView object that fills the browser window's entire content region). But when I tried the same procedure in a debugging (and totally non-optimized) version of Camino (where I never see this bug), [ChildView viewsWindowDidBecomeKey:] dispatched NS_GOTFOCUS and NS_ACTIVATE events to exactly the same object, without any ill effects. I suspect some kind of DOM bug ... but I don't know enough about DOM code to track it down. And in any case Josh's patch does work around the problem. In my next message I'll post an alternative patch that also works around the problem, and doesn't (I think) alter Camino's behavior.

Here's a patch that's simpler than Josh's attachment 275124 [details] [diff] [review], and which (I think) doesn't change Camino's behavior. (I assume that Camino's browser windows (NSWindow objects) never have a delegate that responds to sendFocusEvent:, and that other Mozilla.org browsers (those that use Cocoa widgets) always do.) It also fixes this bug ... at least in my tests.

> (I assume that Camino's browser windows (NSWindow objects) never > have a delegate that responds to sendFocusEvent:, and that other > Mozilla.org browsers (those that use Cocoa widgets) always do.) I've confirmed this is is true ... but it's not for the reasons I expected. I expected that Camino would (at least for top-level windows) call nsCocoaWindow::StandardCreate() with aNativeWindow set (something that Cocoa widgets never does). But Camino (current trunk code) appears never to call nsCocoaWindow::StandardCreate() at all (even for windows of type eWindowType_popup).

Comment on attachment 277408 [details] [diff] [review] Alternate fix that doesn't change Camino's behavior >diff -U 10 -r src.old/widget/src/cocoa/nsWindowMap.mm src/widget/src/cocoa/nsWindowMap.mm >--- src.old/widget/src/cocoa/nsWindowMap.mm 2007-08-02 18:01:32.000000000 -0500 >+++ src/widget/src/cocoa/nsWindowMap.mm 2007-08-20 10:50:08.000000000 -0500 >@@ -136,46 +136,42 @@ > > - (void)windowBecameKey:(NSNotification*)inNotification > { > NSWindow* window = (NSWindow*)[inNotification object]; >- id firstResponder = [window firstResponder]; >- if ([firstResponder isKindOfClass:[ChildView class]]) { >- [firstResponder viewsWindowDidBecomeKey]; >- } >- else { >- id delegate = [window delegate]; >- if ([delegate respondsToSelector:@selector(sendFocusEvent:)]) { >- [delegate sendFocusEvent:NS_GOTFOCUS]; >- [delegate sendFocusEvent:NS_ACTIVATE]; >- } >+ id delegate = [window delegate]; >+ if (delegate && [delegate respondsToSelector:@selector(sendFocusEvent:)]) { >+ [delegate sendFocusEvent:NS_GOTFOCUS]; >+ [delegate sendFocusEvent:NS_ACTIVATE]; >+ } else { >+ id firstResponder = [window firstResponder]; >+ if ([firstResponder isKindOfClass:[ChildView class]]) >+ [firstResponder viewsWindowDidBecomeKey]; > } > } So it seems like the impact of this change is to preferentially send the focus and activate events via the nsCocoaWindow, rather than the focussed view. Is it understood how this fixes the focus issue?

> So it seems like the impact of this change is to preferentially send > the focus and activate events via the nsCocoaWindow, rather than the > focussed view. Yes. > Is it understood how this fixes the focus issue? No ... though I suspect it's a Gecko issue, and not a Mac one (see comment #37). Can you think of someone who knows enough about Gecko events (DOM events) and Gecko objects (widgets) to pass judgment on this issue?

Perhaps Olli Pettay (smaug) knows that kind of event stuff well enough to help.

This is a stack trace from a hang encountered while running with the proposed patch (attachment 277408 [details] [diff] [review]). This was after an intensive browsing session with several windows and many tabs. I did not encounter the "focus bug" during any time while working with the build.

This one has all threads in it, in case this is a deadlock issue.

I suspect the hang is unrelated to the patch. Another hang in pthread_equal is reported at bug 366486, with a similar looking stack.

Could both hangs have occurred at the same URL? If so please try to find out what it was, and report it here.

> Could both hangs have occurred at the same URL? I mean both of your hangs (if there've been more than one).

Comment on attachment 277408 [details] [diff] [review] Alternate fix that doesn't change Camino's behavior Simon - canceling review from you, but if you care to give any more feedback it would be much appreciated!

jag - about comment #32, Windows and GTK2 impls disagree about whether NS_LOSTFOCUS should come before or after NS_DEACTIVATE. I switched to the GTK2 way because it seems to make a little more sense. I doubt it matters much though, the only thing NS_LOSTFOCUS seems to do is turn off the blinking caret (see nsEventStateManager).

Comment on attachment 277408 [details] [diff] [review] Alternate fix that doesn't change Camino's behavior I just noticed wierdness testing this patch in an optimized build of Minefield :-( It should probably be fixed before it undergoes further review. Everything was fine with just one browser window. But if you open two, put keyboard focus in each window into a textfield, and start switching between the windows (and the textfields), you start to see the I-bar cursor blinking in more than one location (though the keyboard focus is itself only ever in one location). I'll be working on this.

> Everything was fine with just one browser window. Actually now I see similar problems with just one browser window, after switching away from Minefield and back again.

Not to say anything one way or the other about the patch itself, but I have been seeing multiple-caret situations since time immemorial, well before Fx2.

(In reply to comment #47) > > Could both hangs have occurred at the same URL? > > I mean both of your hangs (if there've been more than one). > Both of mine occurred when doing the following: open a new tab Do a Google search from search bar Click on a link I used different searches and different links in both cases. I cannot reproduce the hang issue with the current nightly (2007082404). But, like you, I don't think that's necessarily indicating that the hang is the fault of the patch.

(In reply to comment #52) The ones I saw are _really_ easy to reproduce. And I think I have a simple fix -- just drop my patch's changes to TopLevelWindowData windowResignedKey: (leaving only the changes to TopLevelWindowData windowBecameKey:). I tried this out in my optimized build -- it worked fine. Now I'm preparing to try it out in my debug (totally non-optimized) build -- to see if it still prevents the original problem.

Here's a revised "alternate patch" that still doesn't change Camino's behavior, but which does fix the original problem and gets rid of the extra I-bar cursors (at least in my tests). Please test this, Clint (and Josh too, if you have time). I dropped my changes to TopLevelWindowData windowResignedKey: (as I said I would). But I found I needed still more changes to completely get rid of the extra I-bar cursors. I ended up (on Minefield) sending the NS_GOTFOCUS/NS_ACTIVATE message pair twice -- once to the nsCocoaWindow Gecko object corresponding to the browser window, and then (a second time) to the nsChildView object corresponding to the ChildView/NSView object that is the browser window's "first responder" (which, interestingly, is still the "wrong" object that I talked about in comment #37). (I find it easiest to reproduce the multiple I-bar cursor problem on the Minefield home page: Click back and forth between the "search mozilla" text box and the Google search box (just to the right of the location bar). Leave the keyboard focus in the Google search box. Then switch to the Finder (or another app) and back again to Minefield -- often the I-bar cursor will stay blinking even when Minefield is no longer active. Then when you make Minefield active again, it will be easy to make the I-bar cursor appear in more than one text field at a time.) (With this patch I once again sometimes see the "win is null" assertion that I talked about in comment #37 (and under the same circumstances). Now, though, I no longer at step 2 in Josh's procedure from comment #36.) I still don't really know why my patch works. I'd really appreciate comments from someone who knows enough about DOM events to come up with a possible explanation why it does work. Smaug?

Comment on attachment 278151 [details] [diff] [review] Alt fix rev2 (gets rid of extra I-bar cursors) Josh, I'm requesting a review from you on general principles. But my patch might change again if/when I get advice from someone who knows more about DOM events than I do (or if more tests show up further problems).

(In reply to comment #55) > I still don't really know why my patch works. I'd really appreciate > comments from someone who knows enough about DOM events to come up > with a possible explanation why it does work. > > Smaug? > This isn't really a DOM event problem, but (gecko) event handling, or widget handling. So can't help much here (and I don't have a mac to test anything). One thing I noticed that cocoa code seems to pretty much always dispatch NS_ACTIVATE right after NS_GOTFOCUS. That is not what is done in gtk2/linux. There dispatching NS_ACTIVATE depends on nsWindow::mActivatePending, which is set only if mIsTopLevel is PR_TRUE. And just to remind that NS_GOTFOCUS causes DOM events to be dispatched, so after the dispatch "everything" may be teared down. In Gtk2 NS_GOTFOCUS is dispatched also to other kinds of widgets than just eWindowType_toplevel. Not sure how those widgets map to cocoa NSWindow/ChildView (not familiar with mac code at all). (Btw, in gtk2 export NSPR_LOG_MODULES=WidgetFocus:5 helps with focus debugging.)

Here's another revision of my "alternate patch" that gets rid of the "win is null" assertion -- by no longer dispatching the second NS_ACTIVATE event (which in any case seems superfluous). (In reply to comment #57) Thanks, Smaug, for your comments. I'll work through them on Monday, and possibly post yet another revision to my patch. (I'll also do some more testing on Monday.)

As promised here are repro steps that are way easier and 100% reliable. This should make debugging much easier. 1. Save this HTML file to your desktop 2. Open Minefield 3. Drag the HTML file from your desktop into a Minefield window's content area 4. Try to type in either field, you can't This works every time for me. The only circumstance under which it will not work is if you already have the file loaded in the content area when you drag it in, in which case the page doesn't really refresh. You have to drag it into a content area that has some other page loaded.

Thanks, Josh! Your new procedure (like the old one) only works for me on fully non-optimized debug builds. And it generally only works the first time I try it (I have to restart the browser between attemps). But within those constraints it also works for me close to 100% of the time. Interestingly, it still works (though possibly a bit less often) even if I reduce the *.html file to the barest minimum: <html> </html> Also, I now see the "win is null" assertion every time I see the focus problem (whether I use Josh's new or old procedure). Previously I only saw it some of the time (see comment #37). I suspect this may be due to changes elsewhere that have happened in the meantime ... though I have no idea what these changes might have been. (I'm now working with code I pulled from CVS Tuesday morning 2007-08-28.)

Here's a slightly revised version of my "alternate patch", with comments that indicate why I've done things the way I have. I still don't fully understand why my patch works ... but I'm a lot closer to that goal than I was before. In any case, I found good reasons to change the previous behavior (besides the fact that my changes fix this bug). My comments are based on intensive debugging (I logged wherever any of these focus events were processed anywhere in the Mozilla tree). I also did quite a bit of testing -- enough to be pretty sure that my patch doesn't introduce any focus-specific problems. As with my previous "alternate" patches, I haven't made any change to Camino's behavior. Since Camino doesn't seem to have focus problems like those described here, this seems appropriate.

+// For some reason sending +// NS_LOSTFOCUS events to top-level widgets has no effect (these events +// never come through nsWebShellWindow::HandleEvent() or +// nsEventStateManager::PreHandleEvent()), but on general principles we +// send them anyway. Before I land the patch I'll change this comment as follows: // Sending NS_LOSTFOCUS events to top-level widgets currently has no // effect (nsWebShellWindow::HandleEvent(), which processes focus events // sent to top-level widgets, doesn't have a section for NS_LOSTFOCUS). // But on general principles we send them anyway.

Patch (attachment 279037 [details] [diff] [review] with revised comments) landed on trunk.

I think I have a pretty reliable testcase to exhibit this bug. 0. Make sure you have Flash installed and enabled 1. Clear cookies 2. Load http://www.abc.com 3. Click on "Primetime" 4. On the bottom left, click on "Lost" -- This should launch at least one popunder (even with popup blocking enabled, which it is by default). If it doesn't, clear cookies, and keep repeating steps 1-4 until you get a popunder 5. Now, Command T and try typing in the location bar You won't be able to... Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007091304 Minefield/3.0a8pre

OK, sorry for the additional spam, but one more datapoint to increase the likelihood of reproducing this bug: It appears that it's triggered (exclusively?) when the popunder is Flash-based; there is a Netflix popunder (http://c1.zedo.com/jsc/c1/ff2.html?n=162;c=1159;s=175;d=16;w=720;h=300;t=UndertoneNetworks.com-Advertisement) that, when displayed, triggers this 100%. (Keep trying _all_ of the steps until you've hit the Netflix.com popunder, and you should see the bug.)

I think I found another way to reproduce this bug too. Using a debug build (timing matters here), if I launch and then hit command-n about 10 times really quickly to open ten window really quickly, then hit command-l to focus the URL bar, this bug shows up.

(In reply to comment #64) Even if I skip steps 4 and 5 I can reproduce the problem 100% of the time ... at least for now (with the Minefield 2007-09-10-04 nightly). It seems to be the popunder that triggers the problem. I suspect any popunder would do. Anyone know of other examples? Sigh. I can't type in any text field (either in the original browser window or the pupunder) until I click somewhere in the popunder and then somewhere in the original window.

Using a similar approach to bug 383579 comment 0 (which itself is no longer reproducible in official nightlies), I can cause a caret loss / breakage of text fields by simply doing the following: 1. Open two browser windows, both visible 2. Type www.google.com in the location bar of window 1, but don't hit return just yet 3. Mouse over the location bar of window 2, but don't click on it (focus still in window 1 location bar) 4. Hit return, so that the page will start to load, but immediately click on the location bar (or some other field) of window 2, leave the focus there 5. When the Google search page loads in window 1, the caret will vanish from window 2 6. Try to type in window 2. You can't. No caret, no typing. Clicking on the location bar does nothing. It looks like the simple focus() call from the Google page can steal the focus from other Firefox windows (including non-browser windows, like the Error Console). When it does that, it seems to temporarily break text field usage in those windows (focus elsewhere and back again fixes it). However this regression occurred between the 20070621 and 20070622 trunk nightlies, which is much later than the first symptoms of this reported bug. Maybe it's related and it'll help, though. If nothing else, it's a warning that there may be more than one focus bug which can confuse matters. I won't have time for a couple of days to try to figure out why or what the culprit is, but I hope it helps.

I seem to see more focus issues when I running Leopard. I will try to pay attention to times when I am seeing them and document STR, but it seems I have to click in and out of the Minefield app more on Leopard than I ever notice on Tiger.

adding relnote keyword for b1.

I'm no longer able to reliably reproduce any of the problems reported here (the site mentioned in comment #64 has changed, and no longer triggers a popunder). But I've posted a patch at bug 403232 (attachment 290742 [details] [diff] [review]) that fixes a number of reproducible focus bugs (bug 399471, bug 403232 and bug 404433). Here's a tryserver build (of Minefield) made using that patch. If you're still seeing focus problems, please try it out and let us know your results. https://build.mozilla.org/tryserver-builds/2007-11-29_13:05-smichaud@pobox.com-focus/

> I'm no longer able to reliably reproduce any of the problems reported here fwiw, I haven't see this bug is a long time, either.

I don't see it often, but I just saw it :-(

I still see this quite often in CZ.

(In reply to comment #73 and comment #74) Try my patch! :-)

I've been seeing it a lot when doing cmd + T for a new tab. I have to cmd + tab away and then back again.

SethB is also seeing this with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007113004 Minefield/3.0b2pre on mail.zimbra.com I'm not sure if he has reproducible steps, but he sees it when replying to messages and then attempting to type in the addressing fields. It appears to be the same bug as this one, as the workaround is to switch focus between firefox and another application. sethb: if you can come up with reproducible steps, can you list them here? I know that steven is looking for them.

Trying to reproduce. Will post steps if I can get them.

I'd wait until the patch in bug 403232 goes in before trying to get another set of steps to reproduce.

The very small number of reproducible OS X focus bugs has just increased by one -- see bug 408266. Like all the others that I'm aware of, that one is also fixed by my patch for bug 304232.

> by my patch for bug 304232. Oops ... by my patch for bug 403232.

My patch for bug 403232 has just landed, so I'm marking this bug fixed. If someone finds a _reproducible_ focus bug that more-or-less matches the others in this bug, please re-open it.

(In reply to comment #82) > If someone finds a _reproducible_ focus bug that more-or-less matches > the others in this bug, please re-open it. Unless your patch was unsound and backed out (or likely to be, unless quickly fixed), it's almost always better to file a new bug. One bug per patch that landed gives everyone clear audit trails. /be

I agree! This bug is already an unholy mess. New focus bugs should be reported elsewhere, separately. Likewise for any regressions caused by my patch -- and those should be made to depend on bug 403232 (where the patch was landed).

(Following up comment #82) The first time I landed a patch for bug 403232, I had to back it out because of Mochitest failures. I've just landed another version of the patch, which had no problems.