Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows not opening when XtPopdown/XtPopup commands are quick #734

Closed
linux-rocks opened this issue Jun 1, 2023 · 2 comments
Closed

Windows not opening when XtPopdown/XtPopup commands are quick #734

linux-rocks opened this issue Jun 1, 2023 · 2 comments
Labels
bug The issue exposes a bug.

Comments

@linux-rocks
Copy link

linux-rocks commented Jun 1, 2023

The functionality of opening/closing windows when running on Ubuntu 20.04 was not a problem (icewm 1.6.4)
We updated to Ubuntu 22.04 (icewm 2.9.6) and we experienced a host of problems:

  1. (info only) Crash when clicking on a data entry widget (which will go out of view when the scroll bar well is hit), then you click on an xterm, then click the scroll well which will scroll the window. Problem was a double free. Introduced in 2.6.0 but fixed in the latest build.

  2. When our software is issuing close/open windows we call:

    XtPopdown(shellWidget);
    XtUnmanageChild(_theMainMW);
    XFlush(XtDisplay(shellWidget));
    
    XtManageChild(_theMainMW);
    XtPopup(shellWidget, XtGrabNone);
    XtMapWidget(shellWidget);
    XFlush(XtDisplay(shellWidget));
    

Problem on 22.04 is that more than half the time, the windows won't open. When running xev on the window for 20.04 I see a ton of Xevents that show state of the window. When running 22.04, half of my Xevents are not showing up (all the mapping ones to open it).

We traced the bug introduction down to icewm 2.9.3 in file yxapp.cc. The problem he was trying to fix was to stifle the log but he also ended up stifling the sending of the xevent.

We pulled the desktop->handleEvent(xev); out of the ignorable if check and it works great. Tested with icewm 3.3.5 on Ubuntu 22.04.

Previous code in yxapp.cc handleWindowEvent:

} else {
    if (xev.type == MapRequest) {
        if (xev.xmaprequest.window != ignorable) {
            // !!! java seems to do this ugliness
            //YFrameWindow *f = getFrame(xev.xany.window);
            TLOG(("APP BUG? mapRequest for window %lX "
                  "sent to destroyed frame %lX!",
                xev.xmaprequest.window,
                xev.xmaprequest.parent));
            desktop->handleEvent(xev);
        }
    } else if (xev.type == ConfigureRequest) {
        if (xev.xconfigurerequest.window != ignorable) {
            TLOG(("APP BUG? configureRequest for window %lX "
                  "sent to destroyed frame %lX!",
                xev.xconfigurerequest.window,
                xev.xconfigurerequest.parent));
            desktop->handleEvent(xev);
        }
    }

Fixed code:

} else {
    if (xev.type == MapRequest) {
        if (xev.xmaprequest.window != ignorable) {
            // !!! java seems to do this ugliness
            //YFrameWindow *f = getFrame(xev.xany.window);
            TLOG(("APP BUG? mapRequest for window %lX "
                  "sent to destroyed frame %lX!",
                xev.xmaprequest.window,
                xev.xmaprequest.parent));
        }
        desktop->handleEvent(xev);
    } else if (xev.type == ConfigureRequest) {
        if (xev.xconfigurerequest.window != ignorable) {
            TLOG(("APP BUG? configureRequest for window %lX "
                  "sent to destroyed frame %lX!",
                xev.xconfigurerequest.window,
                xev.xconfigurerequest.parent));
        }
        desktop->handleEvent(xev);
    }
@gijsbers
Copy link
Collaborator

gijsbers commented Jun 2, 2023

Well thanks! This commit differs in that it wants to ignore duplicate map requests from destroyed clients.

@linux-rocks
Copy link
Author

We tested that fix and it works !!!!!
Thanks :)

@gijsbers gijsbers added the bug The issue exposes a bug. label Jun 9, 2023
@gijsbers gijsbers closed this as completed Jun 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue exposes a bug.
Projects
None yet
Development

No branches or pull requests

2 participants