892539 - Assertion failure: modifierKey->keyCode == keyCode

Status: RESOLVED FIXED

(Core :: Widget, defect)

Description

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Poking around in gdb

Unfortunately, I don't have solid steps to reproduce this. Sometimes when hitting either cmd or alt (or a combination of the two), I'll hit this assertion. It doesn't reproduce every time.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

What's the version of OS X?

Which keyboard layout are you using?

And what type keyboard are you using? E.g., MacBook Pro's keyboard, external USB keyboard for Mac or PC.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #1)
> What's the version of OS X?

This is OS X 10.7.5

> Which keyboard layout are you using?

This should be the standard en-US keyboard layout.

> And what type keyboard are you using? E.g., MacBook Pro's keyboard, external
> USB keyboard for Mac or PC.

I'm using the builtin MacBook Pro's keyboard.

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: log-vars-n-stack.txt

I ran across this as well in yesterday's Nightly debug. I'm on 10.8.4 MBP standard en us keyboard. I opened a second tab and began to hit command+v to paste a url when I got the assert. I also dumped output, and it seems to be the same key.

  MOZ_ASSERT(modifierKey->keyCode == keyCode);

  keyCode      unsigned short 55
  modifierKey  mozilla::widget::TextInputHandler::ModifierKey * 0x129659068
    flags      NSUInteger     1048584
    keyCode    unsigned short 59

It seems to happen to me infrequently at various times, and has for at least the last few months at least, maybe longer, without a clear pattern.

It's a nuisance, as it interrupts my debug session, but I've learned to move the program counter past the MOZ_ASSERT in the debugger to keep going.

I did some quick experiments:

Using the above technique, I got my session going again, and noticed I can type any other letters into the url field just fine (without triggering the assert), but every time I press down the left command key or the left control key it happens.

It does not happen for any other key or any of the other qualifiers, including the right command key (there is no right control key).

Here are the values when I press the left control key instead of command:

  keyCode      unsigned short 59
  modifierKey  mozilla::widget::TextInputHandler::ModifierKey * 0x112523458
    flags      NSUInteger     262145
    keyCode    unsigned short 55

Notice how 59 and 55 are reversed now compared to when I pressed left command.

This seems to point to some error in logic assumptions in our code about these two modifiers on macs, or maybe some odd rules that pertain to them perhaps.

This appears to also happen in text-fields on a web page.
It does not appear to happen in dialogs like Firefox/Preferences.../Home Page.

Quitting the tab and re-opening a new tab did not make the problem go away.
Quitting the firefox window (not process) & re-opening it DID make it go a way.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

How important is this assertion? Can we back it out or something? It makes debugging on a pristine mac tree basically impossible for me.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Blake Kaplan (:mrbkap) from comment #4)
> How important is this assertion? Can we back it out or something? It makes
> debugging on a pristine mac tree basically impossible for me.

Not so important. It means that there is a bug in very rare case. In normal use case, user never meets the bug. Therefore, MOZ_ASSERT() is useful for getting reports like this. I'll try to investigate this bug soon.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

jib:

Thank you for your investigation.

Your research must be correct, but I have no idea why the left-control key information and left-command key information was reversed.

We *might* meet a bug of Mac OS...

> Quitting the tab and re-opening a new tab did not make the problem go away.
> Quitting the firefox window (not process) & re-opening it DID make it go a way.

TextInputHandler instance is created for every nsIWidget instance. So, the contamination is not spread all over the process.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch

Although, I don't reproduce this bug and we're not sure the cause, anyway, the importance isn't so high because the modifier flag information is used only for deciding key location (left vs. right) only in the default case. The default case isn't normal situation. So, even if the information is lost at that time, only the key location value might be computed as wrong value.

Let's discard the stored modifier flag information if we detect the mismatch. If modifier keys will be pressed, the database will be rebuild with the latest information. So, the default case will work correctly.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch

Sorry, I forgot to update the diff file.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 796458 [details] [diff] [review]
Patch

Looks fine to me.  Let's see what fallout this has, if any.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8f0cc92fbe5d

Comment 11

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/8f0cc92fbe5d