Bugzilla – Full Text Bug Listing
| Summary: | [Cocoa][10.14] Unified toolbar: returns excessively large size | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thomas Singer <eclipse> |
| Component: | SWT | Assignee: | Thomas Singer <ts-swt> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | lshanmug, olivier.prouvost, ts-swt |
| Version: | 4.9 | ||
| Target Milestone: | 4.18 | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| See Also: |
https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/168130 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=962bc418d30aec9515bcaa34cdcc0b659009c8a2 |
||
| Whiteboard: | |||
It boils down to the Toolbar.layoutUnified method where the invocation NSRect [] containerRects = new NSRect[itemCount]; ... containerRects[i] = new NSView(itemViewers.objectAtIndex(i)).frame(); causes strange values in the NSRect's values. Converting these doubles to a long using Double.doubleToRawLongBits shows some interesting result: the width value reads 434c4e47432b2b00 which can be interpreted as CLNGC++. Multiple invocations produce different results: x: 7ffeef6f31d0 y: 7fff7ad7babb width: 434c4e47432b2b00 height: 107ba5e50 x: 7ffeef6f31d0 y: 7fff7ad7babb width: 434c4e47432b2b00 height: 1 x: 7ffeef6f31d0 y: 7fff7ad7babb width: 434c4e47432b2b00 height: 2 x: 7ffeef6f31d0 y: 7fff7ad7babb width: 434c4e47432b2b00 height: 3 x: 7ffeef6f31d0 y: 7fff7ad7babb width: 434c4e47432b2b00 height: 4 ... Does the code use ToolItem.setWidth(SWT.SEPARATOR_FILL)? Does changing it to SWT.DEFAULT fix the issue? No, for this problematic shell's toolbar no stretching toolitem is used. For a different shell's toolbar where a stretching toolitem is used, the problem does not occur. Can you try to create a SWT snippet to reproduce this issue? I wrote in my initial posting:
> Any effort to extract the problem in a tiny test snippet failed.
(In reply to Thomas Singer from comment #6) > I wrote in my initial posting: > > > Any effort to extract the problem in a tiny test snippet failed. It's hard to do anything in this case without a reproducible test case. Sorry, I only know the way to use SmartSVN 9.3 or 11 and opening the Log or Revision Graph window on macOS 10.14. You will need to use the original org.eclipse.swt*.jar files, because ours contain a work-around. New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/168130 Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/168130 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=962bc418d30aec9515bcaa34cdcc0b659009c8a2 |
When I'm running SmartSVN 9.3 from smartsvn.com and try to open the Log or Revision Graph it reliably causes an assertion. The reason is that the shell reports an excessively large width caused by the unified toolbar. Any effort to extract the problem in a tiny test snippet failed. While debugging the problem only occurs sporadically when using Continue, but never when debugging step by step ("heisenbug"). The amount of toolbar items seems to matter; with 5 equal items I could not reproduce (when running), but with 6 I could reliable (except of when debugging). see also bug 387864