mhttpd left hand menu does not register mouse clicks

Issue #74 resolved
dd1 created an issue

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)

  1. Stefan Ritt

    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?

  2. Thomas Lindner

    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.

    Screen Shot 2017-11-28 at 2.03.17 PM.png

  3. Stefan Ritt

    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.

  4. dd1 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.

  5. dd1 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.

  6. dd1 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.

  7. dd1 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.

  8. Stefan Ritt

    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.

  9. dd1 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.

  10. Stefan Ritt

    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.

  11. dd1 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.

  12. Stefan Ritt

    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?

  13. dd1 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.

  14. Log in to comment