Bugzilla – Full Text Bug Listing
| Summary: | [Compatibility] Debug views are empty when first opened | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | DJ Houghton <dj.houghton> | ||||
| Component: | UI | Assignee: | Remy Suen <remy.suen> | ||||
| Status: | VERIFIED FIXED | QA Contact: | Remy Suen <remy.suen> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | daniel_megert, david_williams, Mike_Wilson, ob1.eclipse, pinnamur, pwebster, remy.suen, thatnitind, tom.schindl | ||||
| Version: | 4.2 | ||||||
| Target Milestone: | 4.2 M4 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
DJ Houghton
Oops, thought I opened this already bug didn't find it when I first searched. Sorry for the noise. *** This bug has been marked as a duplicate of bug 338955 *** (In reply to comment #1) > Oops, thought I opened this already bug didn't find it when I first searched. > Sorry for the noise. > > *** This bug has been marked as a duplicate of bug 338955 *** I'm going to reopen this bug as I'm not currently convinced that they are the same problem. They might be but I'll have to step through the code to check. Wow, this bug is increasingly annoying. ;-) Is this problem "permanent" in that it doesn't go away until you restart? Or is it that sometimes you switch perspectives the views are populated but other times when you switch perspectives they're not populated? I've noticed it when I start Eclipse and bring focus to a view which is in a stack (but not on top), it is empty. I can fix it (until next startup) by giving another view in the stack focus and then switching back. I only use a single perspective so I haven't noticed the behaviour when switching perspectives. (In reply to comment #5) > I've noticed it when I start Eclipse and bring focus to a view which is in a > stack (but not on top), it is empty. If it's a view that is on top on startup, then I can see why it would be empty. I'll need to investigate this more though since you say the view is not on top on startup. Created attachment 192466 [details]
deltas.xml
Here is my deltas.xml file. This morning I had the same problem when switching to the Breakpoints view.
*** Bug 338955 has been marked as a duplicate of this bug. *** Event handlers are supposedly notified based on service ranking order. If we want the renderers to always be notified of events first then they need to handle events first before we forward them out to other consumers. Since the notification ordering is currently "random", the problem is not 100% reproducible. What is the ordering issue here ? I have no problem believing that we likely need some ordering control on the event listeners but how is this affecting whether the contents of the part get displayed ? (In reply to comment #10) > What is the ordering issue here ? OSGi event handlers are notified in a non-deterministic way. Well, they could be by service ranking order but we don't use that right now anyway since the broker just throws them in as-is. > I have no problem believing that we likely > need some ordering control on the event listeners but how is this affecting > whether the contents of the part get displayed ? If a handler for checking when parts have become the selected element of a stack is notified before the renderer is, then the part will not have been rendered yet and presumably should not try to display anything. *** Bug 338456 has been marked as a duplicate of this bug. *** Well, I guess we can forget about the service ranking thing... ----- Remy Suen: Should an EventHandler with a higher serivce ranking be guaranteed to be notified of events first? Thomas J. Watson: I don't think that is spelled out in the specification. I know the impl does not sort the order in which the handlers are called. (In reply to comment #9) > Event handlers are supposedly notified based on service ranking order. If we > want the renderers to always be notified of events first then they need to > handle events first before we forward them out to other consumers. > > Since the notification ordering is currently "random", the problem is not 100% > reproducible. Probably use two different events? Something like "part needs to rendered" vs "part has been activated". I've made a slight tweak to the part service to "enforce" rendering of parts in the event that the renderer doesn't do the job properly (doesn't have its own listeners). This should help alleviate the problem. If you are still seeing this problem with the latest build (today is May 13th), please ping on this bug. Using I20110526-1435, I started Eclipse, had some breakpoints, hit F11, when the breakpoint hit and the perspective switch was triggered, the 'Variables' view was empty. As expected, clicking the 'Breakpoints' view and then back fixed the problem. I've started seeing this again. First in the Variables view yesterday when debugging. Then today when I started up Eclipse the Breakpoints view was empty. I'm using: Eclipse SDK 4.2.0.I20111108-2200 This seems to be happening consistently for me on every startup. The Breakpoints view is showing but empty. I'm using the same build as in the previous comment. I won't update builds until I talk to Remy or Paul. DJ, do you see this problem during regular use or only on startup? Though I expect you may also see it if you make a new workbench window (startup-ish code). I believe that it is only on started or when a view is first activated in a session. I've fixed the startup problem. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=40367ebc94e9431896b75c2d6780831975cb873b I think there may be problems in a new workspace with a fresh debug session, taking a look... (In reply to comment #22) > I think there may be problems in a new workspace with a fresh debug session, > taking a look... This looks okay to me right now. The startup case seems okay with I20111208-0200 on Windows 7. |