Bug 1350000
| Summary: | Motif drag-and-drop drawn incorrectly | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Peter Harris <pharris> | |
| Component: | openmotif | Assignee: | Carlos Soriano <csoriano> | |
| Status: | CLOSED WONTFIX | QA Contact: | Desktop QE <desktop-qa-list> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | high | |||
| Version: | 6.9 | CC: | cww, dpathak, goeran, jwright, lockerb, mwevers, pharris, pvrabec, tpelka, twoerner, vanhoof | |
| Target Milestone: | rc | Keywords: | Patch | |
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1392956 (view as bug list) | Environment: | ||
| Last Closed: | 2017-08-15 19:20:01 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1392956 | |||
| Bug Blocks: | 1269194, 1363705 | |||
| Attachments: | ||||
|
Description
Peter Harris
2016-06-24 18:56:12 UTC
Created attachment 1179344 [details]
Proposed fix: Disable XmPIXMAP mode for drag and drop
Re-attaching proposed fix (which appears to have been deleted).
I tried to reproduce this with motif-2.3.4 on a Fedora system and the demos in the motif source repo, but the icons are there and there are no issues with other windows. To verify this there is more information needed and also a reproducer. Which desktop is in use? Does it only happen with ico? What about DNDDemo or simpledrop from demos/programs/drag_and_drop? I will try to verify this on a RHEL-6 machine natively again. Created attachment 1183986 [details]
Blinking Drag and Drop icon with Centos7, GNOME3
Created attachment 1183987 [details]
Missing Drag and Drop icon with CentOS7, KDE, and a slight zoom
> Which desktop is in use? GNOME3, KDE with Magnifier enabled (see attached videos), or remote display to any of Ubuntu/Unity, SuSE/KDE, ETX/Windows, etc. > Does it only happen with ico? It happens with anything that draws to the screen during the drag. Ico is convenient because it draws constantly. In the videos, I used "watch date" in a gnome-terminal or konsole. > What about DNDDemo or simpledrop from demos/programs/drag_and_drop? demos/programs/drag_and_drop/DNDDemo does not reproduce this issue because it uses a small, square icon which puts Motif into Cursor mode. The bug is in Pixmap mode, so you need to use a demo that starts drag-and-drop with a rectangular or large icon. I used demos/programs/periodic/periodic in the attached videos. (In reply to Peter Harris from comment #4) > Created attachment 1183986 [details] > Blinking Drag and Drop icon with Centos7, GNOME3 On RHEL-7 I am not able to reproduce this with Gnome-Classic and also Gnome. The DnD icons are always visible while moving around in the periodic demo. (In reply to Peter Harris from comment #6) > > Which desktop is in use? > > GNOME3, KDE with Magnifier enabled (see attached videos), or remote display > to any of Ubuntu/Unity, SuSE/KDE, ETX/Windows, etc. > > > Does it only happen with ico? > > It happens with anything that draws to the screen during the drag. Ico is > convenient because it draws constantly. In the videos, I used "watch date" > in a gnome-terminal or konsole. > > > What about DNDDemo or simpledrop from demos/programs/drag_and_drop? > > demos/programs/drag_and_drop/DNDDemo does not reproduce this issue because > it uses a small, square icon which puts Motif into Cursor mode. The bug is > in Pixmap mode, so you need to use a demo that starts drag-and-drop with a > rectangular or large icon. I used demos/programs/periodic/periodic in the > attached videos. In KDE in RHEL-7 with desktop effect on or off, this is not happening. It only happens if the zoom is used. This is not an issue of motif in my opinion, but an issue with the magnifier. With the magnifier enabled, the normal mouse pointer is drawn over the DnD icon. Without the magnifier the normal mouse pointer is not visible at all. (In reply to Thomas Woerner from comment #8) > (In reply to Peter Harris from comment #4) > > Created attachment 1183986 [details] > > Blinking Drag and Drop icon with Centos7, GNOME3 > > On RHEL-7 I am not able to reproduce this with Gnome-Classic and also Gnome. > The DnD icons are always visible while moving around in the periodic demo. With the maginifier of Gnome there is a slightly different issuue. The mouse pointer is also drawn, but the DnD icon has an additional offset to the forced drawn mouse pointer. > On RHEL-7 I am not able to reproduce this with Gnome-Classic and also Gnome. > The DnD icons are always visible while moving around in the periodic demo. I sometimes have trouble reproducing that scenario too. It seems to be dependant on a certain amount of timing, and perhaps the video driver's choice of page flipping. Something that is usually easier to reproduce is "drag the icon over gnome-terminal". It leaves "mouse droppings" when entering or exiting the gnome-terminal, and the "watch date" will either erase the drag-and-drop icon when it's over the updating portion of the window, or it will freeze and stop updating (depending on whether or not Motif has done an XGrabServer). > This is not an issue of motif in my opinion, but an issue with the magnifier. I respectfully disagree. If you look at what's going on in the X protocol, Motif is drawing directly on the root window. This bypasses the normal drawing stream of a Composited desktop. From a protocol perspective, the icon doesn't exist. The magnifier is therefore unaware of the drag-and-drop icon (it can't possibly be aware) and erases it as a side-effect when zooming the rest of the desktop. > With the maginifier of Gnome there is a slightly different issuue. The mouse > pointer is also drawn, but the DnD icon has an additional offset to the > forced drawn mouse pointer. GNOME3 appears to use dirty rectangles to try to only update the portions of the screen that change, which makes the issue more difficult to reproduce. As you note, by bypassing the normal way to draw things, Motif is unaware of the zooming and draws the icon in both the wrong size and in the wrong location. By creating a SHAPE'd window (as in my proposed patch - which doesn't add anything, it just forces Motif to use a drag-and-drop drawing mode it already has and uses some of the time -- the only added lines in "diff -w" are updated comments), the magnifier can see the icon and draw it correctly. Even without a magnifier, GNOME3 sees the icon/window and draws a drop-shadow, which makes it look and feel more like the rest of the desktop. I agree, that the motif behaviour might or should be changed. But this needs to be done in motif upstream and in a way that will not break anything existing usage or application. I will contact ICS (motif upstream) about this and will try to make them aware of this. There seems to be an issue with bugs.motifzone.net, therefore I am not able to check which information is available in the upstream bug. Are you ok with sharing all information in this bugzilla with upstream in case it is not in the bugs.motifzone.net bug? Yes, I am okay with sharing all information in this bugzilla with anybody. Thanks. Red Hat Enterprise Linux 6 transitioned to the Production 3 Phase on May 10, 2017. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. The official life cycle policy can be reviewed here: http://redhat.com/rhel/lifecycle This issue does not appear to meet the inclusion criteria for the Production Phase 3 and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL: https://access.redhat.com This bug was reported (with patch) long before May 10, 2017. Therefore, I don't believe this bug should have been summarily closed. |