Menu
▾
▴
#998 Problems when page loaded via window.location.assign
I have a page that creates a popup window, then assigns its URL, then calls a javascript function in that window. This doesn't work when the page has been loaded doing:
var newwindow = window.open('', 'newWindow');
newwindow.location.assign(newurl);
But works fine when the page is loaded by doing:
var newwindow = window.open(newurl, 'newWindow');
JUnit test case attached :-)
This problem also exists when you get a reference to an existing window - updating JUnit test.
A bit of research that may or may not help someone looking at this...
I traced through some debug for the openWindowThenUseLocation test, using 3 breakpoints:
1) in the Window class at the line webWindow = webClient.getWebWindowByName(windowName)
2) in ScriptableObject, in get(String, Scriptable), conditional on name.equals("getStatus")
3) in ScriptableObject, in put(String, Scriptable, Object), conditional on name.equals("getStatus")
What I observed was:
- When the open function is called, a new WebWindow is created, whose Window scriptableObject had object id 4491.
- When the ScriptableObject.put method was called both with value of NOT_FOUND, and then as an instance of InterpretedFunction, the Window object id was 6449
- When the ScriptableObject.get method was called, the Window object id was again 4491.
It seems like the javascript functions are being created on the wrong Window object?
More information:
It seems that this is being caused by the implementation of TopLevelWindow.isJavaScriptInitializationNeeded - the scriptObject is not null, but the getEnclosedPage().getWebResponse() is not an instance of StringWebResponse, and so the window gets re-initialized, losing all detail of the javascript functions defined for it.
Ahh - ignore my previous comment (@15:17), it was a bug in my test that caused the openExistingWindow to fail. I will attach an updated junit test. For failure with openWindowThenUseLocation test.
JUnit test
Ok - gone back to looking at the originally failing test. It looks like when the window.location.assign(url) is called, the WebWindow is re-initialized for the new page, which gives the WebWindow a new Window object. However, the javascript var for the window in the html has a reference to the Window object when the new blank window was created, not to the new Window that has the state of the current page's javascript.
I don't know how you would fix this - either you'd want to reset the Window object to its initial state, or you'd want to update all javascript references to the window in question, so that it points at the new Window object
Patch for code at htmlunit 2.6 tag
I've attached a patch that implements a reset() method for Window - not sure how much I like it, but it does fix the bug that the JUnit test highlights - opinions?
Alternative Patch using Rhino Delegator class
Hi, I've added an alternative patch that uses a Rhino Delegator to return the reference to the window from the jsxFunction_open method, and then updates Delegator instances with new delegee when the Window object changes for the WebWindow. This also fixes the bug in question.
I was hoping someone might take a look at this at some point, shouldn't be too complicated as I have provided a JUnit test case, and possible solution patches... Anybody??
Cheers,
James
I actually just ran into this same bug while fixing another bug, so I'll assign it to myself. The "correct" fix for this, based on the current design is to have the open() method return a WindowProxy instance instead of a Window; the problem is that WindowProxy currently has issues with function execution (Rhino checks if it's "instanceof Window", and it's not). WindowProxy is essentially a dynamic Delegator for Window instances.
I'm hoping to fix this by having WindowProxy extend Delegator once these two Rhino bugs have been fixed (or at least once I get some feedback on whether or not the suggested approaches are kosher):
https://bugzilla.mozilla.org/show_bug.cgi?id=539877
https://bugzilla.mozilla.org/show_bug.cgi?id=539875
OK, I think this is fixed in SVN now; thanks for your patience :-)