© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Let's not bicker and argue about who killed who...
let's try to be humble and constructive for a while.
The main problem has not been solved for 10 years because it is fundamentally complex and partly out of the developers' reach. This is understandable.
The users, on the other hand, are very eager to get rid of the problem's symptoms because they are very annoying. This is also understandable.
To be realistic, the main problem will probably not be solved in several years - but note that the users don't primarily want a solution to the problem, they primarily want to get rid of the *symptoms*! Some of these can be avoided even long before there exists a solution to the main problem, even if it doesn't help at all in finding that solution.
To take the car with the broken cooling system as an example again:
The mechanic wants to fix the cooling system, otherwise the car is not considered functional from his/her point of view, but due to missing components the repair has to wait.
The owner, on the other hand, primarily needs a car that can be driven, even if it means driving slowly for a minute with the hood open and then stopping to cool the motor down for 5 minutes. This car is worth much more than a car that stands still waiting for the perfect repair, even if both of them are considered just as non-functional from the mechanic's point of view.
What I'm aiming at here is that *workarounds* are getting more and more important.
* On a 10-year perspective, I'd prefer to have this bug solved by having the webcam track the user's eyes, and only pass key events to the plug-in when the user looks at it. It's a logical and handy solution and I'm sure that it is doable in that timeframe. (What I'm not sure about is whether Chrome will be the only existing browser left to make use of it, or if Firefox is still around.)
* On a somewhat shorter perspective, I'd prefer a solution where key events are only passed to the plug-in while the mouse pointer hovers it. It makes more sense than the current behaviour, and it doesn't raise as many standardization questions as other solutions. (Btw, it seems like some scroll events already work in this way, in some respect.)
* But first of all the behaviour should be improved as much as possible with workarounds, even if they are not at all part of a way to the solution of the main problem. For instance, the problems with focused plug-ins stealing key events can be made less annoying if Firefox actively removes the focus from the plug-in at various points in time, for instance when switching between tabs or windows, or when the user in other ways indicates that he/she doesn't currently use the plug-in.
Are there any specifications or design rules or users that demand that the plug-in should keep its focus in all such cases? Probably not. Please discuss and vote for the workaround Bug 625806 to handle tab/window switching in a better way, and please discuss and vote for the workaround Bug 625808 to simplify for the user to take focus from a plug-in. Moreover, the very annoying lost scroll events mentioned in parenthesis above seems to be handled in Bug 483136, so please discuss and vote for that one too. None of them solves this (unsolvable) bug, but it reduces the user annoyances from it. Also suggest other workarounds that you can come up with, even as suggested add-ons. Thank you.