User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 Steps to reproduce: In Firefox 50.0.2 - Open any writable text field in a webpage. (This text field I'm writing in is included). Type in Exactly 102 capital "X" characters. Writing more than 102 capital "X" in one row does not cause the crash. Writing less than 102, cause no crash. So all "X"'s are in a row, like the one I've provided bellow (This issue was reported from Google Chrome as Firefox crashes when this is pasted): XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Actual results: Firefox crashes. Expected results: It should show the 102 capital "X" characters. Like this(Reported from Google Chrome browser): XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Firefox should not have crashed.
Is this a for real report? (Sorry, doesn't sound like it) Does it happen in safe mode? https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode?redirectlocale=en-US&redirectslug=Safe+Mode
Priority: P1 → --
Whiteboard: [closeme 2016-12-21]
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #1) > Is this a for real report? (Sorry, doesn't sound like it) > Does it happen in safe mode? > https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe- > mode?redirectlocale=en-US&redirectslug=Safe+Mode Hi Wayne Mery. Yes, this is infact a real report. Strange as it sounds, I can replicate this exact issue running Firefox in safemode as well. All that I need to do is to copy the 102 "X" characters I've provided in the above report, and paste it in this comment field. And Firefox, Eventho it's running in safemode crashes. I've also confirmed the same issue occuring on several nodes. Please try it yourself. br Pontus
I've been able to reproduce this in Windows 7 & Windows 10 On Firefox v49.x.x & v50.0.2
Nope, no crash here - upper and lower case. Please post your crash ID (as text string) from help | troubleshooting or about:crashes
Severity: major → critical
WFM in Fx50.0.2 on Win10. Crash ID is needed.
OS: Unspecified → Windows
Hardware: Unspecified → x86_64
WFM in https://ftp.mozilla.org/pub/firefox/releases/50.0.2/win32/sv-SE/Firefox%20Setup%2050.0.2.exe with paste "X"x101 and TYPE the "X" on this bug's search box, on Win10 (zh-CN). (In reply to Pontus from comment #0) > Type in Exactly 102 capital "X" characters. How do you do it? Enter these characters one by one with keyboard? Or paste can also be reproduced? > Writing more than 102 capital "X" in one row does not cause the crash. It does not crash right away? If it crashes immediately, how do you enter more characters? > Writing less than 102, cause no crash. See above.
(In reply to YF (Yang) from comment #7) > How do you do it? Enter these characters one by one with keyboard? Or paste > can also be reproduced? Both options seem to cause the crash. I mainly paste from clipboard to replicate this issue as this directly cause the crash. The time it takes for Firefox to crash is between a instant and a few milliseconds. For some pages tested, I need to leave the text field. This is the case here on this page, in the comment field. > > Writing more than 102 capital "X" in one row does not cause the crash. > > It does not crash right away? If it crashes immediately, how do you enter > more characters? The time it takes for Firefox to crash seem to between a instant and a few milliseconds. the time varies everytime I've tried to replicated the issue. Sometimes there is enough time to add letter or more, tho pasting 102 "X" usually crashes the browser instantly. Therefor holding down "X" untill it's 102 or more usually does not render a crash. Thank you for taking time investigating this. br Pontus
I have reproduced it with comment 7 configuration, except that these characters are pasted into comment field (appears after login). It crashes silently for many times, but there are no crash reports and crash reporter appears. When the session resumed after crashes, I clicked the comment field to focus, the browser hang and silently shutdown after a few seconds.
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Untriaged → Spelling checker
Ever confirmed: true
Product: Firefox → Core
Hardware: x86_64 → All
Whiteboard: [closeme 2016-12-21]
Version: unspecified → 50 Branch
Oh, so I think this is actually trivial to fix. I suspect I can just change 176 back to 100 in https://github.com/hunspell/hunspell/commit/5de5239f2beac8d22b692dc9db57c821ba321116 and be done with it. And file an upstream issue about guarding that with an #ifndef so it can be set at build time without requiring hacking the upstream source ;)
Sorry, that was intended for bug 1322666, but it'll probably fix this bug too!
Dimitrij, you should probably be aware of this bug for Hunspell2 testing. I'm going to tentatively assume that bug 1322666 will work around it on our end for now.
Depends on: 1322666
This bug can be reproduced in Firefox versions that use Hunspell 1.4.1, but only when certain dictionaries are selected. I was not able to reproduce using en_US or Hungarian, but I was able to reproduce it using the Korean dictionary installed via the package manager of Ubuntu 16.04 (and probably the same Korean dictionary is used in the Firefox addon). It is possible that this bug is already fixed in Hunspell 1.5.x which already landed in Firefox tree and is planned for Firefox 53 AFAIK. I will try to reproduce the bug outside Firefox, directly with the Hunspell command line binary.
I was able to reproduce this bug with both 1.4.1 and the latest 1.5.4. Therefore I will file an issue in the Hunspell bugtracker, once fixed, 1.5.5 will be released. Probably this bug existed since ages, but the MAXWORDLEN limit was 100 and was not allowing the bug to be triggered. Once the limit was raised to 176 in 1.4, the bug can be triggered. And yesterday, that limit was reverted to 100 only in the Mozilla source tree, so this bug will be hidden again. On the Mozilla side we are kinda safe. Until i fix it for real in upstream and not just hiding it with MAXWORDLEN, it would help to tell me with which dictionaries this bug can be reproduced. So far I can do it only with Korean.
I fixed this this in the upstream Hunspell, see the link to the issue above.
Assignee: nobody → dmjpp
status-firefox50: --- → wontfix
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
status-firefox-esr45: --- → wontfix
See Also: → https://github.com/hunspell/hunspell/issues/446
I published Hunspell v1.6.0 where this is fixed. It's up to Ryan to merge it in the source tree.
This was fixed on Nightly by the Hunspell update in bug 1326277 and worked around for Firefox 51/52 by bug 1322666.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox51: affected → fixed
status-firefox52: affected → fixed
status-firefox53: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
You need to log in before you can comment on or make changes to this bug.