211719 - opener is being reset to null when used within frameset

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Ian Neal]

Using BuildID 2003070308 on WinXP SP1
Steps to reproduce:
1. Log into SunONE's calendar express 5.1.1
2. Set up an event and on the Edit Event window, in the Invite other users or
resources section, there is a search button, clicking on this.
3. That produces a new window 'User Search'.
4. Put a known user in the txt window and click on search.
5. A list of results is produced with tick boxes next to them.
6. Tick one of the boxes and click either OK or apply to add the user to the
list of attendees.

Expected result.
1. List of attendees has had user selected added.
2. User Search window disappears if OK was the button clicked.

Actual result.
1. Nothing happens
2. Window doesn't even disappear if OK was the button clicked.

Now this works in Netscape 7 and Mozilla 1.3 but fails in Netscape 7.1 and
Mozilla 1.4+.

No error message is produced in the javascript console.

Works in BuildID 2003042508 but fails in BuildID 2003052608
I'll see if I can narrow down the regression window any further.

Comment 1

[Ian Neal]

Shows up in 1.4b release which has a BuildID 2003050714

Comment 2

[Ian Neal]

The ok button sits as part of a form in a frame called "button", the other
frames being "tab" and "main". The order of the frames is "tab", "main",
"button". This frameset is called from another frameset with the same frame
names and the same frame order. The javascript attached to the onclick of the ok
button is as follows.

{
  var myform = parent.frames[1].document.forms[0];
    if (opener)
    {
      var a = opener.jmain.frames[1].getarray();
      var users = opener.jmain.frames[1].getarray();
      var i = 0;
      var x;
      a[0] = 'invite';
      a[1] = users;
      for (x = 0; x < myform.elements.length; x++)
      {
        var e = myform.elements[x];
        if (e.type == "checkbox" && e.checked)
        {
          users[i++] = e.value;
        }
      }
      if (users.length > 0)
      {
        opener.jmain.frames[1].accept(a);
        jmain.close_all();
      }
    }
    jmain.close_all();
    }
  }
  return;
}

At the top of the script:
var jmain = parent;
var opener = jmain.opener;

Comment 3

[Ian Neal]

Attachment: Testcase

Unzip testcase and load command0.htm
Click on search button which should pop up a new window
Tick check box on new window and then click ok
On working browsers the new window should close and the original window should
try to connect to http://hou3.jephson.org/
On broken browsers the new window doesn't close
Problem appears to be that opener is null on broken browsers and non-null on
working browsers.

Comment 4

[Ian Neal]

Looks like a DOM Level 0 problem, opener is being forgotten for some reason

Comment 5

[Ian Neal]

Attachment: Reduced testcase

Steps to reproduce
1. Unzip testcase2.zip, then open command0.html
2. Click on Search button
3. New window opens
4. Click on OK button

Expected Result
1. Alert pops up saying opener is not null

Actual Result
1. Alert pops up saying opener is null

Comment 6

[Ian Neal]

Looking at the page command_003.html, even though opener is being set to
parent.opener something later on is setting it to null.
Tweaking summary.

Old summary "Cannot invite additional people to an event in SunONE's calendar
express using Mozilla 1.4+"

Comment 7

[Ian Neal]

Another summary tweak

Comment 8

[Ian Neal]

Testing with linux builds on RH9.0 the regression is present in buildID
2003050522 but not in buildID 2003050422

Comment 9

[Ian Neal]

Only checkin during that period that seems to touch openers directly is for bug
159424

Comment 10

[Ian Neal]

I have backed out the patch to bug 159424 locally and the regression disappears.
So just need to work out why that patch is causing this regression.

Comment 11

[Ian Neal]

I suspect this is being caused by the part of the patch to bug 159424 mentioned
in bug 159424c#37 - "As a bonus, this patch also makes window.opener settable
only to null, which will avoid some problems down the road."
I'm just spinning a build to test out this theory.

Comment 12

[Johnny Stenback (:jst)]

Nice debugging, Neal! I had a look at this and this is caused by the attampt to
declare a global variable named opener in command_003.html, that's what's
attempting to set window.opener to a non-null value (var opener = ... is equal
to opener = ... when opener is already defined in that scope). Our sollution for
this type of problems in Mozilla with other variable names has been to make
those properties settable only by qualifying the property names, i.e. you can
set window.opener by saying "window.opener = ...", but not by just saying
"opener = ...". I'll attach a patch that makes window.opener act like all other
'replaceable' writable global properties.

Comment 13

[Johnny Stenback (:jst)]

s/Neal/Ian/, sorry.

Comment 14

[Johnny Stenback (:jst)]

Attachment: Make window.opener a replaceable writable propert.

Comment 15

[Johnny Stenback (:jst)]

Fixed.

Comment 16

[Ian Neal]

Using BuildID 2003070904, testcase now works and so does SunOne's Caldendar
Express 5.1.1
It would be good to get this into both the 1.4 branch and 1.5a -> setting
blocking flags

Comment 17

[Ian Neal]

Using BuildID 2003070904, testcase now works and so does SunOne's Caldendar
Express 5.1.1
It would be good to get this into the 1.4 branch (should already be in 1.5a)->
setting blocking flags

Comment 18

[Ian Neal]

Comment on attachment 127283 [details] [diff] [review]
Make window.opener a replaceable writable propert.

Requesting driver approval for 1.4.x branch. Patch is low risk and fixes a
problem with using mozilla 1.4/netscape 7.1 in conjunction with SunONE's
Calendar Express 5.1.1

Comment 19

[Ian Neal]

Trying to fix too many blocking flags

Comment 20

[Mike Kaply [:mkaply]]

Comment on attachment 127283 [details] [diff] [review]
Make window.opener a replaceable writable propert.

a=mkaply for checkin to 1.4.1

Comment 21

[Ian Neal]

jst: can you do the honours?

Comment 22

[Johnny Stenback (:jst)]

Fix checked in on MOZILLA_1_4_BRANCH.

Comment 23

[Ian Neal]

Cancelling blocking request seeing it's been checked in for 1.4.1