Closed Bug 178173 Opened 23 years ago Closed 16 years ago

New window but no entry in task bar

Categories

(Core :: General, defect)

1.8 Branch
x86
Windows 2000
defect
Not set
major

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: 3.14, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(1 file)

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021016 When you go to http://www.minorityreport.com/ and press ENTER you get a new windows. It does not show up in the Windows task bar, nor is it accessible with ALT+TAB. It is visible only in the Windows menu. This is extremely confusing and closing a window might inexpectedly close all of them. One window is always in front. So all of this is a mojor usability problem. pi
Still here in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030114. pi
Attached file testcase
Note that this problem shows up on windows, but not on Linux. If you click on that bad link, a new window opens, completely covering the old one. By no means you can switch between the windows. You can only minimize the child to get to the parent. In the window menu you see both, but you cannot switch to the parent window. In the task bar only one shows up. pi
Keywords: testcase
Well that is the idea of a dependent window... not sure if content should be allowed to do this, though.
Neil, there are some major problems here: - There is no way to switch between windows, i.e., parent and dependent (minimizing all other windows on your desctop is not a real option). - Unintentionally closing the dependent window, which cannot be expected. - It behaves differently on Win and Linux. I don't think any of those effects should show up. pi
OK, but that's how the Find dialog works, and nobody's complained before ;-)
Well, the find window behaves differently (and this would also be the solution to this bug). The find window is always above the window to which it applies, keeping that one inactive. pi
Product: Core → Mozilla Application Suite
pi, still see this?
Assignee: samir_bugzilla → nobody
QA Contact: pawyskoczka → ui-design
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414] (release) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.12) Gecko/20070510 SeaMonkey/1.0.9] (release) (W2Ksp4) Bug still there. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.21) Gecko/20090403 SeaMonkey/1.1.16] (release) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20081212 Minefield/3.2a1pre] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090518 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4) Bug fixed: the new window is not 'dependent' anymore. (As if comment 3 was "fixed"! Unless you consider the new behavior to be a bug?) R.WorksForMe
Status: NEW → RESOLVED
Closed: 16 years ago
Component: UI Design → General
OS: Windows 98 → Windows 2000
Product: SeaMonkey → Core
QA Contact: ui-design → general
Resolution: --- → WORKSFORME
Version: Trunk → 1.8 Branch
I have never seen this situation anywhere else. The original site does not exist anymore. So be it.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: