Re: Key events conflict with browser

Okay changing it to keyup instead of keydown seems to have fixed the 
problem of the play/pause button getting toggled (at least in firefox) 
but the scrolling issue still exists.

On 09/30/2017 10:11 AM, Michael A. Peters wrote:
> I'm create a custom HTML5 audio interface that has support for chapters,
> captions, and subtitles. Browser audio interfaces don't, and able player
> is too difficult to modify for my needs as it requires a build system
> and in my past experience with javascript build systems, they often have
> components that want a newer version of node.js than my distribution
> ships with which in turn requires updating other libraries and I end up
> pulling my hair out.
>
> Anyway I'm building my own, and it is working very well.
>
> However - for chapter selection, I'm using a list that ordinarily is
> hidden. The current displayed chapter acts as a button that show the
> list and gives focus to the current chapter.
>
> Since some audios may potentially have numerous chapters, the list has a
> fixed height and uses overflow-y: scroll.
>
> That causes the first problem. When there are enough items to cause a
> scroll and I interpret keyCode for 38 or 40 to navigate the list, the
> browser then also scrolls the list which is not desirable.
>
> Is there a way to tell the browser not to?
>
> Second issue -
>
> After the user selects the chapter they want, I give focus to the
> play/pause button as that is the button that when it has focus has other
> keyCode events that do things like fast forward, rewind, and download.
>
> But it seems that the space and return keys, even though pressed before
> the play/pause button has focus, are then interpreted to toggle the
> play/pause button as well which is NOT desired.
>
> This doesn't happen when I click the chosen chapter with a mouse,
> play/pause still gets focus but doesn't toggle. Only when I use keyboard
> to select the chosen chapter from the list.
>
> Is there a way to clear the context of the return / space bar so it
> isn't interpreted by the play/pause button?
>
> I know both these issues would vanish with a select list but it seems
> browsers won't let me style a select list.
>
> I know accessibility is more important that aesthetics but it would be
> nice, if possible, to have both.
>

Received on Saturday, 30 September 2017 17:35:26 UTC