Open Bug 117114 Opened 23 years ago Updated 2 years ago

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

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
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.