981954 - Sometimes we remove a char message whose scan code is different from found message

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

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

When we remove found char message, the removed message's scancode is sometimes different from the found message.

We can guess that it's caused by another application inserting new key message into the queue.

So, we should ignore the scan code difference if other values are same.

Comment 1

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

This bug was fixed by attachment 8377472 [details] [diff] [review].

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #75)
> Logs of remaining crashes are:
> 
> > Handling message: WM_KEYDOWN (0x00000100), wParam: 0x00000080, lParam: 0x00000001, InSendMessageEx()=ISMEX_NOSEND,
> > Found message: WM_CHAR (0x00000102), wParam: 0x0000092F, lParam: 0x00000001,
> > Removed message: WM_CHAR (0x00000102), wParam: 0x0000092F, lParam: 0x00800001 
> 
> and
> 
> > Handling message: WM_KEYDOWN (0x00000100), wParam: 0x00000080, lParam: 0x00000001, InSendMessageEx()=ISMEX_NOSEND,
> > Found message: WM_CHAR (0x00000102), wParam: 0x000000A0, lParam: 0x00000001,
> > Removed message: WM_CHAR (0x00000102), wParam: 0x000000A0, lParam: 0x002A0001 
> 
> http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-
> 923143f3456c/scancode.doc
> According to "Keyboard Scan Code Specification", scan code 0x80 means
> releasing undefined key. 0x2A is pressing left shift key. It might occur
> when new keydown or keyup message is inserted to the queue. Although, I have
> no idea to confirm it.

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #76)
> Created attachment 8377472 [details] [diff] [review]
> NativeKey should not check scan code at comparing found char message and
> removed char message (landed on m-c and aurora)
> 
> Let's ignore the scan code value at comparing found char message with
> removed char message.
> 
> That's all for the crash reasons which we know.

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #77)
> Thank you, let's close this bug after watching crash reports for a week.
> https://hg.mozilla.org/integration/mozilla-inbound/rev/efd7039a2ff2

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #84)
> https://hg.mozilla.org/mozilla-central/rev/efd7039a2ff2

Comment 2

[Manuela Muntean [Away]]

It seems that this issue is still reproducing, since bug 962140 currently has the ASSIGNED status and according to Socorro, there are builds with the 20140306171728 and 20140306171728 build IDs that crashed with this signature, in the last 4 weeks:

https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Awidget%3A%3ANativeKey%3A%3AGetFollowingCharMessage%28tagMSG%26%29&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2014-03-11+10%3A00%3A00&range_value=4#tab-reports

Comment 3

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

(In reply to Manuela Muntean [:Manuela] [QA] from comment #2)
> It seems that this issue is still reproducing, since bug 962140 currently
> has the ASSIGNED status and according to Socorro, there are builds with the
> 20140306171728 and 20140306171728 build IDs that crashed with this
> signature, in the last 4 weeks:
> 
> https://crash-stats.mozilla.com/report/
> list?signature=mozilla%3A%3Awidget%3A%3ANativeKey%3A%3AGetFollowingCharMessag
> e%28tagMSG%26%29&product=Firefox&query_type=contains&range_unit=weeks&process
> _type=any&hang_type=any&date=2014-03-11+10%3A00%3A00&range_value=4#tab-
> reports

See bug 981958 comment 3.

Comment 4

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

I see there is a crash on 29.0 Beta (https://crash-stats.mozilla.com/report/index/b98dbda6-04e9-470e-8319-c687f2140321).
Per comment #3 I'm removing the "verifyme" keyword, since it seems there's nothing more we can do on the QA side for now.

Comment 5

[u279076]

qa- as per comment 4.