Player prevents other elements on the page from being focused

[cheap-glitch]

Your environment

• Version used: 0.9.3.162
• Platform used: JavaScript
• Rendering engine used: SVG
• Browser Name and Version: Firefox & Chromium
• Operating System and version (desktop or mobile): ArchLinux
• Link to your project: https://www.theguitarlickdatabase.com

Expected Results

Until now, when a tab was created with an associated soundfont, the alphatab player would integrate well within the page and interaction with other elements was unhindered.

Observed Results

The player steals the focus permanently and thus prevents other elements, such as text inputs, text areas and select menus from being interacted with. Weirdly, buttons, checkboxes and radio buttons seems unaffected.
Live example : https://www.theguitarlickdatabase.com/lick/30

This must have happened a few updates ago, because before that everything was working fine. Also, this only occurs when a soundfount is loaded along with the tab, so simple tabs without a playback don't cause that problem.

EDIT: after some investigating, it appears the bug first happened in version 0.9.3.158

Steps to Reproduce (for bugs)

Create a web page with a few form elements and a tab with playback activated.

[Danielku15]

I cannot reproduce this issue on Chrome and Firefox on Windows. I can interact fine with all items on your page. Are you sure that this is not an issue of the Linux versions of the browsers you use or the code of your website itself? I would not remember any changes that can affect directly the focus of form elements.

One thing I could imagine is, that something with the CSS on your page is not fully correct and some of the "click overlays" that are used for the user interaction (selection, seeking) is overlapping your form controls. Have you tried reproducing it in a minimal environment as you describe it in the reproduction steps?

Could you check in the developer tools if maybe some elements are misaligned as I described it?

[cheap-glitch]

My bad, the live example I provided is no longer relevant since I downgraded to 0.9.3.157, where the bug is absent.
It could be some other CSS or JS on the page acting up, but I did try with the exact same code, only switching between different versions of alphatex, and the problem occurred at 0.9.3.158 and further -- before that it worked fine.
I will try to reproduce this as minimally as possible, with the latest build.

[Danielku15]

My bad, the live example I provided is no longer relevant since I downgraded to 0.9.3.157, where the bug is absent.

Ah, okay. You could try to make a fiddle on JsFiddle or CodePen as a standalone sample. If it is not reproducible there, it might be a side effect of something else on your page.

Unfortunately BrowserStack has no Linux VMs for testing, Only Windows, Mac and Mobile. If the problem persists for you, I will need to setup a VM to dig deeper.

Edit 1

I checked the history between the 2 versions and there was a bigger rework on the API layer merged at that time. #219
I was able to reproduce the issue. It looks like there is an error on how the mouse events are hooked up. I will fix it asap.

[Danielku15]

Fixing notes:
The mouse events are always attached to the browser window. The preventDefault that is called on the selection logic, prevents then most of the website interactions.

alphaTab/Source/AlphaTab.JavaScript/UI/HtmlElementContainer.cs

Line 106 in 35992a3

public event Action<IMouseEventArgs> MouseDown

In the old code the mouse events were hooked up to the canvas element directly.

[Danielku15]

I changed the event registration for the mouse handlers. I gave it some basic tests and functionality seems to be as before but without the issue of the form elements being blocked.

Please give version 0.9.3.164 a try.
Demo: https://fiddle.jshell.net/danielku15/p5fqk97c/show/

[cheap-glitch]

The bug is indeed gone. Thanks a lot!