Opened 3 years ago

Closed 3 years ago

#365 closed bug (invalid)

Depth gadget and download window of OWB

Reported by: Samir Hawamdeh Owned by:
Priority: undecided Milestone: 5.0-2018R1
Component: undefined Version: 5.0-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:



This is an old issue, maybe present since the first releases ..

Sometimes happen that if the download window of Odyssey is for any reason placed under the main window of the browser, then sometimes there are problems in bringing it back to the front (in front of the main window of OWB) by pressing on the depth gadget of its window (download window)

When the gadget is pressed, the window will brought in front correctly however immediately afterwards it will automatically returns under the OWB main window

I need to repeat the operation 2 or 3 time before it decide to work

Steps to reproduce

  1. Open OWB and download something (not a few kb file preferably so you have time)
  2. During download put the main window of OWB in front, so to have the download window behind it
  3. After the download is finished try to put the download window in front the main OWB window by pressing its depth gadget … eventually repeat the operation few time in case it will works normaly at first step .. (sometimes it happen this too)

Expected results

Pressing deep gadget of download window should always work bringing in front of back the window by normally single clicking

Attachments (1)

FastView_Capture_T171211_101956.jpg (497.7 KB) - added by Samir Hawamdeh 3 years ago.

Download all attachments as: .zip

Change History (10)

Changed 3 years ago by Samir Hawamdeh

comment:1 Changed 3 years ago by Thore Böckelmann

All gadgets in the window's border, except the gadgets added by MUI itself, are under control of Intuition. If these don't behave as intended this is no MUI bug, because MUI doesn't even know when these gadgets are used in any way.

So if you click the depth gadget, then it is Intuition which moves the window to the front/back, not MUI.

The only exception is setting MUIA_Window_Open to TRUE twice. Then the second call will bring the window to the front and activate it. But this is something that is triggered by the application, not by MUI itself. And this feature is implemented in MUI since ages (> 20 years).

Do you have any "do this and that on certain mouse clicks" like Commodities running? Or perhaps a mouse which triggers the left mouse button more than once on a single click?

BTW, which "first releases" are you referring to? MUI? Odyssey? What?

comment:2 Changed 3 years ago by Samir Hawamdeh


Do you have any "do this and that on certain mouse clicks" like Commodities running?

Nothing special, after (or even during a download) i just put the download window "behind" the main window ..
As you see in the grab, to replicate the issue i mantain part of the download window visible in front so to be able to reach (aka click) its depth gadget

In this way i can replicate the issue frequently

Or perhaps a mouse which triggers the left mouse button more than once on a single click?

No Thore, but at first i though the same even if it looked strange to me considering that i have this problem only in this specific circumstance, however i did the test using another mourse but it's the same ..

BTW, which "first releases" are you referring to? MUI? Odyssey? What?

I noted the issue at the time of MUI 3.9 and the first port of Odyssey (the 1.9, that at the time had the old name —> Origyn Web Browser)

comment:3 Changed 3 years ago by Thore Böckelmann

I have downloaded approx 20 files by now but I am not able to reproduce this issue.

Whenever a download has finished and I click the download window's depth gadget it comes to front immediately and stays there. Absolutely no odd or wrong behaviour.

comment:4 Changed 3 years ago by Thore Böckelmann

I repeatedly tried to reproduce this issue but so far I cannot make MUI/Odyssey misbehave regarding window depth arrangement. All my tests were done on a quite plain AmigaOS4 installation without any 3rd party stuff running. So if you have any kind of patching application running in the background it would be a good idea to deactivate it for some time and try working without it.

As I said already, I cannot find anything suspicious neither in MUI nor in Odyssey which could cause (or at least explain) such a strage behaviour as you describe it.

comment:5 Changed 3 years ago by Hubert Maier

I can add to that, but probably not much…and i'm probably way off topic anywhere.

I know this behaviour from long ago (since at least 3.5 times iirc).
It kept popping up and vanished again, but i never bothered to check why it does that.

With the info provided by Thore in this report (about bakground programs) i finally found the time to check if i have something running in the background that could cause the mischief and even found a fix (at least for me).

1) It's not a problem of MUI (at least *i* can rule out MUI)
2) The issue is not persistant, it's a "comet bug" (coming and going) :-)
3) The problem (for me) was the "ClickToFront" commodity (that won't help Samir, because he already said that he hasn't got any programs in the background, but still it would be worth to check)

That commodity comes with a default setting of "IGNOREICONS" set to Yes which should "normally" ignore the depth and other window gadgets when clicked. It seems though that it, regardless of that setting, happily interacts with it and in light of that probable bug in "ClickToFront" it seems to me like a race condition when clicking the gadget and the window pops right back to the front, instead of staying in the back (or vice-versa).

[ The above is the only case where i *could* blame MUI, as *maybe* the "ClickToFront" commodity has problems interpreting a MUI window's gadgets (introduced with one of the many updates. Then again, as i said above, i know this behaviour from long ago, so i *won't* blame MUI) :-) ]

There is a fix (when using "ClickToFront", that is):
Turning off "IGNOREICONS" and instead setting "IGNOREBORDER" makes the behaviour go away for good, even with "ClickToFront" running.
Granzed, one needs to learn not to click on the borders to bring the windows to front, but hey, we are flexible, aren't we? ;-)

Oh and one final note…yes, i was using "ClickToFront" from more or less day one, so i know this behaviour from the day the OS introduced "ClickToFront" (not sure when exactly that was).

comment:6 Changed 3 years ago by Thore Böckelmann

Do you have ClickToFront running and have you tried Hubert's solution? For me his explanation it really sounds reasonable and would explain the issue quite logically.

comment:7 Changed 3 years ago by Thore Böckelmann

Any news on this issue?

comment:8 Changed 3 years ago by Samir Hawamdeh

Sorry for delay .. yes i've tried and in some sort i've come to the same conclusion of Hubert .. :-/
At this point we might rise a ticket for ClickToFront … Hubert what do you think ?

What we can write exactly for a good report ?

comment:9 Changed 3 years ago by Thore Böckelmann

Milestone: future release5.0-2018R1
Resolution: invalid
Status: newclosed

I'd say just copy the conversation from here or at least link to this ticket. It contains all the required information.

For me there is nothing left to do, hence I close this ticket.

Note: See TracTickets for help on using tickets.