I am developing a Chrome Packaged app that has a webview in it. The problem is that I cannot type any sort of accented character (such as é, ç, ê) in a text input that is inside the webview. When I try to type é, for instance, I only get e in the text field. Strangely I can copy and paste accented characters into the webview text field without a problem.
Text inputs that are outside the webview work ok. This issue only seems to happen when running the packaged app on Mac OSX (It works fine on Windows). Other official sample apps that use webviews also have the same issue.
I have already checked if UTF-8 is being used by both the app and the webview itself, and it is.
Any idea of what might be happening?
Like lazyboy commented, this has been fixed since Chrome 34. It was actually a bug in previous versions of Chrome.
Related
I'm currently using JetBrains' PHPStorm IDE and I'm having problems using the embedded terminal with a Portuguese Keyboard (correctly set up on Windows). I can't input certain characters like "[", "{" or "]", which I can only access using the "Alt Gr" key, despite characters common too all keyboard layouts working just fine.
Is there any way to fix this? I'm forced to use the windows console to perform certain tasks because of this problem, which makes the IDE terminal a bit useless to me.
It's a known issue that is fixed already.
You will have to wait till next update (v2016.1.1) will be publicly available -- it's expected to be somewhere in a week time (no precise date for the moment, unfortunately).
In meantime you can either use English keyboard layout ... or keep using external console app.
I've created a webapp that uses SVG to allow the user to create an image. Because I want the user to be able to export that image as a PNG, I've embedded a number of fonts directly into the SVG as Base64 encodes (I converted the fonts using FontSquirrel). Everything works just fine under OSX (where I am developing) on all major browsers.
I have limited ability to test Windows machines, but one of my beta test users is having a problem where certain characters render incorrectly under Windows (Firefox or Chrome that we've tested so far). So far, it appears to affect the letter 'g' and the number '8'. Here's what they look like:
I'm pretty stumped... not seeing anything about this on SO or other sights about embedding fonts as Base64. Do I need to set up my encode on font squirrel differently to accommodate Windows or something?
Update: Thanks to Mike for the testing environment link. I took a look at this and it appears to have been an issue with the encoding of my font. It was present on all versions of Windows (7, 8, and 10) and browser combos. After some frustration I redid the font squirrel encode (which I had tried previously) and suddenly everything worked. I don't know, but if someone finds this, I guess re-encode.
I'm trying to use nested view with DustJS (linkedin fork) with ExpressJS. While rendering the response system generates some escape chars in response. Which disturb the style and theme.
The same code renders fine as one view file, but when split code into two view files (one load as partial) than the problem arise.
Interesting thing is, it happens with two view engines I tried, the same issue, ECT and DustJS. Development on minimal components, Twitter Bootstrap 3.0 and express are additional component added so far.
My machine is running windows as operating system and development tool is visual studio. What could be reasons, has anyone find same trouble with these view engines?
View in Google Chrome Developer Tool.
Response-Text View
I tried to fiddle and tried to map the extra chars.
You have an UTF-8 BOM in one of the files you are using, usually in the first 3 bytes. Normally, a text editor will not show you these characters. Examine your used files with a hex editor (or write a script that examines those files for you) & store the offending file without that UTF-8 BOM, and configure all your editors to omit the BOM in future.
In addition to Wrikken's answer, if you are using Visual studio than it cab be fixed by advance save option.
I'm developing an application and just noticed that not a single accented character, for example, the Brazilian Portuguese "é", neither "ã" are displayed when I'm running the JavaFX application on Linux.
BUT, if I copy/paste those characters they appear normally, so I don't think it's an encoding problem.
On the other hand, the exactly same code works on Windows and those characters are displayed normally.
Is this a known bug?
Thanks in advance.
I've seen this problem in a project which a team member was using Eclipse on Windows, with default encoding to ISO-8859-1, while I was using UTF-8 on Linux.
So, if you're using Eclipse, check your encoding at Window > Preferences > General > Workspace, then Text file encoding group.
I'm developing a javafx-2 application and I want the user to be able to type Greek accented characters in a Textfield using a 'dead key'. Unfortunately, the accents are ignored. The javafx-2 samples provided by oracle behave the same way.
I've only checked on a mac running Lion. Java Swing applications don't have this problem. I have installed the latest JRE provided by apple (1.6.0_31-b04-414).
Thanks,
Nikos
You may want to try JavaFX 2.1 (dev preview: http://www.oracle.com/technetwork/java/javafx/downloads/index.html)
I had no problems with Greek accented characters there:
UPD: Typing these characters works as well in 2.1, see screenshot with characters entered from keyboard using dead keys for Greek Polytonic keyboard:
I am having the same problem with FX8. One solution would be to write a textproperty listener to take care of that, unless it is fixed later on. Coming from Swing it is true I did not have that problem either. I am using Windows7.