site: fix firefox bug

[ukane-philemon]

I investigated the issue resulting in #1808 and found out firefox and chrome behave differently on mousedown events.
I think the issue lies in the fact that Firefox triggers 3 events (onmousedown, onmousedown, onchange) instead of 2 (onmousedown, onchange) like Chrome does. The last onmousedown will have the screen coordination value of the event set to zero(cause the last mouse event is actually right in the Element?). Closes #1808.

Reference 1: w3c uievents #201

[chappjc]

This only happens on master, not release-v0.5, so it seems clear it's the recent wallet page restyling, but I don't understand why. There doesn't seem to be any difference with mouseInElement or the mousedown binding in wallets.ts.

[chappjc]

I'm going to investigate too, but @buck54321 your input is probably needed to discern why this is a problem on master but not release-v0.5, or if this is the best fix.

[buck54321]

I think the issue lies in the fact that Firefox triggers 3 events (onmousedown, onmousedown, onchange) instead of 2 (onmousedown, onchange) like Chrome does.

It's actually because firefox fires a mousedown event for the click on the <option> element, and chrome doesn't. Could you instead do something like

static mouseInElement (e: MouseEvent, el: HTMLElement): boolean {
  if (e.target && (e.target as HTMLElement).tagName === 'OPTION') return true
  ...

so it seems clear it's the recent wallet page restyling, but I don't understand why

Before re-styling, I don't think we were hiding the form when you clicked outside. It wasn't a modal dialog.

[ukane-philemon]

It's actually because firefox fires a mousedown event for the click on the element,

So I guess this behaviour only affects the <option> element? Firefox fires one mousedown event for the click on the element, and another for select.

[buck54321]

In my tests, it was the option element that had the zeroed coordinates. Please do verify.

[ukane-philemon]

In my tests, it was the option element that had the zeroed coordinates. Please do verify.

Yes, I can verify. That was why I added this line. @buck54321, can we have this check with your suggestion? zeroed coordinates could come from somewhere else.

|| (e.pageX === 0 && e.pageY === 0)

[chappjc]

Seems like we're overthinking this.

  static mouseInElement (e: MouseEvent, el: HTMLElement): boolean {
    return el.contains(e.target as Node)
  }

[buck54321]

Nice find. That should work, with a couple of caveats.

1. You probably need to check if the target is the element itself, otherwise that click padding would become ineffective. Something like

return el === e.target || el.contains(e.target as Node)

2. This would fail if we had an element that's not a descendant absolutely positioned over the form. I'm not sure that we do that with anything but tooltips, so it probably won't matter to us.

[chappjc]

1. You probably need to check if the target is the element itself, otherwise that click padding would become ineffective. Something like

https://developer.mozilla.org/en-US/docs/Web/API/Node/contains

contains covers self, apparently:

The contains() method of the Node interface returns a boolean value indicating whether a node is a descendant of a given node, that is the node itself, one of its direct children (childNodes), one of the children's direct children, and so on.

Note: A node is contained inside itself.

It also doesn't seem to be related to position, just DOM hierarchy.

[ukane-philemon]

contains covers self, apparently

yeah, your suggestion is efficient.

[JoeGruffins]

Can confirm the bug and this fixes it.