Community
Participate
Working Groups
When content assist is attached to a Text widget, the location of the suggestion popup is incorrect. Content assist is applied as follows: bc. TextContentAdapter textContentAdapter = new TextContentAdapter(); IContentProposalProvider provider = // provider ContentAssistCommandAdapter adapter = new ContentAssistCommandAdapter(nameText, textContentAdapter, provider, org.eclipse.ui.fieldassist.ContentAssistCommandAdapter.CONTENT_PROPOSAL_COMMAND, new char[0],true); adapter.setProposalAcceptanceStyle(ContentAssistCommandAdapter.PROPOSAL_REPLACE); I'm not sure if it matters, the Text is embedded in an expandable section in a SashForm in a multipage editor. attaching two screenshots showing popup placement issue.
Created attachment 150388 [details] screenshot showing placement, red lines indicate offset problem
Created attachment 150389 [details] a more severe case, red lines showing offset issue
Running Eclipse SDK Version: 3.6.0 Build id: I20091020-0931 Cocoa-64
We changed the bounds calculation code in JFace's field assist APIs recently. Are you using multiple monitors, David?
(In reply to comment #4) > We changed the bounds calculation code in JFace's field assist APIs recently. > Are you using multiple monitors, David? Yes! I've got a laptop monitor and a secondary monitor.
(In reply to comment #4) > We changed the bounds calculation code in JFace's field assist APIs recently. Does it make sense for me to try this with the Carbon build to verify that there's a problem, or is that necessary?
(In reply to comment #6) > Does it make sense for me to try this with the Carbon build to verify that > there's a problem, or is that necessary? Wouldn't hurt if you have the bandwidth to spare. If you invoke Ctrl+F on a text editor and check the 'Regular expressions' checkbox and invoke content assist on the 'Find' text field, does it work properly there?
Created attachment 150401 [details] screenshot of find dialog with content assist (In reply to comment #7) > If you invoke Ctrl+F on a text editor and check the 'Regular expressions' > checkbox and invoke content assist on the 'Find' text field, does it work > properly there? Looks to me like the same problem with the find dialog.
Created attachment 150403 [details] screenshot of find dialog using Carbon Looks like Carbon is experiencing the same problem.
Just downloaded I20091020-0931 for win32 and I get the same problem. Since Carbon is also broken, I highly doubt that SWT is the culprit here.
Created attachment 150405 [details] screenshot of the same content assist running on Eclipse 3.5 I've tried my code unmodified on Eclipse 3.5 and the content assist popup appears where it should
Susan, looks like the change in ContentProposalAdapter for bug 256651 introduced this problem.
Created attachment 150406 [details] ContentProposalAdapter patch v1 If we go back to using map(Control, Control, Point), it seems to be fine.
thanks, Remy and David. I'll get this fixed before the M3 test candidate.
Fixed in HEAD >20091023. Will be released for Sunday's test candidate build (ie, I didn't tag especially for this fix). I'm really embarrassed about this regression. Thanks for reporting it David. I fixed about 5 field assist bugs that day and wrote a bunch of new automated test cases. But...my super-detailed testing involved a too-simple layout so that the parent mappings were 0 and this wasn't caught. I'll add better tests (and keep on manually sanity checking find and replace).
I should add that the test cases still pass and I verified that bug 256651 is still fixed.
(In reply to comment #15) > I'm really embarrassed about this regression. Thanks for reporting it David. > I fixed about 5 field assist bugs that day and wrote a bunch of new automated > test cases. But...my super-detailed testing involved a too-simple layout so > that the parent mappings were 0 and this wasn't caught. I'll add better tests > (and keep on manually sanity checking find and replace). Not to worry, it happens to the best of us. I look forward to trying it out. Thanks for the quick fix!
The Ctrl+F dialog looks fine to me on Windows XP with I20091027-0100. David, can you verify this on your Mac if you get a chance? Thanks.
Verified on Mac using Version: 3.6.0 Build id: I20091027-0100 Something else strange has come up: the first time a content assist field is used, a shell flashes on the screen and disappears almost instantaneously. It happens so fast that if you blink you'll miss it. It's very distracting. I'm not sure if that's related to this issue, a known issue or a new issue.
verified on WinXP and GTK/Ubuntu 9.04 on Build id: I20091027-0100. Marking verified.(In reply to comment #19) > Verified on Mac using Version: 3.6.0 > Build id: I20091027-0100 > > Something else strange has come up: the first time a content assist field is > used, a shell flashes on the screen and disappears almost instantaneously. It > happens so fast that if you blink you'll miss it. It's very distracting. > I'm not sure if that's related to this issue, a known issue or a new issue. Do you observe this on the find/replace dialog or is it in a Mylyn scenario only? I don't observe this on WinXP or GTK/Ubuntu. Can you open a new bug for this? If you are just noticing it, perhaps this has been introduced by recent changes. But it would be helpful to see if the problem is present on a plain 3.5.1.
(In reply to comment #20) > Do you observe this on the find/replace dialog or is it in a Mylyn scenario > only? I don't observe this on WinXP or GTK/Ubuntu. No, I don't see this on the find/replace dialog. BTW, it's not a Mylyn scenario that I'm testing. > Can you open a new bug for this? If you are just noticing it, perhaps this has > been introduced by recent changes. But it would be helpful to see if the > problem is present on a plain 3.5.1. Will do.
(In reply to comment #20) > Can you open a new bug for this? created bug 293489