Currently, we use a Javascript function called "openWindow" in staff-global.js as a bit of a helper function for executing "window.open". Well, there is a problem with the "name" argument when using IE 9 and lower. If the "name" has a space or certain punctuation (NOT including underscores), it'll throw an error which causes unexpected behaviours. For instance, if you open "Help" in the staff client using IE 9 or lower, it'll open the help page into the current window rather than a pop-up, which is far from desirable. I've noticed after a few greps that we usually use an alphabetic string with no spaces or punctuation when using the "name" parameter for window.open. According to Mozilla (https://developer.mozilla.org/en-US/docs/Web/API/Window.open), this is the recommended way of writing a "name". There are only a few instances where "openWindow" seems to use a string containing spaces for "name". The best thing to do is probably fix those instances as well as add a try/catch in openWindow for times where someone makes a mistake.
Created attachment 30526 [details] [review] Bug 12708 - Unexpected behaviour in IE 9 and lower when using openWindow This patch removes the whitespace from arguments to the "name" parameter in "window.open". It also adds a trap for the "openWindow" helper function, which will use a "null" instead of a "name" if window.open isn't able to handle a name with whitespace (i.e. if it's IE <= 9). _TEST PLAN_ 1) Switch to an emulated or authentic Internet Explorer version E 9 or lower 2) Click "Help" 3) Note that it opens the page in the current window rather than as a popup 4) Apply the patch 5) Shift refresh your page 6) Click "Help" 7) Note that it now opens (correctly) as a pop-up (If you want to be more thorough, you can test in other browsers as well to make sure that it still works.)
Created attachment 30556 [details] [review] [Signed-off] Bug 12708 - Unexpected behaviour in IE 9 and lower when using openWindow This patch removes the whitespace from arguments to the "name" parameter in "window.open". It also adds a trap for the "openWindow" helper function, which will use a "null" instead of a "name" if window.open isn't able to handle a name with whitespace (i.e. if it's IE <= 9). _TEST PLAN_ 1) Switch to an emulated or authentic Internet Explorer version E 9 or lower 2) Click "Help" 3) Note that it opens the page in the current window rather than as a popup 4) Apply the patch 5) Shift refresh your page 6) Click "Help" 7) Note that it now opens (correctly) as a pop-up (If you want to be more thorough, you can test in other browsers as well to make sure that it still works.) Tested with IE 10 developer tools: IE7, IE 8, IE 9 Window pops up as expected. No regression found with IE 10 / FF31.0 Signed-off-by: Marc Véron <veron@veron.ch>
Created attachment 30866 [details] [review] [PASSED QA] Bug 12708 - Unexpected behaviour in IE 9 and lower when using openWindow This patch removes the whitespace from arguments to the "name" parameter in "window.open". It also adds a trap for the "openWindow" helper function, which will use a "null" instead of a "name" if window.open isn't able to handle a name with whitespace (i.e. if it's IE <= 9). _TEST PLAN_ 1) Switch to an emulated or authentic Internet Explorer version E 9 or lower 2) Click "Help" 3) Note that it opens the page in the current window rather than as a popup 4) Apply the patch 5) Shift refresh your page 6) Click "Help" 7) Note that it now opens (correctly) as a pop-up (If you want to be more thorough, you can test in other browsers as well to make sure that it still works.) Tested with IE 10 developer tools: IE7, IE 8, IE 9 Window pops up as expected. No regression found with IE 10 / FF31.0 Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Tested for regressions in Firefox and Chromium. I checked the help and the duplicate authorities windows still work correctly. Passes tests and QA script.
Patch pushed to master. Thanks David!