Open Bug 117114 Opened 23 years ago Updated 2 years ago

"-remote 'xfeDoCommand(openInbox)'" opens wrong type of window

Categories

(Core :: XUL, defect)

x86
Linux
defect

Tracking

()

People

(Reporter: leealwc, Unassigned)

References

Details

Mozilla Build: 0.9.7 Release

Steps to Reproduce:
1) Run Mozilla (with MailNews window NOT opened)
2) run "mozilla -remote 'xfeDoCommand(openInbox)'"

Expected Result:
 A "normal" Mozilla Mail window should open. "Normal" means that it's resizable,
have maximize/minimize button.

Actual Result:
 The window opened seems to be of "Dialog" type: unresizable, no
maximize/minimize button.

Note:
My window manager is IceWM 1.0.9.
xremote stuff
Assignee: sspitzer → blizzard
That's working just fine here.
Just tried with different window managers.
Works fine on Gnome + Sawfish.
Doesn't work on IceWM.
Doesn't work on xfce.
*** Bug 117238 has been marked as a duplicate of this bug. ***
Index: XRemoteService.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpfe/components/xremote/src/XRemoteService.cpp,v
retrieving revision 1.14
diff -u -r1.14 XRemoteService.cpp
--- XRemoteService.cpp  17 Dec 2001 07:05:53 -0000      1.14
+++ XRemoteService.cpp  29 Dec 2001 03:14:26 -0000
@@ -827,7 +827,7 @@
       return NS_ERROR_FAILURE;
     
     nsCOMPtr<nsIDOMWindow> newWindow;
-    rv = OpenChromeWindow(0, browserLocation, "chrome,all,dialog=np",
+    rv = OpenChromeWindow(0, browserLocation, "chrome,all,dialog=no",
                          nsnull, getter_AddRefs(newWindow));
   }


Can someone try this patch?  It looks like this might be it.
heh. sr=blake
nice. r=hixie
Checked in.  Let me know if this doesn't fix the problem.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
it still occur on build 2001123006.
Reopening per comments.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
confirming this bug

i'm a loving icewm user =)

running linux trunk 2002040422 and launching inbox via remote opens mail&news
which is different from that opened regularly in ways that the reporter described.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 134472 has been marked as a duplicate of this bug. ***
from bug 134472:
------- Additional Comment #1 From Andrew Schultz 2002-04-30 19:19 -------

I've figured out the problem, but I'm not familiar enough with the relevant code
to figure out the proper solution...

Here's the problem:

http://lxr.mozilla.org/mozilla/source/xpfe/components/xremote/src/XRemoteService.cpp#829
1) XRemoteService::XfeDoCommand calls XRemoteService::OpenChromeWindow (which
calls nsWindowWatcher::OpenWindow) with aArguments set to nsnull (just open mail
or the browser, no URL) and aFeatures set to "chrome,all,dialog=no"

http://lxr.mozilla.org/mozilla/source/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#449
2) OpenWindow sees that aArguments is nsnull and sets dialog to PR_FALSE, then
calls nsWindowWatcher::OpenWindowJS, which calls
nsWindowWatcher::CalculateChromeFlags

http://lxr.mozilla.org/mozilla/source/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#1118
3) CalculateChromeFlags ignores the "all" chrome flag because aDialog is false.  

resizing is included in "all", so the window is not resizable.

mozilla -remote "openurl(http://www.mozilla.org,new-window)"
works because there is a URL, so argc is not 0, and CalculateChromeFlags treats
it as a dialog and so pays attention to "all".

Step 1 (XRemote) looks ok, and steps 2 and 3 look a bit weird.  What do
arguments (or a lack thereof) have to do with being a dialog and why can't
non-dialogs set chrome to "all"?
-------------------------------------------

I would add that opening normal windows (as in the first window, and those
opened via Window->Mail and such) work because aDialog is PR_TRUE!!!
also, the same problem occurs with
mozilla -remote "xfeDoCommand(openBrowser)"

This is not a MailNews problem, but I don't know where it ought to go.
the starting place for trouble seems to be:
http://lxr.mozilla.org/mozilla/source/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#452
   PRBool dialog = argc == 0 ? PR_FALSE : PR_TRUE;

bonsai says that code was written "largely" by jst, checked in by damn (a long
time ago)

http://bonsai.mozilla.org/cvsquery.cgi?file=nsWindowWatcher.cpp&filetype=match&date=explicit&mindate=03%2F22%2F2001+19%3A00&maxdate=03%2F22%2F2001+19%3A30

==> XP Toolkits/Widgets
cc'ing jst
Assignee: blizzard → jaggernaut
Component: Mail Window Front End → XP Toolkit/Widgets
Product: MailNews → Browser
QA Contact: esther → jrgm
$ mozilla -mail    (not xremote)
works because OpenWindow in nsAppRunner.cpp passes a valid pointer to null as an
argument.

xremote passes a null pointer.  passing a pointer to null tricks
nsWindowWatcher.cpp into doing what it ought to anyway.

this bug would make many complain if bug 122698 were implemented.
Blocks: 122698
*** Bug 152896 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.2
just reporting that this bug exists in both version 1.1 and version 1.2a and
that I'm using IceWM  1.2.0 on Red Hat Linux version 7.3.

also, I can confirm that this bug exists for both Mail and Browser components in
both versions of Mozilla.
*** Bug 187358 has been marked as a duplicate of this bug. ***
*** Bug 189419 has been marked as a duplicate of this bug. ***
*** Bug 205724 has been marked as a duplicate of this bug. ***
*** Bug 207276 has been marked as a duplicate of this bug. ***
note that I fixed the XRemote part of this bug (see bug 149126).  the problem of
handling null arguments and "dialog=" remains in the windowwatcher code.
No longer blocks: 122698
Assignee: jag → nobody
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(enndeakin)
You need to log in before you can comment on or make changes to this bug.