| Summary: | Widget is disposed error if I run the Copy Build ID to clipboard | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Lars Vogel <Lars.Vogel> |
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | arunkumar.thondapu, bsd, daniel_megert, Lars.Vogel |
| Version: | 4.5 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 433746 | ||
| Bug Blocks: | |||
|
Description
Lars Vogel
After a restart of the Eclipse IDE, I'm not able to reproduce it anymore. Setting to worksforme. Happens again regulary in Build id: N20150425-1500 Verified it works for me on Ubuntu 12.04 and Ubuntu 14.04 with I20150428-0100. Please test with the latest I-build and confirm. (In reply to Arun Thondapu from comment #3) > Verified it works for me on Ubuntu 12.04 and Ubuntu 14.04 with > I20150428-0100. Please test with the latest I-build and confirm. I still get this error on a regular basis with Build id: I20150428-0100 (In reply to Lars Vogel from comment #4) > (In reply to Arun Thondapu from comment #3) > > Verified it works for me on Ubuntu 12.04 and Ubuntu 14.04 with > > I20150428-0100. Please test with the latest I-build and confirm. > > I still get this error on a regular basis with Build id: I20150428-0100 I cannot investigate this further because no matter how many times I try it, it always works for me, so it looks like there is some prior sequence of events that is causing the exception in a particular scenario. Moreover, I don't even see how this can be fixed in SWT since the widget is somehow getting disposed from the UI code itself and needs to be handled there... assigning back to UI for further investigation. It sounds like a dupe of bug 433778 where the shell returned is the shell of the Quick Access drop-down, where it's sometimes disposed before the handler executes: clipboard = new Clipboard(HandlerUtil.getActiveShell(event) .getDisplay()); My guess is that the recent change to the Quick Access like bug 433746 or bug 449485 may have perturbed the execution context? We can fix the immediate symptom with: clipboard = new Clipboard(PlatformUI.getWorkbench().getDisplay()); The handler is still somewhat problematic in that it assumes it's executing on the SWT thread. It seems strange to me that we set the commandProvider's execution snapshot in SearchField's text #focusGained method. Shouldn't this be done once, during the widget creation when the active shell is the window? (In reply to Brian de Alwis from comment #7) > It seems strange to me that we set the commandProvider's execution snapshot > in SearchField's text #focusGained method. Shouldn't this be done once, > during the widget creation when the active shell is the window? Oops, of course this is the right place: we need to set the context when the user clicks into the search text field. Aha, I think I have it: bug 433746 removed the shell-closed listener which called QuickAccessContents.doClose() which reset the different providers. CommandProvider#reset() tossed the context snapshot. Since the providers are now not being reset, the CommandProvider's context snapshot isn't being updated and so you're executing CBI with a stale context. Like Arun I cannot reproduce this and #doClose is actually called:
Thread [main] (Suspended (breakpoint at line 160 in SearchField$2))
owns: RunnableLock (id=7519)
SearchField$2.doClose() line: 160
SearchField.checkFocusLost(Table, Text) line: 453
SearchField$3$1.run() line: 213
...
Also, when using 4.5 M6, the Copy Build ID isn't working sometimes (no exception though).
So, please provide steps starting off a new workspace that allow to reproduce the problem using http://download.eclipse.org/eclipse/downloads/drops4/I20150429-2000/
Thanks.
If someone can reproduce this we might consider it for RC2 or RC3, but for now moving to 4.6. Mass move to 4.7 as M7 is approaching. Please move back in case you are planning to fix it for Neon. Lars, please reopen if you can still reproduce this using 4.6 M6. (In reply to Dani Megert from comment #12) > Lars, please reopen if you can still reproduce this using 4.6 M6. Happens sometimes, unfortunately not reliable reproducable. Will reopen if I find the cause. |