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.
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.
I am developing an application for an environment where Chrome Version 29.0.1547.62 is used.
As part of the application, there is a requirement for a mailto: link. When this link is clicked, MS Outlook opens with the provided information in a new message.
In general this works as expected, however the following string causes Chrome (including all other Chrome windows) to crash with a message that begins with 'Whoa!'
> mailto:xxxxxxxxxx#xxxxxxxxxx.xxx?body=xxxxxxx%0A%0Axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> %0A%0Axxxxxxxxxxxx x xxxxxxxxxxxxx%0A xxxx%0A xxxx%0A xxxx%0A xxxx%0A
> xxxx%0A%0A xxxxxxx xxx
I have obviously removed all personal information, but the structure is otherwise the same. The issue can be replicated by pasting the link into the omnibox.
Removing one of the x's from the end will cause it to work correctly, making it appear to be a length issue, however simply having a longer body made solely of x's doesn't cause an issue.
My question is:
Has this issue been specifically resolved in a later version of Chrome? If so, then a simple ($.browser.chrome && $.browser.version == 29) check would be sufficient, but if it has not, then I will have more of a problem.
Unfortunately the common fix for adding the GMail handler is not appropriate here, and it is also not possible to add any command line arguments to Chrome on start up, limiting the amount of debug information I can provide.
I have a page in XPages that I use to open and edit a document. There are two ways to open a document in edit-mode: first in read-mode then click a button to put it in edit-mode, or open it directly in edit-mode. Both work in all browsers, yet IE seems to handle both cases differently. We found this out when working with the SWING API.
Opening directly in edit-mode in IE (8/9/10) works, via read-mode to edit-mode doesn't. What we found is that the internal representation of a textarea field differs: when opened in edit-mode, there are more properties, but most importantly, the return+linefeeds are correctly set in both the value and the innerText property.
The button just contains a simple Change Mode action.
Has anyone heard of this anomaly? And does someone know what we did wrong?
PS I'll try to build a simple XPage that shows this behaviour more clearly tomorrow.
For IE switching from read to edit mode, you need a full page refresh
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)