Closed Bug 25040 Opened 24 years ago Closed 19 years ago

Opening content in an existing window with window.openDialog fails to send arguments


(Core :: XUL, defect, P2)






(Reporter: bugs, Assigned: bzbarsky)



(Keywords: arch, helpwanted)


(1 file)

I wish to allow the user to open only one instance of the pref dialog.

currently I get this behaviour automatically since the name for the window I 
supply to openDialog is the same:

var prefWindow = window.openDialog("chrome://pref/content/pref.xul", 
"PrefWindow", "chrome,modal=yes,resizable=yes", pane );

so every time the user tries to open the dialog from other points in the app, a 
new window isn't created, the old one is loaded.

The problem here is that in this case, window.arguments for the window seem to 
be destroyed. What should happen is the new arguments passed from the subsequent 
call to openDialog should replace the arguments currently on the window.

I am about to check in a fix to prefwindow that makes it modal, single instance 
only that displays this problem. To test:

1) load mozilla, and mozilla mail
2) load prefs from mozilla
3) switch to mail, load prefs. the prefwindow opened by mozilla should appear.
4) look in the console. see text about window.arguments not being found. this is 
because a test of ( window.arguments ) fails on this second call to open the 
I wouldn't say this is a beta1 blocker, since it is somewhat of a fringe 
case, but here's what'd happen:

you'd load prefs from a navigator window, pref dlg would come up with the 
navigator start page...

if you also had a messenger window open, a call to prefwindow would focus the 
previously opened prefwindow, but the panel inside would not change to the 
messenger start panel, instead, window.arguments would be undefined and you'd go 
into the error condition in the prefwindow code where the default panel (or 
whatever) is loaded. 
Target Milestone: M16
Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17
spam, open xptoolkit qa contact moving over to jrgm
QA Contact: paulmac → jrgm
Problem still exists in a current build (2000050412 win95). 

ben/danm -- is this feature something you need/want for nsbeta2?
sure what the hell. I'll nominate it for beta3. I'm not desperate for it but it
allows for 4.xP (IIRC - but it is a minor detail). So, if you're out of more
pressing nsbeta3 stuff and looking for something to do...
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
Target Milestone: M17 → Future
I have a widget toolbar opened in a xul window. The is window is accessed from a 
menu item with: 
    var widgetbar = openDialog("chrome://xulapp/content/widgetbar.xul", "widget 
bar", "resizable=no,dependent,chrome,dialog=yes,titlebar",xulapp);

First time through everything is OK.
If the widgetbar becomed obscured and the user reselects this menu item then:
1. All program variables in the existing window become undefined.
2. The window.arguments are also undefined.
What is a poor programmer to do?
Any chance that you can fix this? It has been around a long time.
i would think you could switch your argument passing arch.

var w=openDialog(...);
w.push(arguemnts); //or something.

note that this would be probably be a workaround and not an acceptable 
Keywords: nsbeta3arch, helpwanted
Whiteboard: [nsbeta3-]
This blocks a 4xp view-source bug...
Blocks: 119802
So the problem here is that we AttachArguments() and then LoadURI().  As the URI
loads, GlobalWindowImpl::SetNewDocument() is called.  This sees that we already
have a doc and helpfully clears the JS scope, clobbering our brand-new arguments
Blocks: 131762
Attached patch Possible "fix"Splinter Review
This fixes the problem... not quite sure how it interacts with the plugin stuff
jst put in place (the code that triggers when mDocument is null and aDocument
is null in nsGlobalWindow::SetNewDocument).
Blocks: 259039
Comment on attachment 90447 [details] [diff] [review]
Possible "fix"

The plugin stuff I was worried about is gone (removed in bug 199033, revision
1.580 of nsGlobalWindow.cpp).  jst, danm, would you review?

I'll add a comment as to why this is needed before checking in.
Attachment #90447 - Flags: superreview?(jst)
Attachment #90447 - Flags: review?(danm.moz)
Comment on attachment 90447 [details] [diff] [review]
Possible "fix"

sr=jst with a comment explaining this.
Attachment #90447 - Flags: superreview?(jst) → superreview+
Attachment #90447 - Flags: review?(danm.moz) → review+
Assignee: danm.moz → bzbarsky
OS: Windows 98 → All
Priority: P3 → P2
Hardware: PC → All
Target Milestone: Future → mozilla1.8alpha5
Checked in for 1.8a5.
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.