WM_DEADCHAR message might have gone at removing it from the queue

RESOLVED FIXED in Firefox 52

Status

()

Core
Widget: Win32
RESOLVED FIXED
9 months ago
9 months ago

People

(Reporter: masayuki, Assigned: masayuki)

Tracking

(Blocks: 1 bug, {crash})

Trunk
mozilla54
All
Windows
crash
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox51 wontfix, firefox52 fixed, firefox53 fixed, firefox54 fixed)

Details

(crash signature)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

https://crash-stats.mozilla.com/report/index/4ba63f64-4f3d-41d0-bc4f-e11102170202
> PeekMessage() failed to remove char message! 
> Handling message: { message=WM_KEYDOWN, virtual keycode=VK_BACK, repeat count=1, scancode=0x11, extended key=false, context code=false, previous key state=false, transition state=false, hwnd=0x2b01b0, InSendMessageEx()=ISMEX_NOSEND, 
> Found message: { message=WM_DEADCHAR, character code='㕲' (0x3572), repeat count=1, scancode=0x11, extended key=false, context code=false, previous key state=false, transition state=false, hwnd=0x2b01b0, 
> WM_NULL has been removed: 0, 
> Next key message in all windows: { message=WM_DEADCHAR, character code=NULL (0x0000), repeat count=1, scancode=0x11, extended key=false, context code=false, previous key state=false, transition state=false, hwnd=0x2b01b0, time=8413593, 
> Next message in all windows: { message=WM_DEADCHAR, character code=NULL (0x0000), repeat count=1, scancode=0x11, extended key=false, context code=false, previous key state=false, transition state=false, hwnd=0x2b01b0, time=8413593

This is odd case. WM_DEADCHAR message has gone from the queue but next key message is still in the queue but its scancode is different key's.

I think that we should treat this case as consumed case.
status-firefox51: --- → wontfix
status-firefox52: --- → affected
status-firefox53: --- → affected
See Also: → bug 1336080
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8d1562a73325
See Also: → bug 1336331
Coming patch depends on bug 1336080.
Depends on: 1336080
https://treeherder.mozilla.org/#/jobs?repo=try&revision=19516432cfdd
Blocks: 1336331
Comment hidden (mozreview-request)

Comment 5

9 months ago
mozreview-review
Comment on attachment 8833244 [details]
Bug 1336322 NativeKey::GetFollowingCharMessage() should treat the char message has gone if PeekMessage() failed to remove found char message and next key message becomes non-char message or different key's char message

https://reviewboard.mozilla.org/r/109480/#review110950
Attachment #8833244 - Flags: review?(m_kato) → review+

Comment 6

9 months ago
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/21f71652e491
NativeKey::GetFollowingCharMessage() should treat the char message has gone if PeekMessage() failed to remove found char message and next key message becomes non-char message or different key's char message r=m_kato

Comment 7

9 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/21f71652e491
Status: ASSIGNED → RESOLVED
Last Resolved: 9 months ago
status-firefox54: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Comment on attachment 8833244 [details]
Bug 1336322 NativeKey::GetFollowingCharMessage() should treat the char message has gone if PeekMessage() failed to remove found char message and next key message becomes non-char message or different key's char message

Approval Request Comment
[Feature/Bug causing the regression]: Long standing bug which we don't handle odd keyboard message behavior of Indian keyboard utility.
[User impact if declined]: Some users around India may meet this crash at typing something. See bug 962140 comment 144 for the detail.
[Is this code covered by automated tests?]: No.
[Has the fix been verified in Nightly?]: No, because we're still not sure how to reproduce this bug but we have not gotten any regression reports.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: Perhaps, this may depend on the patches for bug 1336080. (It will be fine if you land the uplifts from smaller bug number to larger number of this series of crash bugs.)
[Is the change risky?]: No.
[Why is the change risky/not risky?]: When we detect odd case, we have been crashing by ourselves. This patch avoids the crash in the specific case mentioned in comment 0. So, this doesn't change normal path.
[String changes made/needed]: No.

FYI: Nobody of Aurora/Nightly channel testers has met this crash. So, the odd keyboard utility users are using only Release and Beta. So, it does not make sense to wait 12 weeks for such users.
Attachment #8833244 - Flags: approval-mozilla-beta?
Attachment #8833244 - Flags: approval-mozilla-aurora?
Comment on attachment 8833244 [details]
Bug 1336322 NativeKey::GetFollowingCharMessage() should treat the char message has gone if PeekMessage() failed to remove found char message and next key message becomes non-char message or different key's char message

crash fix for aurora and 52.0b4
Attachment #8833244 - Flags: approval-mozilla-beta?
Attachment #8833244 - Flags: approval-mozilla-beta+
Attachment #8833244 - Flags: approval-mozilla-aurora?
Attachment #8833244 - Flags: approval-mozilla-aurora+

Comment 10

9 months ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/ee21650b0037
status-firefox53: affected → fixed

Comment 11

9 months ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/066a9139b060
status-firefox52: affected → fixed
Flags: qe-verify-
You need to log in before you can comment on or make changes to this bug.