Summary: | [Qt] Shortcuts on webpages don't work if the Qt application has the same shortcut | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Benjamin Meyer <ben> | ||||
Component: | Platform | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED INVALID | ||||||
Severity: | Enhancement | CC: | ap, hausmann, jturcotte, kenneth, tonikitoo | ||||
Priority: | P2 | Keywords: | Qt, QtTriaged | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Benjamin Meyer
2009-08-11 10:20:21 PDT
Created attachment 34575 [details]
possible fix
Simon had some concerns about web apps being able to "overwrite" shortcuts. Would be good to see if the HTML5 have a say in this. These two arora bug reports look like they might also be for this bug: http://code.google.com/p/arora/issues/detail?id=515 http://code.google.com/p/arora/issues/detail?id=230 Comment on attachment 34575 [details]
possible fix
Seems we should have a manual-test for this. It should be possible to test in DumpRenderTree, but would likely require modification to DRT.
I agree that this change a test, even an autotest would be sufficient. But more generally speaking I admit I don't like this solution: shortcutOverrideEvent is not a substitute for handling key events. Handling it means accepting or rejecting the event, but not processing the actual keys. That belongs into keyPressEvent. But with this patch it is just a matter of time until someone complains that their application shortcuts are overridden by web pages, and that's harder to control and we have to tell them to re-implement shortcutOverrideEvent? I would prefer to see Arora handle its shortcuts in a re-implementation of keyPressEvents. Another option might be to make QWebPage's behaviour of overriding all shortcuts configurable. if i understood this bug correctly, I the path mozilla is taking to support this kind of situation: in bug https://bugzilla.mozilla.org/show_bug.cgi?id=448602 they implementing a way to verify if there is a default key listener for a given key (in this case control+s), but application could verify that before setting their own, avoiding conflicts in a safe way. we could consider implementing something similar in webkit ... Some more notes from looking things up: The documentation for ShortcutOverride is very slim and I am not exactly sure how it is suppose to be used, when it is called, or if this is even the Qt way to handle this bug. Looking through Qt's source it looked like when a widget overrides a global shortcut (like many do such as QLineEdit, QComboBox etc) they should handle this event saying that they should eat the keyevent and not allow a shortcut to. Is this correct? If we could know that there is a listener for a key without having to actually pass a key event then we could accept the event on ShortcutOverride without having to send the key event. This seems like the correct approach to solving this. Tested Safari and it behaves as expected; ctrl+s doesn't do Save As, but passes it to the DOM and GoogleDocs so there might be some code in WebKit already to handle this. Simon, you mentioned that Arora could handle its shortcuts in a re-implementation of keyPressEvents. To do this were you thinking to overload ShortcutOverrideEvent, always accept the event and then in the KeyPressEvent if the key isn't accepted walk up the parent tree find all QShortcut children, and test their QKeySequence if it matches call that shortcut and return? === Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines. |