Fix back/forward navigation using dedicated mouse/keyboard buttons.

[ghost]

PR Checklist

Please check all that apply to this PR using "x":

• I have checked that this PR is not a duplicate of an existing PR (open, closed or merged)
• I have checked that this PR does not introduce a breaking change
• This PR introduces breaking changes and I have provided a detailed explanation below

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting)
• Refactoring (no functional changes)
• Documentation changes
• Other - Please describe:

Fixes

Issue Number: none

What is the current behavior?

The LBRY app does not navigate backward or forward when using the dedicated back/forward keyboard or mouse buttons.

What is the new behavior?

Back/forward keyboard and mouse buttons cause the LBRY app to navigate backward/forward.

Other information

The handlers for the 'navigate-backward' and 'navigate-forward' events introduced in #2250 look like they were removed at one point. So instead of firing those events upon receiving the back/forward app-command, I've rewritten it to call the window's WebContents goBack and goForward methods.

Tested on Windows 10 x64.

[tzarebczan]

Hey @jcamp0x2a , thanks for the PR! My app seems to work fine with mouse forward/back on Windows and Linux. The keyboard buttons do not. Are you sure this is an issue?

Can we show you some apprecation for your contribution?

[ghost]

Hi @tzarebczan , thank you for the timely response.

It's interesting... I tested the version without my changes with another mouse, and the buttons do indeed work. I also reverted the custom bindings for my main mouse (an Elecom trackball), and the default back/forward buttons work again.

This is my first time working with Electron, but if I were to hazard a guess, it would be that the LBRY app or the browser instance (Blink?) inside Electron itself is explicitly handling mouse buttons 4 and 5 to trigger back/forward navigation. Whereas, the keyboard keys and my rebound mouse are sending the back/forward app commands, not clicks of mouse button 4 or 5.

I've tested my changes again and verified that the standard mouse's back/forward buttons still work, so that functionality remains intact with the gain of being able to use the keyboard keys, rebound mouse buttons, and other possible input methods like accessibility tools.