Closed Bug 7146 Opened 26 years ago Closed 25 years ago

the find dialog appears in the list of running apps

Categories

(Core Graveyard :: Tracking, defect, P2)

x86
Windows NT

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cpratt, Assigned: law)

References

Details

build id: 1999052517 platform: windows nt to reproduce: - launch apprunner - select Find On this page… from the Search menu - press Alt+Tab. Note that the Find window shows up in the list that is displayed of currently running applications. Expected result: only one seamonkey whatsit is shown in this list, and it should be titled 'Find'.
Assignee: don → davidm
Priority: P3 → P2
Target Milestone: M7
David, work with Bill and find out what's going on here ...
Assignee: davidm → law
I am assiging to bill since this is a windows issue. Since it also happens in 4.5 ( multiple windows for the same app show up in the task list ), I am not sure what the bug really is.
QA Contact: leger → cpratt
Behavior is different in 5 than in 4.6. In 4.6, each browser window shows up in the list of running applications. If you open a Find dialog - which is a child of a browser window - then the instance of its parent is replaced by the Find dialog in the applications list. However, in 5, you then get 2 - not 1 - things in the list of open apps. One would expect behavior to be the same as 4.6.
Status: NEW → ASSIGNED
Target Milestone: M7 → M8
This requires some underlying code to enable opening windows with various "styles" (to use the Windows terminology). This won't happen till at least M8, so I'm adjusting the target milestone accordingly.
Moving all Apprunner bugs past and present to Other component temporarily whilst don and I set correct component. Apprunner component will be deleted/retired shortly.
Depends on: 9327
Target Milestone: M8 → M9
I'm marking this as dependent on #9327 (and deferring till M9).
Depends on: 9631
No longer depends on: 9327
Depends on: 9327
This got lumped in with other similar native chrome-y things (min/max/resizable) but then slipped through the cracks, it appears. I'll re-escalate the issue and see about getting a fix (in M10).
Target Milestone: M9 → M10
Target Milestone: M11 → M13
Moving to M13 'cause we've got bigger fish to fry.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
dependent=yes does the trick (see bug 9327 or 9631). Fix checked in.
Status: RESOLVED → VERIFIED
Does what it should in the 19991110508 build under NT. Verified fixed.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.