Closed Bug 88827 Opened 23 years ago Closed 14 years ago

Find Again pops up many Not Found windows

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED
Milestone:
Future

People

(Reporter: bugs, Unassigned)

References

Details

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.
Assignee: alecf → blake
Status: UNCONFIRMED → NEW
Component: Keyboard Navigation → XP Apps: GUI Features
Ever confirmed: true
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?
Assignee: blake → danm
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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.
Depends on: 65521
Target Milestone: --- → mozilla0.9.7
"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.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → ---
Target Milestone: --- → mozilla0.9.9
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".
QA Contact: sairuh → pmac
Target Milestone: mozilla0.9.9 → mozilla1.0
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.
Target Milestone: mozilla1.0 → mozilla1.2
Keywords: mozilla1.0, nsbeta1
Keywords: nsbeta1 → nsbeta1-
Blocks: 70771
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.
Target Milestone: mozilla1.2alpha → Future
QA Contact: pmac → sairuh
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
OS: Linux → All
Hardware: PC → All
Product: Core → Mozilla Application Suite
Assignee: danm.moz → nobody
Status: REOPENED → NEW
Component: XP Apps: GUI Features → UI Design
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
Status: NEW → UNCONFIRMED
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
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.