Community
Participate
Working Groups
20020326, Win2K When I launch the Help view, the tab key does not actually do anything. I need to first click on one of the "live" areas before it starts working (eg. the banner with the tool buttons, the nav frame or the content frame. We should be starting the Help view in a way that can be immediately navigated via the keyboard.
It also does not work when launched from F1 or search. I will make it a P2 item, but it should probably be a P1
Our OLE control for Internet Explorer does not accept focus until it is clicked once. Since the back and forward buttons are initially dissabled, there is nothing left in the shell to accept the focus. If I create some controls that accept focus (or anable toolbar buttons), the focus traverses these controls but skips OLE. Once OLE control is clicked, the focus can traverse all controls. I will route the bug to SWT. Could you (SWT experts) see if we need to do anything special, or is this SWT or IE limitation? Please change back the component if this does not look like SWT bug.
<rant> It is incredibly hard to debug and test changes to SWT or to your IEHost - I can't just modify your code and run with it because I get a "javax.servlet.ServletException: org.eclipse.core.boot.BootLoader " error. And if I make changes to SWT I guess I have to create a jar and put it in the plugins folder because you do not seem to pick up the changes from the workspace and even then, where is standard out - I was unable to verify that I actually ever ran my code changes. I was in fact unable to test any changes with your stuff but I have been testing against a plain IE ActiveX control. </rant> I made one fix which helps to get focus in other activeX controls but it does not seem to help IE. I have found no way to get IE to become active and take input except for clicking on the control. I will continue to poke around but I do not have high hopes.
It should not be too bad to work with IHost (with SWT being contstant in a dll). Standard out is written to Eclipse .log file. There is one message per line and they start with "Web browser message:" followed by line that IEHost wrote to stdout. javax.servlet.ServletException: org.eclipse.core.boot.BootLoader error - I have never seen it. You should be able to have 0409 integration driver, load org.eclipse.help.ui from repository, import other plugins to your workspace and run help. The error might be caused by having SWT in a workspace rather than a dll. I do not know the mechanism what happens then.
If you tried self hosting help, you should also import the org.eclipse.tomcat into the same workspace. Basically you need to have the tomcat and help plugins in the same directory.
If you take the below code and overwrite the org.eclipse.help.ui.internal.browser.win32.IEBrowserAdapter, it will allow for easier debugging. It will open an in-process shell with embedded IE, instead of launching IEHost class in a separate process, but still has the problem that this bug is about. It should be easy to debug this now. Make sure you have plugins org.eclipse.help org.eclipse.help.ui org.eclipse.help.webapp org.eclipse.tomcat in your workspace. /* * (c) Copyright IBM Corp. 2000, 2002. * All Rights Reserved. */ package org.eclipse.help.ui.internal.browser.win32; import org.eclipse.help.internal.ui.util.HelpWorkbenchException; import org.eclipse.help.ui.browser.IBrowser; import org.eclipse.swt.SWT; import org.eclipse.swt.events.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*; public class IEBrowserAdapter implements IBrowser, ICommandStateChangedListener { WebBrowser webBrowser; ToolItem backItem, forwardItem; public void displayURL(String url) { createShell(); webBrowser.navigate(url); } private void createShell() { Shell shell = new Shell(); GridLayout layout = new GridLayout(); layout.marginHeight = 0; layout.marginWidth = 0; layout.horizontalSpacing = 0; layout.verticalSpacing = 0; shell.setLayout(layout); createContents(shell); int w = 800; int h = 600; shell.setSize(w, h); shell.open(); //shell.setVisible(true); shell.moveAbove(null); } private Control createContents(Composite parent) { Composite composite = new Composite(parent, SWT.NONE); GridData data = new GridData(GridData.FILL_BOTH); composite.setLayoutData(data); GridLayout layout = new GridLayout(); layout.marginHeight = 0; layout.marginWidth = 0; layout.horizontalSpacing = 0; layout.verticalSpacing = 0; composite.setLayout(layout); // Add a toolbar ToolBar bar = new ToolBar(composite, SWT.FLAT | SWT.HORIZONTAL); GridData gridData = new GridData(); gridData.horizontalAlignment = GridData.FILL; gridData.grabExcessHorizontalSpace = true; //gridData.horizontalSpan = 3; bar.setLayoutData(gridData); // Add a button to navigate back backItem = new ToolItem(bar, SWT.HORIZONTAL, 0); backItem.setText("Previous_page"); backItem.addSelectionListener(new SelectionListener() { public void widgetSelected(SelectionEvent e) { webBrowser.back(); } public void widgetDefaultSelected(SelectionEvent e) { widgetSelected(e); } }); // Add a button to navigate forward forwardItem = new ToolItem(bar, SWT.NONE, 1); forwardItem.setText("Next_page"); forwardItem.setHotImage(null); forwardItem.addSelectionListener(new SelectionListener() { public void widgetSelected(SelectionEvent e) { webBrowser.forward(); } public void widgetDefaultSelected(SelectionEvent e) { widgetSelected(e); } }); try { webBrowser = new WebBrowser(composite); webBrowser.addCommandStateChangedListener(this); webBrowser.navigate("about:blank"); } catch (HelpWorkbenchException hwe) { System.err.println(hwe); } return composite; } public void commandStateChanged(boolean back, boolean forward) { if (backItem.getEnabled() != back) backItem.setEnabled(back); if (forwardItem.getEnabled() != forward) forwardItem.setEnabled(forward); } public void close() { } public boolean isCloseSupported() { return true; } public boolean isSetLocationSupported() { return true; } public boolean isSetSizeSupported() { return true; } public void setLocation(int x, int y) { } public void setSize(int width, int height) { } }
This is critical for 13934 (P1, blocker). Without it, help cannot be navigated with the keyboard.
I think I may have a solution for this one in hand. The biggest problem I have to overcome before releasing it is that the solution seems to break Word and Paint which are embedded editors in Eclipse. I may just release this as a change to OleControlSite and leave OleClientSite untouched. We shall see.
I have released the fix to just the OleControlSite part. This is in today's integration build (0515).
Veronika, this fixed the orginal problem but broke it in a different place: - click Tab or Ctrl-Tab until you get focus on the toolbar that contains the tree icons: toggle navigation, synchronize and print (this is just above the main help area). Tab or Ctrl-Tab on this frame. The focus never leaveas the frame, or if it does, it goes to the main SWT control with back/forward buttons if they are enabled and comes back to the same frame. Keybaord navigation works fine in IE (try Ctrl-N when focus is on Help view, it should open the browser), and also worked fine before the fix. The problem was only getting the initial focus inside the control. We opened bug 16093 for it, but I will probably mark it as a dup of this bug.
The problem you are seeing is described by: http://dev.eclipse.org/bugs/show_bug.cgi?id=5910 5910 is fixed but not in 0515 - see the HEAD stream to test it. Everything works in IE because the place you tab to after the print button is the text field in the ie browser which takes focus. In the embedded guy, the place you tab to is the forward/backward toolbar which has nothing but disabled items in it and grabs the focus erroniously. Closing this PR and marking 16093 asa duplicate of 5910.
I am reoppenning this, as the fix caused a regression. In this driver when back button and forward button are anabled, tab navigation does not work correctly. After tabbing to toolbar frame, focuses gets to toolbar buttons and back to toolbar frame. It does not move to next (first) frame. I was suggested in bug 16093 that shift tab should be used. Shift tab causes focus to traverse frames back but stops on the first frame without placing focus on toolbar. Both tab and shift-tab should allow for getting to all the frames. There should not be frames beyond which keyboard navigation does not work. Notice that in the build, that did not contain fix for the original problem, once the IE area has been clicked once with the mouse, the focus could traverse all frames and toolbar without any dead ends.
There is something different about your web page. I have tested this with the OTI internal home page and I can access all fields on the page by tabbing around even when tabbing in and out. This is the behaviour of the activeX control and there is nothing I can do about forcing the focus to go to one frame or another on activation. In the old driver the control was never activated/deactivated when focus changed.
Can you guys use the following Navigate method in which you specify the frame to navigate to as a workaround. Listen for focus in and then call this method on the OleAutomation object to force the focus to the first frame on your page using TargetFrameForName : IWebBrowser2.Navigate Navigates to a resource identified by a URL or to the file identified by a full path. Syntax HRESULT Navigate( BSTR url, VARIANT *Flags, VARIANT *TargetFrameName, VARIANT *PostData, VARIANT *Headers ); Parameters url [in] Required. A BSTR expression that evaluates to the URL, full path, or Universal Naming Convention (UNC) location and name of the resource to display. Flags [in] Pointer to a variable that specifies whether to add the resource to the history list, whether to read to or write from the cache, and whether to display the resource in a new window. The variable can be a combination of the values defined by the BrowserNavConstants enumeration. TargetFrameName [in] Pointer to a string that contains the name of the frame in which to display the resource. The possible values for this parameter are: _BLANK Load the link into a new unnamed window. _PARENT Load the link into the immediate parent of the document the link is in. _SELF Load the link into the same window the link was clicked in. _TOP Load the link into the full body of the current window. <WINDOW_NAME> A named HTML frame. If no frame or window exists that matches the specified target name, a new window is opened for the specified link. PostData [in] Pointer to data to send with the HTTP POST transaction. For example, the POST transaction is used to send data gathered by an HTML form. If this parameter does not specify any post data, IWebBrowser2::Navigate issues an HTTP GET transaction. This parameter is ignored if URL is not an HTTPURL. Headers [in] Pointer to a value that contains the HTTP headers to send to the server. These headers are added to the default Microsoft® Internet Explorer headers. The headers can specify things such as the action required of the server, the type of data being passed to the server, or a status code. This parameter is ignored if URL is not an HTTPURL. Return Value Returns one of the following values. S_OK The operation was successful. E_INVALIDARG One or more parameters are invalid. E_OUTOFMEMORY Out of memory.
*** Bug 17350 has been marked as a duplicate of this bug. ***
I'll let Konrad explain his experimentation with the proposed Navigate method (I recall there were problems), but I tested a different page that contains frames: http://www.msdn.microsoft.com/library and noticed identical behavior: things work fine until reaching the last frame, then focus goes between that frame the and back/forward buttons.
The workaround to call HRESULT Navigate( BSTR url, VARIANT *Flags, VARIANT *TargetFrameName, VARIANT *PostData, VARIANT *Headers ); by help does not look like acceptable solution. Some of the issues are: 1. The name of the frame to navigate is not always known. Help browser is not only used to display help frame set. Same goes for the URL displayed within a frame. URLs to load within help frames are dynamically computed by JavaScript. 2. Calling this navigate method, will cause frame to be reloaded. This in turn results in: a) Visible effect of page being reloaded. b) Audible click sound, while no navigation has been triggered by the user. c) All user state information within a frame to be reset, i.e. the state of the navigation tree, navigation page displayed will be lost. All of help frames (except the topic content) have dynamic content that reloading the frame will reset. 3. The above effects will also affect users not using keyboard navigation. Whenever user brings the help window to foreground, or restores from minimized state the focus is set 4. Browser history might be affected.
We have done all we can about this issue. You need to set up your pages in a way that allows you to reference the content in a navigable way. We have described the nature of the problem and provided a possible workaround. We do not have time to do more than that.
(Previous comment from McQ).
Thanks Veronika. I think we'll have to investigate different workarounds that don't involve he SWT control. I will leave the bug as WNF for the time being.
I have removed the toolbar from the help browser on windows, and added the buttons to one of the HTML frames displayed by help. This eliminates the accessibility problem for help.
