Community
Participate
Working Groups
I have a couple of Java editors open in the same tabbed pane. The funny bug is every second time I select another tab, the edittor in the first tab is actually selected. The outline shows the right file. "Open type" is broken as well, same with following hyperlinks.
Created attachment 215399 [details] Screencast showing the tab switching and hyperlink errors I've attached a small screencast demonstrating the bug.
Setting to blocker, as this is a real no-go.
Problem's gone after a restart. Let's see if it reappears...
Was this with 4.2 M7? PW
Version: 4.2.0 Build id: I20120503-1800 I've been working a lot with 4.2M6 before, the error never appeared.
Created attachment 215517 [details] Java Editor tab highlighted - manifest editor contents showed I think this screenshot may be related to Jan's issue - but I'm not sure whether this should go to a new bug report or not. FWIW, I exactly had the same problems Jan described with M7 several times this week on Mac. During the 1-week e4 training this seems not to happen on the customers' Windows 7/XP machines nor on Linux (12 machines) - at least no one complained about it.
I can not duplicate this. Jan, Marcel - do you remember by chance what were you doing before getting into this state? Adding Bogdan to CC on the off-chance that he can find a problem in the CTabFolder from a code inspection. Could it also be Mac-specific?
Something similar happened yesterday during workshop on a Windows7 machine. Double clicked on a new editor tab: Tab was selected and magnified but content pane showed previous content belonging to another tab.
(In reply to comment #8) > Something similar happened yesterday during workshop on a Windows7 machine. > Double clicked on a new editor tab: Tab was selected and magnified but content > pane showed previous content belonging to another tab. This behavior is also described on bug 380090
It turns out that this (and a few other) odd effects are the result of the fix made for bug 375576 (on 2012-04-30). We were spinning the SWT event loop (once) in various parts of WorkbenchPage, leading to the results we are now experiencing. We have tested the scenarios with these changes reverted and everything is much better. You can easily see the effect in action (especially on a Mac), just select multiple and open multiple files; in M6 this a 'clean' but in M7 it flashes all over the place...and ends up 'broken'. I'll remove the 'readAndDispatch' calls for now and we can look into another approach for bug 375576 (which I'll re-open) in 4.2.1.
Created attachment 216485 [details] Remove extra calls to 'readAndDispatch
It seems that the lines: if (partListenerList.size() + partListener2List.size() == 0) return; from the original fix are not reversed. They might make a difference for #firePartOpened() as the last statement will be skipped if there are no listeners: if (part instanceof IPageChangeProvider) { ((IPageChangeProvider) part).addPageChangedListener(pageChangedListener); } Is this a desired effect?
Created attachment 216490 [details] Updated patch that also reverts the list checks Oleg was sharp enough to determine that the checks could actually prevent the code at the end of 'firePartOpened' to execute if there are no other listeners...
+1 as component lead. Eric, could you or Silenio update the bug with results from him testing it on his mac? PW
+1, works for me on Mac and Windows.
commit 7df93988a8b50f3fdce6a6ca9f1928f1823afbc9 This reverts the WorkbenchPage code that was causing the issues on the Mac (and likely was unsafe on other systems as well).
Verified in I20120530-1900. I used the Mac in the SWT lab as well as having Silenio and Bogdan check on their machines. I've also smoke tested on Windows.
*** Bug 380090 has been marked as a duplicate of this bug. ***
