Bug 512683

SUMMARY
When interacting with an item that detects and utilizes mouse buttons, the three common buttons (left, right, middle) work as expected. However, mouse buttons 4 and 5 (two common supplementary side buttons) are not recognised, nor are any buttons beyond 5.

STEPS TO REPRODUCE
1. Own a pointing device capable of producing button events beyond the third, or a program that can emulate this
2. Navigate to this page (preferably opening in a new tab): https://muzikbike.github.io/tests/mouse-button-recognition/index.html
3. Aim the cursor at the button on screen, and use each of the buttons on your mouse

OBSERVED RESULT
The left button produces value 0, the middle button produces value 1 and the right button produces value 2. Any other buttons have no effect whatsoever.

EXPECTED RESULT
The fourth mouse button would display 3, the fifth button 4, the sixth button 5, and so on depending on how many buttons your device has.

SOFTWARE/OS VERSIONS
Operating System: Kubuntu 24.04
KDE Plasma Version: 5.27.12
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.13
Kernel Version: 6.8.0-88-generic (64-bit)

ADDITIONAL INFORMATION
Other browser engines such as Chromium and Ladybird do recognise mouse buttons 4 and 5; there's also nothing in w3c's UI Events specification (https://w3c.github.io/uievents/#dom-mouseevent-button) indicating that values 5, 6 and so on (corresponding to mouse buttons 6, 7 and onwards) for MouseEvent.button shouldn't be handled (indeed MouseEvent.buttons is a 16-bit field, implying that up to 16 distinct buttons at least should work).

If page history exists in either direction, mouse buttons 4 and 5 will navigate back and forward, ignoring the preventDefault() specified in the script on the page which should block this action.