Open Bug 311756 Opened 18 years ago Updated 6 months ago

Some "Warning: Key event not available on ..."

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

People

(Reporter: sgautherie, Assigned: neil)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [not needed for 1.9][Post "new" warnings in bug 427520, not here.])

Attachments

(2 files)

fischam-B-gone
885 bytes, patch
neil
: review-
Details | Diff | Splinter Review
Update warning message tests [Checkin: Comment 47]
1.25 KB, patch
jst
: review+
jst
: superreview+
damons
: approval1.9+
Details | Diff | Splinter Review 
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051008 SeaMonkey/1.1a]
(nightly) (W98SE)

{{
Warning: Key event not available on some keyboard layouts: key="f"
modifiers="control,alt"
Source File: chrome://navigator/content/navigator.xul
Line: 0

Warning: Key event not available on GTK2: key="d" modifiers="accel,shift"
Source File: chrome://navigator/content/navigator.xul
Line: 0
}}
(I'm getting them twice.)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051008 SeaMonkey/1.1a]
(nightly) (W98SE)

And some in MailNews:
{{
Warning: Key event not available on GTK2: key="a" modifiers="accel, shift"
Source File: chrome://messenger/content/messenger.xul
Line: 0

Warning: Key event not available on GTK2: key="c" modifiers="accel, shift"
Source File: chrome://messenger/content/messenger.xul
Line: 0
}}
(I'm getting them twice.)
The first one is strictly valid; Ctrl+Alt+F is reserved for Windows shortcuts.
The other three are technically invalid, as they're in platform overlays.
We can shut them up by adding a comma at the beginning of the modifiers.
this also happens in Mozilla Firefox!
Bug 312625 is for thunderbird but is otherwise identical.
Since this bug occurs for Firefox, Thunderbird, and Seamonkey the product should be changed to CORE. Also there should be a OS option for Windows-ALL but there isn't.

Bug 312625 references bug 240627 where bug 240627 comment 1 says:

"We could even ifdef out the assertion for non GTK2 builds"

but obviously didn't in the end.
(In reply to comment #2)
> The first one is strictly valid; Ctrl+Alt+F is reserved for Windows shortcuts.
> The other three are technically invalid, as they're in platform overlays.
> We can shut them up by adding a comma at the beginning of the modifiers.
So why not just do that?


*** Bug 312625 has been marked as a duplicate of this bug. ***
Assignee: general → aaronleventhal
Component: General → Keyboard: Navigation
Product: Mozilla Application Suite → Core
QA Contact: general → keyboard.navigation
bug 331379 may be a dupe of this one.
*** Bug 331381 has been marked as a duplicate of this bug. ***
(In reply to comment #7)
> bug 331379 may be a dupe of this one.

(That bug number is unrelated to the current bug.)

"Key event not available on GTK2"

We couldn't come up with a more descriptive message? How is anyone supposed to know what the heck that's about?
Assignee: aaronleventhal → neil
Where's the place in the code which triggers these? I'd write the patch myself if someone could just point me there. Comment 2 says this should be fairly easy.
Well for instance in the "f" key is the fishcam key in navigatorOverlay.xul
*** Bug 339140 has been marked as a duplicate of this bug. ***
OS: Windows 98 → All
Hardware: PC → All
Eyal in comment #11
> Where's the place in the code which triggers these? I'd write the patch myself

haven't found it yet, but AFAICT it is set up through the window creation process for compose and also main window (3-pane)


Aaron in comment #10
> "Key event not available on GTK2"
> 
> We couldn't come up with a more descriptive message? How is anyone supposed to
> know what the heck that's about?

good point. needs a bug?


misc info - bug 240627 comment 10


Neil in comment #12
> Well for instance in the "f" key is the fishcam key in navigatorOverlay.xul

Neil, which one of these? http://lxr.mozilla.org/mozilla/find?string=navigatorOverlay.xul

(In reply to comment #15)
>(In reply to comment #12)
>>Well for instance in the "f" key is the fishcam key in navigatorOverlay.xul
>Neil, which one of these?
>http://lxr.mozilla.org/mozilla/find?string=navigatorOverlay.xul
The one called navigatorOverlay.xul of course. See
http://lxr.mozilla.org/mozilla/find?string=/navigatorOverlay.xul
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070111 SeaMonkey/1.5a] (nightly) (W2Ksp4)

(Simple confirmation, as I hadn't used Trunk for a long time.)
(2*) 2+2 warnings still there.
(In reply to comment #2)
> The other three are technically invalid, as they're in platform overlays.
> We can shut them up by adding a comma at the beginning of the modifiers.

badly pollutes error console for windows users - making it more difficult to find legitimate problems.
I see the fischam thing here:

http://lxr.mozilla.org/mozilla/source/suite/browser/navigatorOverlay.xul#123

and that points to an invalid URL; shouldn't it just go away?

As for platform-specific overlays, I don't know which files I'm supposed to be looking at.
Attached patch fischam-B-gone — — Splinter Review 
The patch brought to you by the letter 'F'.
Attachment #252913 - Flags: review?(neil)
(In reply to comment #20)
> Created an attachment (id=252913) [details]
> fischam-B-gone

Removing the "C+A+F feature" would be related to bug 290235 / bug 344194.

Geez -- hard to believe anyone would want to continue with this antifeature, but those bugs both want to keep Fishcam in place, just fix it.
but, correct me if I'm wrong, it should be done in such a way that it doesn't integrate to thunderbird, where it just errors out in the js console
Instead of removing the fishcam we could just change the shortcut to something else. But then people would complain again... also, it seems the common thing about the rest of the problematic shortcuts is being accel+shift+hexadecimal_char , and the problem is that in Gtk these combinations are used to insert arbitrary unicode characters (you hold down ctrl and shift, and type in the hexadecimal value). So why should we get a warning about this in Windows, you ask? Good question. Neil thinks it's a good idea to warn extension developers who are using these shortcuts on Windows that it'll break on Linux; I disagree.

Also, I tried doing what Neil suggested and add a ", " before the modifiers of the misbehaving keys - but it seems the remove anchors key (ctrl+shift+a) doesn't even have shift as part of its modifiers - perhaps something sets this dynamically. So I'm kind of stuck for now.
[Mozilla Thunderbird, version 3 alpha 1 (20070128)] (nightly) (W2Ksp4)

(Reminder to self)
{
Warning: Key event not available on GTK2: key="f" modifiers="accel, shift"
Source File: chrome://messenger/content/messenger.xul
Line: 0

Warning: Key event not available on GTK2: key="c" modifiers="accel, shift"
Source File: chrome://messenger/content/messenger.xul
Line: 0

Warning: Key event not available on GTK2: key="a" modifiers="accel, shift"
Source File: chrome://messenger/content/messenger.xul
Line: 0
}
[Mozilla Thunderbird, version 3 alpha 1 (20070330)] (nightly) (W2Ksp4)

And
{
Warning: Key event not available on GTK2: key="a" modifiers="accel, shift"
Source File: chrome://messenger/content/messengercompose/messengercompose.xul
Line: 0
}
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070421 SeaMonkey/1.5a] (nightly) (W2Ksp4)

And
{{
Warning: Key event not available on GTK2: key="e" modifiers="accel shift  "
Source File: chrome://venkman/content/venkman.xul
Line: 0
}}
As I understand it this message really means "Dear End User, some time ago you installed an extension which uses a key shortcut combination which is invalid on one window manager of one platform we support. The extension developer didn't know that and we aren't going to even tell you which extension did the deed.  Have a Nice Day".

At least half of the silliness could be addressed by changing the error raised from the worthless-and-ought-to-be-banned nsIConsoleMessage to nsIScriptError so we can look at the site of the problem.  If we know what extension we can at least direct our suggestions in that area.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1

Key event not available on GTK2: key="c" modifiers="accel,shift"
chrome://browser/content/browser.xul
Line 0
Key event not available on GTK2: key="e" modifiers="control,shift"
chrome://browser/content/browser.xul
Line 0
Key event not available on GTK2: key="b" modifiers="accel,shift"
chrome://browser/content/browser.xul
Line 0
Key event not available on GTK2: key="d" modifiers="accel,shift"
chrome://browser/content/browser.xul
Line 0
I have to see these dumb messages about 20 times a day: isn't there any way to get rid of them?
The text of this message is in xbl.properties in the entry:
GTK2Conflict=Key event not available on GTK2...
So the first part of the bug -- the confusing message -- could be fixed by changing this entry to read something lke:
An extension is binding an event to a key combination which cannot be used on computers running GTK2; key="%S" modifiers="%S"

The message is created by a call:
ReportKeyConflict(key.get(), modifiers.get(), aKeyElement, "GTK2Conflict");
in nsXBLPrototypeHandler::ConstructPrototype() 
in the file nsXBLPrototypeHandler.cpp

The second part of the bug seems to be in ReportKeyConflict:
  nsIURI* uri = mPrototypeBinding ? mPrototypeBinding->DocURI() :
                aKeyElement ? aKeyElement->GetOwnerDoc()->GetDocumentURI() :
                nsnull;
I'm guessing the mPrototypeBinding->DocURI resolves to the target of the binding, eg browser.xul. That isn't helpful because we can only fix the problem at the source of the binding.  Maybe aKeyElement has that info, I don't know.

Actually, in this case mPrototypeBinding is probably null.  If it were not, you'd get its URI, which would be useful.  As it is, you're getting aKeyElement->GetOwnerDoc()->GetDocumentURI(), which is of course just the main browser XUL document.

See http://lxr.mozilla.org/seamonkey/source/content/xbl/src/nsXBLWindowKeyHandler.cpp for the likely source of these "XBL" keys.  They're just nodes in the XUL document.

What you really want here is the overlay the nodes came from.  Sadly, XUL doesn't preserve that information.
I wonder if most of these warnings (for gtk) aren't even false nowadays. See bug 269228 comment 11.) For instance, Ctrl+Shift+a which which it warns about - thunderbird's select thread - works just fine on trunk...
(In reply to comment #34)
> I wonder if most of these warnings (for gtk) aren't even false nowadays. See
> bug 269228 comment 11.) For instance, Ctrl+Shift+a which which it warns about -
> thunderbird's select thread - works just fine on trunk...
According to http://cvsweb.netbsd.se/cgi-bin/bsdweb.cgi/pkgsrc/x11/gtk2/PLIST (sorry if it's a bad link, that's what came up in a search) the key got changed in GTK2.9 and as we now require GTK2.10 the warning should use the new key.
* Fixed GTK2 to test against Ctrl+Shift+U
* Fixed Windows to test against Ctrl+Alt+Z
* Allowed upper/lower case in case bug 410186 lands again
Attachment #312725 - Flags: superreview?(jst)
Attachment #312725 - Flags: review?(jst)
If this message cannot be correctly connected to the code that a developer can fix it should not be issued. The message is a bug, no matter what keys trigger it.
Attachment #312725 - Flags: superreview?(jst)
Attachment #312725 - Flags: superreview+
Attachment #312725 - Flags: review?(jst)
Attachment #312725 - Flags: review+
Attachment #312725 - Flags: approval1.9?
What's the risk in taking this now?  When requesting approvals, please:

* Include an assessment of the risk associated with this patch.
* Give a sentence or two why it's so important to take your patch this late in the release process.
* Included tests so we don't have to ask for them.

Comment on attachment 312725 [details] [diff] [review]
Update warning message tests
[Checkin: Comment 47]

Please re-request approval once above questions are addressed.
Attachment #312725 - Flags: approval1.9?
Assignee: neil → nobody
(In reply to comment #39)
> * Include an assessment of the risk associated with this patch.

Nearly none: it only changes which key combinations trigger the warning.

> * Give a sentence or two why it's so important to take your patch this late in
> the release process.

Stops (now) false warnings with GTK2; adds more warnings with Windows.
Allows Trunk/Extension developers to be warned (only) in the relevant cases.

> * Included tests so we don't have to ask for them.

(This, I don't know how to do: helpwanted.)
Flags: wanted1.9.0.x?
Keywords: helpwanted
Thanks for letting me know the risk.  Really helps!


Comment on attachment 312725 [details] [diff] [review]
Update warning message tests
[Checkin: Comment 47]

I'm going to go ahead and a1.9+ this as it's simply an update to the warning messages.
Attachment #312725 - Flags: approval1.9+
(In reply to comment #43)
> (From update of attachment 312725 [details] [diff] [review])
> I'm going to go ahead and a1.9+ this as it's simply an update to the warning
> messages.  

Thanks you too.
Flags: wanted1.9.0.x?
Keywords: helpwanted → checkin-needed
Whiteboard: [c-n: Neil's patch // Leave opened]
(In reply to comment #41)
> 
> Stops (now) false warnings with GTK2; adds more warnings with Windows.

This is bad: we already get a dozen or more.

> Allows Trunk/Extension developers to be warned (only) in the relevant cases.


This is false. The warning does no good at all.

John, I understand your concern and your previous posts are rather clear and helpful.
Yet, the only reviewed patch we have so far is Neil's, then it's what we're taking in (for) now.

More patches welcomed...
Assignee: nobody → neil
Attachment 312725 [details] [diff] checked in.
Keywords: checkin-needed
Whiteboard: [c-n: Neil's patch // Leave opened]
Attachment #312725 - Attachment description: Update warning message tests → Update warning message tests [Checkin: Comment 47]
Blocks: 427520
I filed bug 427520 to (only) post "new" warnings, after Neil's checkin.
Whiteboard: [Post "new" warnings in bug 427520, not here.]
(In reply to comment #47)
> Attachment 312725 [details] [diff] checked in.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008040715 SeaMonkey/2.0a1pre] (SEA-WIN32-TBOX-trunk) (W2Ksp4)

"Verified" (still working), for this patch, per bug 427520 comment 1 example.
Whiteboard: [Post "new" warnings in bug 427520, not here.] → [not needed for 1.9][Post "new" warnings in bug 427520, not here.]
Blocks: 435025
After Firebug added accessibility features we now get a variation on this obnoxious message:
Key event not available on some keyboard layouts. 

I get 8 of these every time a start FF, about 6 times an hour.

The only place in Firebug source where key="k" appears is:
 <key id="key_focusFirebugSearch" key="k" modifiers="accel,shift" class="fbOnlyKey"

note no alt.

If I comment out the line with key="k", the warnings vanish.  

Of course since I believe the entire message is bogus I surely don't want to ask for a fix to make the message trivially more 'correct'.
My comment 50 was incorrect: the warnings did not go away. Eventually I discovered, by simply typing 'c-a-s k' that the key was ironically for Firebug's new key-rebinding mechanism.

On the newsgroup Boris says this warning only applies to Windows and GTK. That would explain why no one else on Firebug team sees the warning: they all use Macs. But this is yet another reason this warning makes no sense.

Firebug has plenty of bug reports about key binding conflicts. None has ever been for a key reported via this warning.
(In reply to comment #51)
> On the newsgroup Boris says this warning only applies to Windows and GTK. That
> would explain why no one else on Firebug team sees the warning: they all use
> Macs. But this is yet another reason this warning makes no sense.
It shouldn't matter which OS you're on. In fact, you've got the worst of all worlds as without the warning you'd have no idea that you shouldn't use, e.g. Ctrl+Shift+U for one of your accelerators.

> Firebug has plenty of bug reports about key binding conflicts. None has ever
> been for a key reported via this warning.
Do you mean conflicts with Firefox, other extensions or their OS?
(In reply to comment #52)
> It shouldn't matter which OS you're on.
Hmm, maybe it does matter if you use key="U" modifiers="accel,shift" because the Mac thinks that's "meta", not "ctrl", so fails to issue the warning.
attachment 252913 [details] [diff] [review] should be obsoleted IMHO, bug 496322 solves the warning and we decided to keep the easter egg.

With that, can this bug be resolved and any still seen issues (if any) be tracked in bug 427520?
(In reply to comment #52)
...
> > Firebug has plenty of bug reports about key binding conflicts. None has ever
> > been for a key reported via this warning.
> Do you mean conflicts with Firefox, other extensions or their OS?

Yes, all of the above. Some examples if you are curious:
http://code.google.com/p/fbug/issues/list?can=1&q=label%3Akeys
So, maybe we should add warnings for such things as Cmd+Tilde to stop other extension developers using them by mistake?
Comment on attachment 252913 [details] [diff] [review]
fischam-B-gone

We have a new fishcam now ;-)
Attachment #252913 - Flags: review?(neil) → review-
(In reply to comment #36)
> Created attachment 312725 [details] [diff] [review]
> Update warning message tests
> [Checkin: Comment 47]
> 
> * Fixed GTK2 to test against Ctrl+Shift+U
> * Fixed Windows to test against Ctrl+Alt+Z
> * Allowed upper/lower case in case bug 410186 lands again

As far as I can tell from reading the code, the patch causes all keys with Ctrl+Alt+ a-z or A-Z to emit the warning on Windows. 

Experimentally we get this message:
Warning: Key event not available on some keyboard layouts: key="b" modifiers="accel shift alt"
Source File: chrome://browser/content/browser.xul
Line: 0
but only on FF4.0b9pre. 

And experimentally Control+Alt+Shift+B works on Windows.
Indeed, only the Ctrl+Alt+B case is documented, and the Ctrl+Shift+Alt+B is an edge case which probably should not issue the warning. (I notice that you can also assign Ctrl+Shift+B and Shift+Alt+B to Windows shortcuts.)
Sorry I don't understand. It seems to me that the warning is incorrect. But I don't understand this warning anyway, so I understand your answer.
Ctrl+Alt+A-Z are documented as for use as user-defined shortcuts to launch
applications. Ctrl+Shift, Shift+Alt and Ctrl+Shift+Alt are not documented,
but appear to be usable as application launch shortcuts anyway.
(In reply to neil@parkwaycc.co.uk from comment #61)
> Ctrl+Alt+A-Z are documented as for use as user-defined shortcuts to launch
> applications. Ctrl+Shift, Shift+Alt and Ctrl+Shift+Alt are not documented,
> but appear to be usable as application launch shortcuts anyway.

Huh, and I thought they were reserved because of the issue described in <https://blogs.msdn.microsoft.com/oldnewthing/20040329-00/?p=40003> (such shortcuts conflict with characters entered as AltGr+letter).

I guess those can both be true, though, since if the *user* assigns such a conflicting combo to a shortcut, that's their business.
Component: Keyboard: Navigation → User events and focus handling
Severity: minor → S4

The severity field for this bug is relatively low, S4. However, the bug has 6 duplicates.
:neil, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(neil)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(neil)
You need to log in before you can comment on or make changes to this bug.