Closed felmab closed 4 years ago
Hi @felmab the issue you are experiencing is not related to "tabindex", but to a wrong focus command included in the interface source code (init.js). This bug has already been fixed in the DEVELOPMENT version of 3DHOP, as you can see below (tabindex + text selected in FIREFOX + 3DHOP DEV):
Since both the projects you linked are using 3DHOP 4.2, my suggestion is to update your 3DHOP distribution, and then to check again (actually it is our fault, it's been a while since we last merged the DEV branch into the MASTER ... we hope to do it shortly).
Anyway, to answer your question, SpiderGL uses "tabindex" for internal routines related to its event listeners. As a result (but only in Chromium-based browsers), this setup can slightly influence the webpage behavior, moving the "focus" on the canvas when a user starts to interact with it, if it is not completely visible.
Let me explain: let pretend you are in this situation A (left image). When you click on the canvas the page automatically scrolls up to the top of the canvas, as in B (right image).
Even though this setup does not touch (and mess) the browsers "official" focus routine, nowadays these kinds of page controls aren't considered anymore a good thing in modern web design... But unfortunately SpiderGL begins to age, and some of its features are a little dated.
For this reason (but not only), in the next months 3DHOP will go through a renewal process, which will most likely include a serious reconsideration of the SpiderGL library.
However, this not means that temporary fixes will not be released in the meanwhile. So, stay tuned, and remember to keep your code updated with the latest 3DHOP DEVELOPMENT version!
Thanks @potenziani, I'll try to update to the latest dev version as advised.
SpiderGL adds the
tabindex="0"
attribute on the<canvas>
element. To begin with, in order to help us better understand this issue, what is the purpose of this?In Firefox (tested with version 74 under Archlinux and Ubuntu), but not in Chrome (more precisely Chromium), it seems this behaviour messes with focus, namely text selection disappears when the mouse button is released, and a select list does not remain open. This could be observed on our website up until now, but since I am going to implement a workaround (by removing the attribute later in JavaScript), here is another example. Manually removing the attribute when inspecting the code disables this behaviour. Although I tried to understand this interaction, I could find nothing on this topic which could explain this.