Community
Participate
Working Groups
Build ID: Eclipse 3.3 M6 Steps To Reproduce: Use eclipse 3.3 M6 on Vista machine 1. Open "Internet Web Browser" view from eclipse show view menu. 2. Visit any website, e.g: http://www.eclipse.org 3. After it is loaded, click in the web page, make sure the focus is in the web content. 4. Click back to the URL input bar, the caret disappears, while you can still type char on the url bar. 5. If you switch to other perspective, or click with other view, and then back to the browser view, the caret is shown in URL bar again. 6. Repeat 3/4, the caret disappears again after it is out from browser widget. More information: -This doesn't happen with MS IE7 on WinXP sp2
Are we addressing this for 3.3 ?
Focus does go to the text widget, but for some reason the caret disappears. This can be reproduced with a basic OLE example: public static void main(String[] args) { final Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new GridLayout()); final Text text = new Text(shell, SWT.BORDER); text.setLayoutData(new GridData(GridData.GRAB_HORIZONTAL)); final OleControlSite controlSite; try { OleFrame frame = new OleFrame(shell, SWT.NONE); frame.setLayoutData(new GridData(GridData.FILL_BOTH)); controlSite = new OleControlSite(frame, SWT.NONE, "Shell.Explorer"); controlSite.doVerb(OLE.OLEIVERB_INPLACEACTIVATE); } catch (SWTError e) { System.out.println("Unable to open activeX control"); return; } shell.open(); final OleAutomation webBrowser = new OleAutomation(controlSite); int[] ids = webBrowser.getIDsOfNames(new String[]{"Navigate", "URL"}); Variant[] rgvarg = new Variant[] {new Variant("http://www.google.com")}; int[] rgdispidNamedArgs = new int[]{ids[1]}; webBrowser.invoke(ids[0], rgvarg, rgdispidNamedArgs); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } webBrowser.dispose(); display.dispose(); } I investigated this with SSQ and we could not determine why this is happening. So there is currently no fix for this.
Any commitment for 3.3 or still don't know ?
It's a "don't know". I think Steve N. is a good candidate to look at this when he returns next week.
Grant, any progress on having Steve look at this?
*** Bug 182017 has been marked as a duplicate of this bug. ***
It appears to be an IE7 issue (happens on XP or Vista), so I've updated the title accordingly.
This appears to be an IE7 bug, because it even happens if snippet123 ( http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet123.java ) is modified to include a Text. Snippet 123 does not use the Browser, but just invokes the three lines of OLE needed to open IE in place. I looked at this with SN yesterday and we could not find a fix. So at this point I don't think a committment for 3.3 can be made for this.
Is this really an issue with focus? Bug 80080 described this same problem back in 2004 (probably IE5 days) and bug 182017 https://bugs.eclipse.org/bugs/show_bug.cgi?id=182017 started occurring with IE6. The issue is that the text cursor is not restored when the user switches from the browser view to an editor view. Note that you can switch between these two views all day long and never see the problem if you do not click within the browser view window itself. That is, if you just select the tab to switch view, then select the tab for an editor, then in this case the text cursor is displayed. At least this is my situation described in bug 182017 which has been marked as a duplicate of this. I believe the issue is that when the user physically clicks in the browser view, the text cursor is turned off because it is not an editable view. Then when the user selects an editor view by clicking on a tab or other means, the text cursor is still turned off. I do not dispute that the cursor is being turned off by the browser view, but it should be possible to force it back on when the editor view receives the focus. HTH
Submit a patch.
(In reply to comment #10) > Submit a patch. It was not my intent to trivialize the problem. I'm sure this is a tough nut to crack since it has been around for so long. I just wanted to avoid classifying this as an IE7 issue when it might not be. If I had any spare cycles to work on this, I would be thrilled to dig in.
*** Bug 187022 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > Submit a patch. Steve N. Do you have a patch for this problem? Where can we get it?
Nope. Grant and I will look at it today.
Under consideration for Eclipse 3.3 RC2.
+1
Fixed > 20070524
*** Bug 80080 has been marked as a duplicate of this bug. ***
*** Bug 240109 has been marked as a duplicate of this bug. ***
