I'm creating a voice/text-memo web application.
Here: http://gustavstromberg.se/sandbox/html5/localstorage/ look at its source (very short, most of it is css)
This is:
Voice recognition, works only in chrome as far as I know.
Local Storage, to store notes as text.
Google Translate text-to-speech.
Everything works, but in different browsers. The voice input works perfect, only in chrome. The text-to-speech works in safari.
To dynamically load the memo into the audio>source element i use:
$("#spokenmemory").html("<source src='http://translate.google.com/translate_tts?tl=en&q="+localStorage['memory']+"' />");
(the localStorage['memory'] contains my stored text memo)
To play my recently saved memo with googles text-to-speech-function I use:
$("#listenplay").click(function(){
$("#spokenmemory")[0].play();
});
(spokenmemory is the id-attribute of my audio-tag)
This does'nt work to play in chrome, but if I visit the translation link (example: http://translate.google.com/translate_tts?tl=en&q=Japan, and my text-memo is "Japan") in a separate browser-tab and then return to my site and reload the page (with the same text-memo "Japan" saved), the playback works. How strange, and annying!
Has anyone any idea of this strange behaviour?
It is because google restricts certain types of requests to prevent the service from being overloaded. So the audio file is not fetched when your browser tries to fetch it. Once you visit the translation link, the audio file is fetched and is cached which is why the playback works (provided the text-memo is same). This has been my observation but I'm not very sure.
When I used CURL to fetch the file, this is what I got in response:
403. That’s an error.Your client does not have permission to get URL /translate_tts?q=hello from this server.
I tried hard Gustav, and this is what I found after a bit of research and testing.
It seems Chrome is having trouble streaming mp3 (the format google returns). The only solution I can imagine is getting the file (cURL?) to your server and then present it to the user. I assume when Google releases the official API, there will also be some sort of a format option.
http://code.google.com/p/chromium/issues/detail?id=45152
http://www.trygve-lie.com/blog/entry/html_5_audio_element_and (yes, the play button is the same color as the background, funky)
Related
UPDATE: At time of asking this question, this was related to SignalR library and not plain WebSockets. I see correctly formatted messages now.
Is there any way to word-wrap messages in WS tab in Chrome Developer Tools or display JSON with formatting ? It's really annoying to scroll to right to see whole message.
Example with message selected and it's preview doesn't have any formatting or word wrapping applied:
Thank you in advance.
It's working fine here on Chrome/78.0.3904.97:
What I did:
Go to http://crawl.develz.org/play.htm
Open one of the listed servers
Start devtools
Go to the Application tab and add a cookie called "no-compression" with value "yeah no" to the relevant server. (Any truthy string should work, I just chose the least confusing one I could think of in about a minute.)
Otherwise, crawl's webtiles server can end up compressing messages even when browser supports RFC 7692's "permessage-deflate" extension, which ruins the demonstration.
Open the Network tab
Reload the page
Select the "socket" request, switch to the "Messages" tab, and pick a frame.
Start drilling down in the tree view in the bottom pane!
Sorry it is difficult to provide code for this.
In a normal browser (firefox, IE etc) when I enter a Google Geo Code API URL
https://maps.googleapis.com/maps/api/geocode/xml?address=&key=
with myAddress and mykey set correctly. I get a the JSON response as text in the browser window.
I would like to do exactly the same with a VBNet browser control. That is-
Set aBrowser.Navigate property to my Google GeoCode API URL and then receive the JSON back as text in the browser that can be accessed with aBrowser.document.... .
However, VBnet seems to immediately abort the url navigation task and invites the user via a dialogue box to save a file. If I save the file and then inspect it, the content is the JSON text that I expected to see inside the browser document.
This is my first play with JSON and assumed that the VBNet browser would behave just like IE. I am missing something?
Thanks in advance.
Geoff
Had a play with the answer provided for for HTTP GET in VB.NET
This is easily adapted to work with Google GEO Code API and the JSON text is received into a string. I can then either process the string or place the string on the browser page.
This works for me.
My intention is to analyze json strings as part of REST messages.
In Chrome there are possibilities to use Inspect -> tab Network to find the json string that I want. However I cannot find the json string in Firefox.
Does Firefox support this?
I will show an example from a public page.
Open https://www.theguardian.com/ in Chrome
Inspect (Ctrl-Shift-I) and select tab Network
Click UK (UK News)
On tab Response you will find json strings as for examlple comment-counts.json
like
{"counts":[
{"id":"/p/5kmed","count":269},{"id":"/p/5kkv8","count":39},
{"id":"/p/5kq4t","count":5},{"id":"/p/5k7x7","count":1064},
{"id":"/p/5ky88","count":1720},{"id":"/p/5kp8e","count":841},
{"id":"/p/5kkbv","count":692}]
}"
Image: Inspecting The Guardian UK News
In Firefox I cannot get this piece of code. I have tried Inspect Element tab Network and sub-tabs Headers, Params and Response.
Do anyone know if it is possible in Firefox and in that case how to get it?
Background: I'm working in a corporate linux system where I haven't authority to install so much. However I have access to Firefox 45.5.1 and a bad build of Chrome 43.0.2357.81.
Thanks for any idea you come up with.
AFAIK, Firefox currently offers only a "structured view" of JSON responses in the developer tools.
There is a ticket in Bugzilla requesting plain text view.
Not sure about Firefox 45, but the latest release offers a context menu entry which allows copying response text to clipboard. Maybe that helps.
With Rafael's answer I found out what I needed.
Sometimes Copy Response works fine.
When that does not work I can find what I need from Copy All As HAR, which contains more or less everything before "now".
Since I'm a newbie I can neither flag up Rafaels answer nor flag that this question has been answered.
From my perspective I am fully satisfied and the case can be closed.
Let's say someone is writing a reply to an online forum on their iPhone when they lose connection.
Is it possible to use HTML5 local storage to save their submission and post it when they get connection back?
If so, how do I tell if the phone has a connection or not?
Yes you can by implementing your custom logic into the app.
To see if a connection is available you could either use navigator.onLine flag (but it seems that is not completely reliable):
Does Safari and/or WebKit implement the equivalent of window.navigator.online?
http://html5demos.com/offline
or try to load content from the internet and see if it's possible or not:
Checking online status from an iPhone web app
Could you not use JavaScript to set a variable and make it a string with the content of whatever the user puts in the box? You could use getElementById or similar to get the content from the form.
Then, store it in a "cookie". If you don't know how to do this, here is a quick run down on javascript cookies from w3: http://www.w3schools.com/js/js_cookies.asp
Then on page load you could have it load the cookie and make the value of the form equal to the variable you declared earlier.
The best approach (in the light of navigator.onLine behaving inconsistently in different browsers) would be to save whatever the user is typing to localStorage every few seconds or every few keystrokes.
If the page is reloaded again, then you can make sure to first see if there is anything stored in the localStorage key, and if so, then load that into the text box and the user can continue from where he left off.
You can also take a look at the 'going offline with web storage' section of this article http://dev.opera.com/articles/view/taking-your-web-apps-offline-web-storage-appcache-websql/
I want to have a html file with javascript. Then I want to have some images in this file. I want to send this html file to my friends (per e-mail). I want them to see my html file with images but I do not want to send them all files with all images. It would be nice to send them just one file.
I also do not want to have images on a web-server.
I also do not want to send them an archive with all the files (since they then need to open this archive).
Do I want to much or it's possible to do what I want?
ADDED
I do not want my friends to see the html file in a mail-client. I want to send a file as an attachment. So, they can save it and then open with a browser.
Yes, it is possible:
# HTML
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA................." />
# CSS
background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA.................)
File source is encoded using Base64 algorithm that allows easily represent binary data as normal text.
Find out more on wikipedia: Data URI scheme.
Depending on whether the mail client supports it, you could in theory use the data URI scheme, like so:
<img src="data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
vr4MkhoXe0rZigAAAABJRU5ErkJggg==" alt="Red dot" />
Again, the support is mail client dependent. Some might not support it at all. Some might truncate after a X amount of bytes. Etcetera. As far as I know there aren't many of them. Further I don't see another ways to inline images in HTML like that. Until the support is widespread, your best bet is really to send the images along as an attachment.
Update as per the OP's update: well, most of the modern webbrowsers supports it. The aforementioned Wikipedia link even mentions them in detail.
Data URIs are currently supported by the following web browsers:
Gecko-based, such as Firefox, XeroBank, Camino, Fennec and K-Meleon
Konqueror, via KDE's KIO slaves input/output system
Opera (including devices such as the Nintendo DSi or Wii)
WebKit-based, such as Safari (including on iPhones), Android's browser, Epiphany and Midori (WebKit is a derivative of Konqueror's KHTML engine, but Mac OS X does not share the KIO architecture so the implementations are different), as well as Webkit/Chromium-based, such as Chrome and Iron
Internet Explorer 8: Microsoft has limited its support to certain "non-navigable" content for security reasons, including concerns that JavaScript embedded in a data URI may not be interpretable by script filters such as those used by web-based email clients. Data URIs must be smaller than 32 KiB.
Note that IE8 truncates the string after 32KB. So, as long as the images aren't that large, you could use the data URI scheme for IE8 users. It's not supported on IE7 and lower.
I am not aware of a way to accomplish what you're after with 100% certainty it will work.
Is there a way to forgo the images? Perhaps an ascii representation instead? (something like this http://www.text-image.com/)
The archive would be the only "single file" option that I'm aware of.
You cant execute javascript from a mail client. You can inline the images, but you will need a library because doing it by hand is non-trivial.
You should just send them a link.
Why don't you just link the images with relative paths, and bundle them in a folder with the html file and send it archived and compressed (zip or tarball, depending on preference)?
If you just want to send one file, just zip it using your favorite compression program.
You should never, under any circumstances, send email whose body is HTML. Send plain text mail with the images as MIME attachments, or better yet, put the images on a website (I hear Flickr is quite good ;-) and send them URLs.
I'm going to say it again, because it needs to be said more often: email must be plain text.