Closed
Bug 8002
Opened 25 years ago
Closed 23 years ago
Tasks|Navigator opens a NEW Navigator window
Categories
(Core :: XUL, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
mozilla0.9.3
People
(Reporter: nbaca, Assigned: danm.moz)
References
Details
(Whiteboard: nsIWidget::Show needs to bring the window to the front on linux)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Build 1999060909M7 Win32/NT4, Linux, Mac 8.5
Problem:
In Messenger select Tasks/Navigator and a Navigator window opens.
Each time this step is repeated a NEW Navigator window appears. I
would have expected the application to switch to Navigator, not
create a new window.
In Navigator select Tasks/Messenger and a Messenger window opens.
Repeat this step and a NEW Messenger window appears.
> > > Is Bug# 2652 associated with this? If not, then I should log a bug
> > > but what Component should be chosen since Navigator and Messenger
> > > appear to have a similar problem?
Assignee: don → davidm
OS: Windows NT → All
Priority: P3 → P1
Target Milestone: M7
Summary: Tasks/Navigator opens a NEW Navigator window → Tasks|Navigator opens a NEW Navigator window
Until I am able to pass a nsIDOMWindow around there is no good solution to this
bug
Updated•25 years ago
|
Whiteboard: moving to m8?
Updated•25 years ago
|
Target Milestone: M7 → M8
Comment 5•25 years ago
|
||
moving to m8 after discussion with don
Comment 8•25 years ago
|
||
Selecting Navigator from the menu toggles to the open Nav window. Verified on
mac and win95 -- it is still broken on Linux.
Updated•25 years ago
|
Whiteboard: 07301999: still incorrect on Linux
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Updated•25 years ago
|
Resolution: FIXED → ---
Assignee: davidm → trudelle
Status: REOPENED → NEW
Component: XPApps → XP Toolkit/Widgets
Linux doesn't appear to bring the window to the front after a call to
window.focus(). I am guessing that gtk is not bring the window to the front
after a call to Show. Reassigning
Updated•25 years ago
|
Assignee: trudelle → pavlov
Priority: P1 → P3
Target Milestone: M9 → M10
Comment 10•25 years ago
|
||
reassigning to pavlov as p3 for m10, cc danm
Assignee | ||
Comment 11•25 years ago
|
||
The JS function window.focus() is supposed to bring the affected window to the front
and make it visible if it wasn't. Last time I checked, only Windows was doing this.
Personally, I think it's silly, but the spec insists, and all platforms should behave
the same way.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Whiteboard: 07301999: still incorrect on Linux → nsIWidget::Show needs to bring the window to the front on linux
Updated•25 years ago
|
Target Milestone: M10 → M11
Comment 12•25 years ago
|
||
mass-moving most m11 bugs to m12
Comment 13•25 years ago
|
||
Mass-moving non-PDT+ bugs to M13
Comment 14•25 years ago
|
||
this is a bit strange. if i make nsIWidget::Show() bring the window to the
front, the window gets brought to the front whenever you mouse in to the window
Updated•25 years ago
|
Target Milestone: M13 → M15
Comment 15•25 years ago
|
||
*** Bug 25740 has been marked as a duplicate of this bug. ***
Comment 16•25 years ago
|
||
*** Bug 32219 has been marked as a duplicate of this bug. ***
Comment 17•25 years ago
|
||
correcting the OS field. All the dupes are linux only and checking with 03/21 builds shows me that this is Linux only as well.
OS: All → Linux
Comment 18•25 years ago
|
||
Tasks|Navigator should open a new (or empty) navigator window.
Tasks|Mail should open new view of Inbox if there is no existing one.
My duplicate bug was complaining about the fact that the navigator window was
not raised at all.
The behaviour of netscape where it reuses browser windows from certain places
should be made optional (or completely removed).
Comment 20•25 years ago
|
||
Bug topic drift? From "Tasks->Messenger opens a new window instead of the open
one" to "JS window.focus() doesn't work on Linux" :-) And I'm going back.
What are the specs for the Tasks->* menu?
From Nav4.72's behaviour and what's implied in earlier comments, it seems to be
this:
if (the selected task is a different type than what's on top right now) {
if (there's no instance of the task) {
create one;
} else {
switch to the most on top for that task;
}
} else {
// the selected task is the same type as what's on top right now
if (it's of type navigator or editor) {
if (there's only one instance) { // inconsistent behaviour...
create a new instance;
} else {
switch to next instance in list, wrap if needed; // list ordered by Z?
}
} else {
// composer or addressbook, we can only have one instance; do nothing
}
}
There's a bug preventing this behaviour. To reproduce:
Start Mozilla
Tasks -> Navigator (opens a second Navigator window)
Tasks -> Navigator (switches back to the first)
Tasks -> Navigator (switches back to the second)
Tasks -> Navigator : we're stuck on the second.
Manually switching between from the second to the first and back and then Tasks
-> Navigator gives the same result.
Adding some tests in tasksOverlay.js:CycleWindow(...) revealed that (
firstWindow == topWindowOfType ) is true that last time when it shouldn't be.
This is because topWindowOfType is incorrect. The other thing that could be
incorrect is the next window after firstWindow in the enumeration list. In the
case of two windows this would mean the next window in that list and the first
were the same, but testing showed this wasn't the case.
Conclusion: getMostRecentWindow returns incorrect values sometimes.
Another clear hint that getMostRecentWindow sometimes returns an incorrect value
can be seen this way:
Start Mozilla
Tasks -> Mail
Tasks -> Navigator
Tasks -> Mail
Tasks -> Navigator : opens a new navigator window
This happens because (topWindowOfType != topWindow) is false that last time,
which is clearly wrong since the topWindow was Mail and
topWindowOfType(Navigator) was Navigator (duh). Testing shows topWindowOfType in
that case is the Navigator window, so topWindow is a Navigator window while it
should've been a Mail window.
P.S. is there some kind of window.getType() and window.getUniqueID() for JS? It
would've made the above tests a bit easier :-)
Comment 21•25 years ago
|
||
*** Bug 32700 has been marked as a duplicate of this bug. ***
Comment 22•25 years ago
|
||
The sensible behavior IMO:
Tasks|Navigator activates an empty navigator window (new or existing empty one)
Tasks|Mail activates the Inbox folder (opens a new Mail window if user is not
viewing the Inbox in the existing one).
Reusing windows is a bad (annoying) idea.
Comment 23•24 years ago
|
||
Attaching a patch which cleans up the CycleWindow() code to be a bit more
transparant (but no change in functionality). It also cleans up
toMessengerWindow(), hope you don't mind me smuggling that in with this ;-)
Comment 24•24 years ago
|
||
Comment 26•24 years ago
|
||
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Comment 27•24 years ago
|
||
Adding PATCH keyword for easier querying. If the clean up patch by Peter Annema
is good, it should be checked in before it got rotten in M21.
Nothing is more annoying than improving stuff senselessly.
Keywords: patch
Comment 28•24 years ago
|
||
I'll attach a new patch, these files have changed a bit since then.
Comment 29•24 years ago
|
||
That's exactly why patches, when looking good, should be checked in as soon as
possible. Sorry for the spam, just had to get rid of it...
Comment 30•24 years ago
|
||
Comment 31•24 years ago
|
||
The first patch did some more cleaning up, but most of that's been done in
one way or another in the mean time, so it's just for CycleWindow now.
Comment 32•24 years ago
|
||
BenGoodger checked this patch in.
Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Comment 33•24 years ago
|
||
Whoops, wrong bug... Reopening. Apologies for the spam.
BenGoodger did check in the clean-up patch though.
There still seems to be a problem somewhere with the Z-ordering of Moz's
windows, making |getMostRecentWindow(windowType)| return incorrect values.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•24 years ago
|
Target Milestone: M21 → Future
Comment 34•24 years ago
|
||
Only switched to Nav window once out of many tries for me today, usually does
nothing.
Comment 35•24 years ago
|
||
See bug 20306 for more discussion about whether reusing windows for Ctrl+1,
Tasks|Navigator, and the Navigator "taskbar" button makes sense or not.
Comment 37•24 years ago
|
||
*** Bug 65729 has been marked as a duplicate of this bug. ***
Comment 38•24 years ago
|
||
Removing patch keyword, as the attached patch has been checked in.
Gerv
Keywords: patch
Comment 39•24 years ago
|
||
*** Bug 71343 has been marked as a duplicate of this bug. ***
Comment 40•24 years ago
|
||
Does this bug cover Tasks|Navigator from any window or from any window other
than a browser window?
Comment 41•24 years ago
|
||
Jesse,
It would have to be from any window other than a navigator window b/c the expected behavior
from a navigator window is to produce a new navigator window, whereas from any other app the
expected behavior is to raise the existing navigator window and create one iff there isn't already
one.
Comment 42•23 years ago
|
||
over to xptoolkit.. maybe danm or dr can take a look at this?
Assignee: pavlov → trudelle
Status: REOPENED → NEW
QA Contact: claudius → aegis
Comment 43•23 years ago
|
||
->danm in case this represents some window infrastructure problem, although IMO,
deciding whether switch tasks or create a new window should be XPApps or Apps.
Assignee: trudelle → danm
Assignee | ||
Comment 44•23 years ago
|
||
Sure seems like an Apps issue. Regardless, WFM today. (Messenger)Tasks->Navigator
doesn't open a new Navigator window if one is already open; it just brings it to
the front.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → mozilla0.9.3
Comment 45•23 years ago
|
||
May God have mercy on us all. The 212 bug spam-o-rama is Now!
QA Contact: aegis → jrgm
You need to log in
before you can comment on or make changes to this bug.
Description
•