When I use the Search->Find Again function and the text has many matches, I hold down the Alt+G keys to go through the known ones. It works as expected, but after hitting the last match a lot of "The text you entered was not found" pops up, instead of exactly one. Then I have to hit Esc many times to dismiss them. In addition when there are more than two of these boxes, I can only click the OK button in the right order, otherwise the button doesn't press. The Enter/Esc/Space/etc keys work in any order... It can be reproduced with either a high keyboard repeating rate, or giving back the focus to the main browser window after the first box appears, then pressing the Alt+G keys again, click inside the main window, press Alt+G again...

Confirming 2001070206/Linux and moving to XP Apps. Another way to say this is that "Find Again" shouldn't pop up a new alert if one is already open.

Yes, of course, but the original report contains additional information: there may be another bug in the messagebox creation, because of that unclickable OK buttons. I hoped that anybody less lame than me can report that bug correctly.

->danm, could this be a dup of bug 60150?

I don't think so. It may be lightly related, but they are talking about JS code execution halting. This seems simpler, than that bug, they could be only related by the "sub-bug", but this only affects mouse handling, as the boxes can be dismissed easily with the keyboard. (I don't want to look smarter than anybody else, but I think this helps danm decide.)

Ah, I misread the bug somewhat. This bug is about holding down Alt-G (Find Again) and it executing multiple times, resulting in lots of 'not found' dialogs. That would make it a dup of bug 71074. I was confused, because something similar happens when you have the Find dialog up, and you hit the 'Find' button lots of times in quick succession; then, you can also get multiple 'Not found' dialogs up. That is bug 60150.

okay, marking this a dup of 71074... *** This bug has been marked as a duplicate of 71074 ***

I don't think its a dup of bug 71074. Fixing that could help fixing one third of this, fixing that in a general way, could fix two thirds of this only. Just read the last line of my original report, and it seems clear, that bug 71074 is currently only about keyboard issues (its summary is "Commands should fire on key down, not keypress"), but this is more broad. Either extend that bug like I proposed in my comment, or threat them as separate. It would be a dup, if it could be only triggered by continously pressing Alt+G, but it pops up windows for pressing and releasing, giving back focus to main window with mouse, then pressing the key again... And after doing this several times, I now have some windows, where if I don't click the OK buttons in the right order, the buttons are unresponsive to mousedown, while they can be hold depressed by pressing Space. Please open another bug for this, if it doesn't belong here.

This is a problem only on linux. The "not found" alert is modal; that's sufficient for other platforms to stop the extra ^G madness after the first alert. Quelle surprise, this bug goes away if you apply the patch in bug 65521, which is about modal windows, their relationship to their parent window, and event handling. Marking dependent, and hoping Chris can soon come up with his planned replacement patch for that bug.

"This is a problem only on linux." Really? Are you sure it's not just a problem the first time the Find window is shown in a session (when bringing up the window is asynchronous)?

Alright to be honest I only tried it on windows and linux. I assumed it would work on the Mac because it looked like a modality event problem and because the Mac has such thoroughly modal windows. But I just tried it on the Mac and it brought me down and slapped me mercilessly. Merely unplugging it wasn't good enough to get it to boot; I had to walk away for a minute, too. Guess there's a problem on the Mac, after all. Yow. Windows is good, though.

mass moving open bugs pertaining to find in page/frame to pmac@netscape.com as qa contact. to find all bugspam pertaining to this, set your search string to "AppleSpongeCakeWithCaramelFrosting".

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

Seems fixed in 1.0RC2 (Build ID: 2002051009) on Linux

Changing target milestone to 'Future' since these seem to have missed the 1.2 alpha. If you are still considering a fix for 1.2 please re-target accordingly.

Well, all:all since mac:macosx and pc:linux cover the range. On Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040108 I got one dialog, but dismissing the dialog gave me the dialog again (and again ...) see bug 71074 comment 40 and bug 71074 comment 41 unfortunately, that proposal fails the expected behavior for ctrl-n

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420