When I try to use Google Chrome's spell checker to correct the spelling of words in a text field or text area, Chrome crashes and displays the “Aw, Snap!” error message. This issue is only present on Chrome.
This is the sample code for reproducing the issue.
As soon as I right click on the red underlined word, Chrome crashes and it displays the error page. If there are multiple misspelled words in text field, only the last word causing an issue. I don’t have any issue with using spell checker for other words expect the last one, “mssage” in this case. I also don’t have any issue when there is another correctly spelled word after the misspelled word. In this case, it doesn’t crash.
In general, what I observed is that if the misspelled word is the last word in the text field, then the crash occurs; otherwise, it works as expected. I have checked all log files including Chrome local logs, but there is no log message related to this issue, and I am not able to debug it. I found a few partial solutions, but still couldn’t understand the root cause of this issue.
Partial solution-1: If we remove the text from the Button, the issue is resolved. As you can see, the button doesn’t have any text written on it, and in this case, it works as expected.
Partial solution-2: If we swap the order of the Button and Text Field, the issue is resolved. When I add components to the layout, the order makes a difference. When the button is added before the text field, the issue isn't there.
Partial solution-3: This is the solution I am currently using since the first 2 solutions require me to change my layout. If I add the suffix (sample code included) to the text field, the issue is resolved; however, the suffix has to have text in it, otherwise it doesn’t solve the issue. I added Label with “.” and set opacity to “0” to make it invisible on the user end.
Thank you so much.
I was able to reproduce your issue in Chrome Version 91.0.4472.114 in macOS and it works after upgrading to Version 92.0.4515.107.
It was already reported in bugs.chromium.org and it's fixed in latest Chrome.
Related
Somehow, in my website, the last word appearing in a contenteditable is marked as misspelled, even when it is the correct spelling.
Here is an example of such an entry with the last word clearly marked as misspelled:
Just in case there is the HTML code surrounding that contenteditable <div> tag.
Note: as mentioned by Carl below, that screenshot shows the HTML as loaded and not the HTML as used once jQuery ran against it. I have a simplified sample below that includes that data. Also it shows a ! at the end of the string, which makes it work right... (Any other character after the word, and the spelling works fine.)
I tried to replicate that problem in jsfiddle without luck, so I create a simplified version of the page with just that one widget:
http://alexis.m2osw.com/contenteditable/ContentEditableProblemSimplified.html
IMPORTANT NOTE: On first load, it works properly because Firefox does not check the spelling of words at that time. You have to click in that field once and the effect happens.
This happens in FireFox v53.0, it has been like that for a while though.
I noticed strange behaviour on TYPO3 tx_news list view. Sometimes on the bottom of the page appears unknown characters. I don't know how and why and it's only on one (list view) page and in chrome browser. Here is the screen shot of that:
I have noticed that I can call out that behaviour when I change some tx_news configuration in Extension Manager eg. "List actions shown in Flexforms"
Any suggestion what is wrong?
[EDIT:] After turn off OpCache - problem doesn't occur. Could it be related?
You best bet is to install XDebug and call your page with ?XDEBUG_TRACE=1
You can then search for the offending pattern in your trace file and find the very first place where this offending pattern occurs (if it's not random of course). This gives you the very best chance to figure out why it appeared at all.
I'm afraid this is highly specific, so please bear with me and read carefully.
The problem:
Open a PDF file, select and copy some text that contains line breaks and paste it into a TinyMCE textarea in the Google Chrome browser. Then delete any line break and insert a space at the same point: the space that is added is non-breaking even though I used a regular "space bar" key stroke in TinyMCE.
How do I know there is a non-breaking space?
You can click the "show invisible characters" button on the first row of my TinyMCE implementation (see link below). Remember that with TinyMCE your must turn that option Off and On again every time you modify the text to see the changes.
The non-breaking spaces will appear in orange, normal spaces appear normally.
What I have found so far:
If I delete the character that comes after the line break and then type that character again, I can insert a normal space. The problem seems to be attached to that character.
If I delete the character occuring before the line break, the problem persists, i.e. when I delete the space and type a new space it is still a non breaking space.
Also when I save the text to the MySQL database, and read it again in TinyMCE, the problem still occurs, which reinforces my impression that the "hidden" character is attached to the letter following the line break (there is no saving on the test page of course).
Replicating it
You could of course try it yourself, but here is my testbed for you: http://www.roseback.com/test/tinymce4.html
I have tested it with many PDF files that we receive from graphic designers, from many products and eras. These PDFs are the files that are used for printing and there is no problem with those files for that use.
I uploaded a sample file here: http://www.roseback.com/test/languedoc.pdf. Test with the first paragraph starting with "Ce film exceptionnel".
However I have also tested random PDF files from the web and replicated the problem every time. So if you try with your own files and can't replicate, that might be interesting.
Environment:
Web page: the page is in HTML5, in UTF-8.
On the original page, the page is served via PHP and the textarea content comes from a MySQL 5.1 DB. The DB connection is set to UTF-8 in PHP, the content of the table and of the text field is in utf8_unicode_ci
On the test page there is no content and no saving, so no DB is involved.
Browser: Chrome. Does not happen in Firefox or Opera (not tested elsewhere)
TinyMCE: version 3 and version 4 (both standard version, not jQuery)
OS: on Windows 7 Pro 64 bit and also on Windows XP Pro 32 bit
I would appreciate any feedback, even simple confirmation / replication of the problem.
Hmm, i think what you observe has something to do with the fact that tinymce inserts non breaking spaces instead of spaces. Tinymce needs to so this in order to avoid that the browser shows more than one space concurrently entered as one single space (this is the default browser behaviour).
You can verify this by inserting more than one space and then have a look at the non-visible characters.
I installed the All Autocomplete package in my Sublime Text 2 editor and everything works fine except when I type "<div" or something similar, the auto-complete box pops up, I select the one I want and hit enter and it adds "<<div></div>" with an extra "<" in the front of my tag. I have to go back and delete the extra "<" every time...(!)
I can't seem to resolve this issue. If I use the command CTRL+Space, the box pops up and I can select the tag I want and it does not include the extra tag but that messes with my flow.
Has anyone out there experienced this? Thanks for your help!
I've just installed the package and it seems to work fine for me.
I type <div and then hit Tab or Enter and it completes correctly.
The only thing I can think of is that the AllAutocomplete package is conflicting with another package/plugin you may have installed.
It seems to be a problem with Zen Coding. See here.
Unfortunately I tried all suggestions there, including peruvianidol's 'Packages/HTML/html_completions.py' solution, but haven't had any luck.
This is something of a follow-up question to my question here. You can find the HTML source in a text file here.
When I load that page in IE8, I get the "Done, but with errors on page." message in my status bar. The detail view shows
Expected identifier
sms Line: 147
Code: 0 Char: 67
and I see absolutely no problems anywhere near there. In IE8, the page is still behaving erratically w/r/t the randomly losing focus as mentioned in my other question.
When I load the same exact page in Firefox (using Firebug) the console shows no errors and the page works perfectly. Any thoughts on what's going on here? This is driving me nuts and making me want to give up on even trying to write an IE friendly page.
Edit: Thanks for all the comments! This page is written as a JSP, so I edit in Eclipse. I found an Eclipse warning about the onblur event for the username field. I switched it from
onblur="alert(document.activeElement + ' class:' + document.activeElement.class)"
to
onblur="alert(document.activeElement)"
and that made the bizarre IE page error vanish. I had been trying to give more info (namely, its CSS class) about specifically which element is stealing focus - to my own detriment, apparently, since Javascript was interpreting the '.class' part in the Java(script) sense there is no class property (I should have been using className).
And, no, the page doesn't validate. But the errors were mostly/all ones that just didn't make sense to me, such as
Line 14, Column 41: Attribute "LANGUAGE" is not a valid attribute. Did you mean "language"?
But I'm still stuck trying to figure out why, as I enter text in the username & password fields, focus randomly switches to a div (working on figuring out which div currently).
Edit 2: It's the div between the two "global nav" comments, at the very top of the body. Still no idea why it's happening, though.
The problem appears to be the line
onBlur="alert(document.activeElement + ' class:' + document.activeElement.class)"
when you take off the ".class" it loads without issue. Are you sure ".class" is valid?
Does your HTML validate?
I agree, IE does a terrible job giving developers information about page errors. I only support IE on the principle that users shouldn't have to download twenty-odd browsers to go to their favorite websites. Web developers have a responsibility to make it "just work". Browser developers have a responsibility to communicate with each other and conform to standards.
Run your javascript through JSLint. You probably have a missing semicolon somewhere or a comma at the end of an object property that shouldn't be there. Firefox is more forgiving than IE when it comes to those types of syntax errors.
Edit: The inline js in your page seems to be OK. Check the contents of qm_scripts.js.
When I remove the .class from document.activeElement.class the error goes away.
The real issue is that you need to be able to debug your JS in IE 8, correct? There is a tool for that! :)