Bugzilla – Full Text Bug Listing
| Summary: | [UI] Cannot enter search in events table | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] Tracecompass | Reporter: | Genevieve Bastien <gbastien+lttng> | ||||
| Component: | TMF | Assignee: | Project Inbox <tracecompass-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Project Inbox <tracecompass-inbox> | ||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | matthew.khouzam, patrick.tasse | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 4.2.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| See Also: |
https://git.eclipse.org/r/#/c/134021/ https://git.eclipse.org/r/134021 https://git.eclipse.org/c/tracecompass/org.eclipse.tracecompass.git/commit/?id=21dc41faa695557a50d8b8511f0d778f5a99028d https://git.eclipse.org/r/134352 https://git.eclipse.org/c/tracecompass/org.eclipse.tracecompass.git/commit/?id=8faaaded4e5d029bb7342cd92cca4c37ac76ce9c |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Genevieve Bastien
It is still possible to type-in the text and apply it for the search but the text box is not visible on obsolete GTK versions. *** This bug has been marked as a duplicate of bug 536851 *** Created attachment 276917 [details]
Screenshot of events table
I'm not sure it's the same bug, see attached screenshot. The header row is very visible, I try to click on it, type in it, it does not edit the row, nor does it search if I try hitting Enter after entering something. This is what I have in the About section: org.eclipse.swt.internal.gtk.theme=Greybird org.eclipse.swt.internal.gtk.version=3.22.30 though my setup is used to have SWT_GTK3=0 somewhere, I'm not sure it does anything anymore. But I saw the same thing yesterday on someone else's computer. Also, the Snippet from the bug you linked works fine here, it's just the events table. (In reply to Genevieve Bastien from comment #3) > I'm not sure it's the same bug, see attached screenshot. The header row is > very visible, I try to click on it, type in it, it does not edit the row, > nor does it search if I try hitting Enter after entering something. This is the same thing I see, except that when I press Enter the typed word is put in the header row in green and search happens? > This is what I have in the About section: > > org.eclipse.swt.internal.gtk.theme=Greybird > org.eclipse.swt.internal.gtk.version=3.22.30 > > though my setup is used to have SWT_GTK3=0 somewhere, I'm not sure it does > anything anymore. But I saw the same thing yesterday on someone else's > computer. GTK 2.x is no longer supported at all by SWT starting in 4.10 / 2018-12. (In reply to Patrick Tasse from comment #5) > (In reply to Genevieve Bastien from comment #3) > > I'm not sure it's the same bug, see attached screenshot. The header row is > > very visible, I try to click on it, type in it, it does not edit the row, > > nor does it search if I try hitting Enter after entering something. > > This is the same thing I see, except that when I press Enter the typed word > is put in the header row in green and search happens? When I press enter, nothing happens here, no search, no green header :( This target update is the guilty one for this bug: 5c6a44b176f1319bb91946a2f6a9331524aca532 As an additional note, I experience this problem on a Debian machine, with GTK 3.24.1 (xfce), also on Ubuntu beaver machine with gtk 3.22.30 (gnome). I removed all the SWT_GTK3=0 in my environments. Could you debug a bit to see if the mouseDown() in TmfEventsTable.createHeaderEditor() executes correctly and if the keyPressed() on the table editor control (Text) handles the SWT.CR? If you can confirm that it works with GTK 3.24.1 on early target, it might be a regression in the Platform...? This is a legit fail since last week. By debugging, there seems to be a NPE in the o.e.swt.widgets.Control class here line 1066: /* Bug 540002: Showing and hiding widget causes original focused control to loose focus, * Reset focus to original focused control after dealing with allocation. */ if (focusControl != null && display.getFocusControl() != focusControl) { focusControl.setFocus(); } The control looses focus, but the display field is null, so the focus does not come back. When I try it with GTK 3.10.8, GTK.gtk_widget_get_visible returns true at line 1056 so I don't get in that branch. (the widget is not really visible but that's another issue...). Are you saying that 'display' is null at line 1069? And if it was not at line 1057, that would mean that the widget got disposed in the middle? Or is it 'focusControl' that is null?
> Are you saying that 'display' is null at line 1069? And if it was not at
> line 1057, that would mean that the widget got disposed in the middle?
Yes it's the second display that is null. I just tried with master, the bug is still there. Indeed I put a breakpoint in the lostFocus and some events seem to have a *Disposed* element in them. Not sure it that means it's been disposed in between?
(In reply to Genevieve Bastien from comment #12) > > Are you saying that 'display' is null at line 1069? And if it was not at > > line 1057, that would mean that the widget got disposed in the middle? > > Yes it's the second display that is null. I just tried with master, the bug > is still there. Indeed I put a breakpoint in the lostFocus and some events > seem to have a *Disposed* element in them. Not sure it that means it's been > disposed in between? master of org.eclipse.swt Oh I think I might know what's happening here... The Text is not visible yet, and this GTK 3 code needs to show it so that it can be resized, then it is hidden. My bet is that when we hide the Text it loses focus, and when that happens TmfEventsTable will dispose the Text from the FocusListener in updateHeader() or applyHeader(). That code is intended to quit editing when you click out of the Text box. That could be fixed in TmfEventsTable by handling focusLost only if the Text is visible, otherwise it's these SWT initialization shenanigans. (In reply to Patrick Tasse from comment #14) > Oh I think I might know what's happening here... > > The Text is not visible yet, and this GTK 3 code needs to show it so that it > can be resized, then it is hidden. > > My bet is that when we hide the Text it loses focus, and when that happens > TmfEventsTable will dispose the Text from the FocusListener in > updateHeader() or applyHeader(). > > That code is intended to quit editing when you click out of the Text box. > > That could be fixed in TmfEventsTable by handling focusLost only if the Text > is visible, otherwise it's these SWT initialization shenanigans. I collisioned your reply, but that's exactly what is happening, so good news! _We_ can fix it! No need to update gtk or swt. Gerrit change https://git.eclipse.org/r/134021 was merged to [master]. Commit: http://git.eclipse.org/c/tracecompass/org.eclipse.tracecompass.git/commit/?id=21dc41faa695557a50d8b8511f0d778f5a99028d New Gerrit change created: https://git.eclipse.org/r/134352 Gerrit change https://git.eclipse.org/r/134352 was merged to [stable-4.2]. Commit: http://git.eclipse.org/c/tracecompass/org.eclipse.tracecompass.git/commit/?id=8faaaded4e5d029bb7342cd92cca4c37ac76ce9c |