Cancel button doesn't respond when re-entering design list

In the current lab, after using the “U” and “D” keys to view the 2D structures, I click on designs to get back to the list mode. I used to be able to click on cancel while in the view,vote, sort window to bring up the list. It will no longer respond to my clicking on cancel. It sometimes makes a clicking sound when I just mouse over the button.  Using Chrome Ver.69.0.3497.100.

Note: This conversation was created from a reply on: EternaJS Problems.

1 Like

Hi Whbob,
When trying to reproduce this, it seems like occasionally I have to make a second click in order for it to register (though I’m having a bit of a hard time reliably making this happen). Does this seem to match with what you’re seeing?

No, when it works, the first click returns the list. When it doesn’t work, the cancel button letters will become brighter with a mouse over. Left clicking will turn the button yellow and produce a click sound without switching to the list page. Sometimes it will make a click sound by just hovering the cursor over the button. 
I see now that I also can not get the view icon to work when this happens.
I have tried looking at dev tools, but I don’t know how to set it up to look at mouse clicks.

In this case it’d be hard to do that anyways.

You don’t happen to see any errors (aside from the assertion errors when the page loads) do you?

Also, just to confirm the sequence of events:

  1. Load puzzle
  2. Click designs
  3. Click solution
  4. Click copy/view
  5. Use U/D a bunch of times
  6. Click designs
  7. Attempt to click cancel

Yes, confirmed.  

Did you see any additional errors?

No errors. My work around is to reload and the unfiltered list comes up.  

I’ve been having this problem the last three days, exactly as whbob describes. I click and click and click, usually takes 5-12 clicks to get the dialog box to close. I’m running Chrome on a Macbook and have tried restarting the laptop. I had this problem initially with JS, then it went away, now it’s back. No error messages.

I’ve played around with Chrome Dev Tools to try and locate where the cancel button mis directs, but I can only get so far and the Dev Tools won’t track anymore, it just jumps over the button handling stuff.

Looking at the html, there is a " div id “overlay” end div == $0" line.

When the cancel button is working, the div characters have their backgrounds flash a color briefly and the software brings back the list page ( makes the view/copy overlay disappear). 

When it doesn’t work, the view/copy overlay remains. Instead, there is a period at the end of the sentence in the banner that toggles highlighted when clicking the cancel button.

I haven’t been able to figure out how to step into the overlay div to see where it goes.

This “overlay div” and a “pixi container” div  are indented under a “maingame” div that reads like it might hide or expose a background image.

Today I had it failing to revert to the list, so in Dev tools, I highlighted the line that has the div id “overlay”… stuff and then clicked the cancel button and it works. Every time I highlight that line, it works.  Don’t highlight it, it fails to work. 

I’m puzzled why I can’t use the arrow cursor to hover over any of the buttons in the bottom row and see them come into focus. It seems like it is waiting for a click and then tries to figure out which button caused the event rather than letting the cursor arrow bring the button into focus and then go directly to the buttons event handler.

I see from the post below that Chrome is also hanging up for Dig.Embrace.

After talking the problem out with myself (above), I tried holding the left click mouse down for 3-4 seconds before releasing it ( mouse click up). It worked every time.

A fast click or double click or triple click  won’t work. The software needs time to run through the long list of events it is tasked to handle and find the cancel button event.

I hope this will work for any players that experience this problem.

That works. Thank you.

I’m puzzled why I can’t use the arrow cursor to hover over any of the buttons in the bottom row and see them come into focus. It seems like it is waiting for a click and then tries to figure out which button caused the event rather than letting the cursor arrow bring the button into focus and then go directly to the buttons event handler.

The buttons don’t show up in the inspector because they’re not actually HTML buttons - they’re simply graphics drawn onto the WebGL canvas like the rest of the game elements (with a mouse click triggering a check if the coordinates of the mouse fall within the bounds of a button). Eventually I want to migrate all the “UI”/overlay stuff in the game to be straight HTML, but this was the simplest method for the migration from Flash.

The software needs time to run through the long list of events it is tasked to handle and find the cancel button event

That’s not entirely accurate. The way JavaScript works is that once an event is fired, everything waiting for that event gets called with the same parameters, and no other JS can be run until all those methods are done running (it would just get added to a queue - that’s why a page might completely freeze, e.g. in the case of some Eternascripts).

When it doesn’t work, the view/copy overlay remains. Instead, there is a period at the end of the sentence in the banner that toggles highlighted when clicking the cancel button.

This I actually find quite interesting, though I have seen this happen while the button still works. I think this is just due to generally common behavior of double clicking in browsers though (if you double click somewhere on a webpage, it’ll generally highlight a bunch of the text on the page, even if you’re not double clicking the text itself).

A fast click or double click or triple click  won’t work. The software needs time to run through the long list of events it is tasked to handle and find the cancel button event.

While I can’t figure out why (or reproduce) just tapping the button would cause it to fail, clicking multiple times will definitely appear to cause issues - since the close button is actually above the design list, so if you double click it’ll close the window, but then open whatever design is under your cursor behind where the button was.

Just to verify - when you “fast” click the button, you don’t move your cursor, right? It is typical behavior that if you click down a button but don’t release the click over the button, it will “cancel” the click.

@lfp6 thanks for the explanation. When clicking (either fast or slow) the cursor never moves out of the cancel button.  Yes, I was just speculating what might be happening since I really don’t understand all that coding stuff. My idea to hold the mouse click down for a number of seconds before releasing it was a guess that the software needed to do some work before getting the mouse click up signal. That’s probably not what’s happening, but it works.  

Hey everyone! I’ve just finished some refactoring that should improve reliability of input handling. I think it should resolve this issue - could one of you that was having this issue before confirm whether it is still present or not?

Problem resolved for me. Thank you.

Working great! Thanks. Instant response when clear is clicked.