Community
Participate
Working Groups
Build id: 200404100010 / Windows XP To reproduce: - set the internal browser as the help browser - open the help - click on a link holding down shift A new browser window opens up. The window is not resizeable.
I have not considered this scenario. The second window is a dialog, as it is usually used for displaying working set selection dialogs, errors, e.t.c. I am not sure how to distinguish between browser widget sending a WindowEvent to display another instance of a browser, or just to open a message dialog for the current instance. Christophe, is there a way?
A Shell should be used instead of a Dialog. The WindowEvent.java file contains javadoc that illustrates how to use it. * browser.addOpenWindowListener(new OpenWindowListener() { * public void open(WindowEvent event) { * Shell shell = new Shell(display); * shell.setText("New Window"); * shell.setLayout(new FillLayout()); * Browser browser = new Browser(shell, SWT.NONE); * initialize(display, browser); * event.browser = browser; * } * });
Christophe, I was not precise when I wrote the second window is a dialog. We are not using Dialog class, but Shell(parentShell, SWT.DIALOG_TRIM | SWT.PRIMARY_MODAL) Having a regular non-modal shell for secondary window, as you suggest, will fix this, but break other scenarios. 1. While on Windows a print dialog is created by Windows itself, on Linux these result in calls to our OpenWindowListener. If I modify the code to open an independent shell, and users clicks on a print button in help (that calls Javascript window.print() ), Our openWindowLister will be called and user will get a non modal, resizible, print window. What is worse, the user will be able to click the print button multiple times and get multiple of print window opened, and they will be able to continue working without closing them. 2. Clicking "Search scope:" HTML link on help UI, is should open a dialog similar to working set dialog in the workbench. It should be modal with a dialog trim. So the problem is not how to achieve modeless behavior, but how can openWindowListener determine which behavior is needed at the moment (is the request for print dialog, modal dialog, or nonmodal secondary window).
About 2.: what is Help doing to activate "Search scope"? It seems to be invoking javascript:openAdvanced(). Could you confirm and past the code for openAdvanced?
Yes, here is the code. The interesting is resizeable=no option passed to window.open(). It is part of JavaScript specification. Can OpenWindowListener read this value somehow? function openAdvanced() { var scope = document.getElementById("scope").firstChild; var workingSet = ""; if (scope != null) workingSet = document.getElementById ("scope").firstChild.nodeValue; <% if (data.isIE()){ %> var l = top.screenLeft + (top.document.body.clientWidth - w) / 2; var t = top.screenTop + (top.document.body.clientHeight - h) / 2; <% } else { %> var l = top.screenX + (top.innerWidth - w) / 2; var t = top.screenY + (top.innerHeight - h) / 2; <% } %> // move the dialog just a bit higher than the middle if (t-50 > 0) t = t-50; advancedDialog = window.open("workingSetManager.jsp? workingSet="+encodeURIComponent (workingSet), "advancedDialog", "resizeable=no,height="+h+",width="+w+",left="+ l+",top="+t ); advancedDialog.focus(); }
Thanks. Some notes: About 1. Mozilla does fire new window events where IE simply bring up its own (modal) dialog. I'll need to check what the other browsers do. 2. "Search scope". The dialog should be non resizable but not modal in this case. IE is documented to never fire new window events for modal dialogs (msdn: showModalDialog and showModelessDialog Do Not Fire NewWindow2 (251128)) (unlike Mozilla). Running the help in the standalone browser, it can be verified the dialog is not modal. Changing summary from "second browser not resisable" to "expose chrome required for new browser". This PR is for investigating adding API to the WindowEvent to provide some chrome information.
Konrad: Have you observed other cases (either than window.print) where you expect a modal dialog? If so please let me know, I'll need to test them.
Not really. I know of two other instances when stand alone Mozilla displays dialogs: 1. When Mozilla privacy & security is set to ask before accepting a cookie, navigting to help, Mozilla displays a dialog: "Confirm" The site help1:2003 wants to set a cookie. Use my choice for cookies from this site Show details Allow Deny When the same is done using embedded Mozilla no dialog is shown (OpenWindowListener is not called) - a bug? 2. When Mozilla privacy & security is set to warn when submitting information without strong encription, performing help search displays a "Security Warning" dialog. In both cases (embedded and stand alone browser) Mozilla displays the dialog itself.
Ok. v>20040416 - The SWT Browser does not send new window requests for modal dialogs like the PrintDialog. This was a side effect of Mozilla using HTML to emulate modal dialogs when they are missing from the OS. To be clear, in the particular case of the PrintDialog, the dialog will come up automatically as it does on Windows. Konrad: Help can and should now use a non modal Shell to handle the WindowEvent as indicated in the javadoc for WindowEvent. This PR remains open - chrome (resizable etc.) should be exposed to the WindowEvent. some development notes: /* * Note. Safari and Internet Explorer expose the requested chrome (resizable, toobar, location, * status) after the window open request and before the window show request. Mozilla * and Voyager provide the chrome information along with the window open request. * Because of the Safari and Internet Explorer behaviour, it is not possible to pass * all the chrome information in the WindowEvent in the OpenWindow request. It has to * be done in the ShowWindow request. */
It is better if this bug is under SWT, so it does not get forgotten. Moving.
I have changed help code to always use new Shell(); This allows links with target="_new" or user openning new window (by shift-click, or open in the new window action from the context mentu) to get secondary non-modal window. The remaining is that we would like to have some of the windows ("Select search scope", "new search scope", "confirm Show All Topics" ...) opened from main help window be modal. Without it these windows may go to bottom, be forgotten, or try to access opener that has changed. Chris, since this bug is not fixed, do you know of any tricks (or hacks) that I could use in 3.0 to guess whether to create a modal or not modal shell?
From what I have gathered about html and javascript, there is a known lack of support for modal windows. There does not seem to be a portable way to request to open a new modal window containing an HTML document. That's an HTML/javascript limitation. An IE only solution is to use window.showModalDialog. I found an example at: http://www.google.ca/search? q=cache:zGSvCFle1_sJ:www.devguru.com/features/knowledge_base/A100203.html+windo w.showModalDialog&hl=en&start=7 Click on Click "here" to see an example. You can try this example in IE as well as in the IE SWT Browser. You can try using javascript Alerts but you probably want to render something more elaborate. Another way using the Browser widget is to set your links so that they open in the same target. You register the LocationListener and filter/forward to a modal window certain URL requests (probably a little bit like what the Eclipse Intro page does - except you forward a URL to a new Browser in a modal Shell). Something like: browser.addLocationListener(new LocationListener() { public void changing(LocationEvent e) { if (SpecialURLToOpenInNewWindowModal(e.location)) { e.doit = false; Shell shell = new Shell(display, SWT.APPLICATION_MODAL); shell.setLayout(new FillLayout()); Browser browser = new Browser(shell, SWT.NONE); browser.setUrl(e.location); } } public void changed(LocationEvent e) { } });
Thanks a lot Chris. It helped. Openning windows in help webapp is triggered by links at some places, and javascript in another, but a trick of putting window.location="javascript://needModal"; before every window.open(...) ensured the LocationListener is called every time, but does not affect current location. Help browser listens to such locations and sets a private flag that is valid for a second, or cleared by other location. OpenWindowListener checks the flag when deciding style of new shell. It works for me, and was simple to hack.
Sounds like we are done with changes under this bug for 3.0 (centered around the help system). Am I reading this right? If so, could we resolve this bug as fixed or if we will do more work for some more general cases, we should document that fact and resolve this as later (post 3.0).
We have a hack in help, but it is not a proper fix. I prefer the bug deferred for later, rather than resolved as fixed.
[post 3.0] As said in comment 6, this PR is for investigating adding API to the WindowEvent to provide some chrome information. In particular: - resize/no resize - whether the application should bring up a toolbar or not To clarify with Konrad, modality is unlikely going to be part of the chrome information - because WindowEvent's relate to non modal dialogs. Modal dialogs (Alerts, IE showModalDialog) don't trigger WindowEvent's (comment 12) Steven, as you have observed SWT does not use the bugzilla LATER flag, let Steve (steve_northover@ca.ibm.com) knows about your need for this.
Ron Capelli directed me to this RFE/bug in conversation http://dev.eclipse.org/newslists/news.eclipse.platform.swt/msg12430.html Please don't forget to address the chrome aspect of this defect. I understand this to mean that it should be achievable that the behavior of clicking on links inside an embedded browser is identical to the external host browser. I have working on windows and IE. For example JavaScript window.open parameters for statusbar, titlebar etc should be honored. Also links to new window frames (target="_new") should open a full external browser. For IE http://msdn.microsoft.com/library/default.asp?url=/workshop/browser/mshtml/reference/events/events.asp describes the NewWindow2 event. It says that one option is:"Do nothing and do not set ppDisp to any value. This will cause the object that fired the event to create a new InternetExplorer object to handle the navigation." I believe the current eclipse code base doesn't allow to do this.
Christophe, will some or all of the work left to do be targeted for 3.0.1 or will it all move to 3.1? Could we target the bug appropriately to let the interested parties know?
Not planned for 3.0.1 at the moment.
Fixed in HEAD. WindowEvent has new fields addressBar, menuBar, statusBar, toolBar. The VisibilityWindowListener.show notification fires a WindowEvent with these extra fields set. The SWT BrowserExample plug-in (inside the Eclipse Example plug-ins) has been modified to use the new API.
