Bugzilla – Full Text Bug Listing
| Summary: | Accessibility problems | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Vlad Klicnik <klicnik> |
| Component: | SWT | Assignee: | Veronika Irvine <veronika_irvine> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P1 | CC: | arbenjam, asahata, birsan, konradk, Mike_Wilson, Tod_Creasey |
| Version: | 2.0 | Keywords: | accessibility |
| Target Milestone: | 2.0 M6 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 13934 | ||
|
Description
Vlad Klicnik
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. |