Comment 454 for bug 263435

Revision history for this message
In , Igor-levicki (igor-levicki) wrote :

Idea with a webcam fails when a plugin takes whole window (PDF reader for example) -- user simply has nowhere else to look.

Problem here is that browser keyboard shortcuts (and thus keyboard navigation) simply do not work in the presence of plugins -- either at all, or as intended (see related Bug #627315 which I reported recently).

That problem is easy to solve by not passing reserved key combinations to plugins, at least those that I listed in Comment #424.

If some plugins break because of that then let those who use such plugins report a bug, and then kindly refer them to the web app developer who mindlessly (ab)used reserved key combination(s) when they wrote their web app.

In the meantime, work with plugin vendors and web app developers to define an API which would enable them to receive reserved keys if absolutely necessary and with user consent which will be remembered as a per-site preference. That is how it should have been done in the first place if anyone involved cared about user experience.

Instead, what we have for the last 10 years is a *kludge* that enables plugin vendors and web app developers to do whatever they want with keyboard events, and nobody is doing anything to fix it because both plugin vendors and web app developers got what they wanted -- they have no incenitive for a change because that change requires work on their end.

After 10 years, I believe it is about time to return (keyboard) control to the end user, because plugin vendors and web app developers have shown themselves as irresponsible and careless so far. They need to be brought into a position which will force them to act in order to get what they want, instead of having everything at their disposal by default.