-
assigned issue to
mhttpd left hand menu does not register mouse clicks
mhttpd left hand menu sometimes does not register mouse clicks. I click on "status" and nothing happens. Maybe 5-10% of the clicks do this. I click right into the middle of the letter "a" in "status". K.O.
Comments (16)
-
-
I tried ~100 times on OSX under Chrome and Firefox and had not a single issue. Can you teach me how to reproduce the problem?
-
I can reproduce this problem as well. I find that a portion of the buttons on the left menu are not active. I include a screen shot, where I'm trying to push the Status button. In that picture only the blue shaded part of the button is active; the darker grey section is inactive. This is true on MacOS with Safari and Firefox.
Maybe this is just how html buttons work. What is confusing is that the dark grey part of the buttons seems like it is active: my arrow becomes a finger when I move over the grey part.
As a comparison, on the bitbucket page left menu the entire button areas seem to be active, rather than just the central part of the button.
-
Good point. I changed the CSS file to have the whole area around the link being active. Can you test again (in develop) and close the item if it works for you.
-
reporter confirmed the insensitive are on macos safari is now fixed. my original problem - when I click on buttons (status, odb, etc) nothing happens. This occurs rarely, but often enough to be noticable and annoying. See it with google-chrome on Macos and Linux (ubuntu). Not surprised that you see it never. K.O.
-
reporter I wonder. If I press the menu button while an rpc request is on progress, what happens? Maybe that's when there is an appearance of a button push being ignored? This is what I see in the google chrome inspector: from the "status" page, when I press the (say) "messages" button, everything stops on a rejected promise from an rpc call - it looks like to leave the page, all on-flight rpcs have to be "failed" and we cannot leave the page until all exception handlers have run. is this what creates an illusion that menu button pushes are ignored? but no, what I see here consistently is changing pages after pushing the button is delayed. the original problem is that I see nothing happens at all. maybe it is a delay and I do not wait long enough? strange... K.O.
-
reporter some more. so from the "status" page I pressed the "start" button, everything stopped on the exception (rejected promise), I press the js debugger "continue" button and everything stops. I am still on the status page, the start page did not load and there are no rpc requests going to mhttpd. this is much closer to what I see in the original problem. only difference is the "loading page" spinner is spinning (but exactly nothing is going on, new page is not loading). K.O.
-
reporter confirm the invisible insensitive area between buttons is fixed for google chrome. what that it?!? I am pretty sure I always click in the middle of the button, without fail. K.O.
-
I can confirm that the problem with insensitve area is fixed for me on MacOS.
-
Not sure either what happens if you switch pages during an ongoing RPC request. I know that the new "fetch" API has an "abort" option. Maybe we should switch to that. Otherwise we should maybe carefully check which exception to ignore and which not.
-
reporter I still see sometimes I click on the buttons on the midas status page and nothing happens.
My current theory is that some web browsers sometimes somehow ignore mouse clicks when javascript is running.
A test for this is to add a javascript busy loop (eat cpu) in the status page and observe the page completely stop responding to mouse clicks.
K.O.
-
I believe it's not the load on the CPU, but the AJAX request in the background. Actually there is no "background" since JS runs in your browser in a single thread. So if the page is busy with something else, it cannot react on mouse clicks. I expect however that the mouse clicks are stored in the OS and delivered a bit later. To confirm that, you could add a delay statement in mhttpd of one second or so, forcing each AJAX request to take some time. Between the request and the callback, I expect the browser however to be responsive, since the AJAX return is handled in a callback.
-
reporter I think I understand why the "start" run button is often non-responsive (nothing happens when I click it) - it looks like the button is recreated on each update of the status page (1Hz rate). I guess if I click it during the update, nothing will happen. K.O.
-
That could well be. I changed the code on the status page so that it only changes this field when the run number of the button contents change. To me it looks fine now. Did the same with the "Restart: on/off" link, had the same problem there. Can you check again now?
-
reporter We have not seen this problem for some time now. I think it was caused by running “too much” javascript, making the browser unresponsive. K.O.
-
reporter - changed status to resolved
Fixed in midas-2019-09. K.O.
- Log in to comment