Firefox allows to attach to web workers. You can go to about:debugging, see the list of active workers, and click on "debug" to attach.
But what to do if the application creates a short-lived worker? I want to set a breakpoint, but I cannot do so in advance before the worker is created. (At least, I have not found a way to do so. For instance, setting a breakpoint with the debugger statement does not work in Firefox 54.)
As a very crude workaround, I can delay the startup of the web worker by using setTimeout, so I can use the time to open about:debugging and attach to the new worker. This is not a good solution, however.
Is there an efficient way to set a breakpoint in advance (before the worker is even started)?
I've forked a very simple webworker jsfiddle, and debugger; works in the chrome debug tools, but not in firefox debug tools : https://jsfiddle.net/ckprrLxz/2/
Currently, it is not possible. At least not in Firefox 54.
As a workaround, I would recommend to modify the code so that web workers are reused, at least during debugging. In my specific use case, it was relatively easy to do so. Depending on the situation, it might be more difficult or not even possible. In that case, you have to use other techniques to debug the code. For instance, by writing tests for the web worker code (which might be a good idea, anyway).
Delaying sending the message to the newly created web worker with setTimeout is theoretically also an option, as it gives you some time to attach the debugger. It is certainly not ideal, but it can be used as a last resort.
Related
Context
A game shipped as a progressive web app which has timers (setTimeout, setInterval) and websocket connections to get real-time communication.
What is happening
Everything is fine as long as the user stays in the app. But when the user goes to another tab, or another app or turns off the screen (in case of mobile), it becomes a "hellish unknown world".
Websockets may or may not become "paused" or "turned off"
Timers look like they are being throttled or debounced.
This behaviour seems to depend on browsers and platform and, maybe, even depend on the particular user behaviour. I guess browsers and OS have their own lifecycle / mechanisms to save battery and/or computation.
When the user comes back, the app is in an unknown state and I am struggling to restore the state properly.
Regarding websockets I have auto-reconnection with socket.io and reconnecting-websocket but it's not enough to solve everything.
Looking for answers
What are the "lifecycles" of the different browsers regarding these? Is this documented? When do they decide to turn off and throttle?
What do they do exactly to websockets? Browsers just disconnect them?
What do they do exactly to timers? They throttle them or debounce them or something else?
What happens to javascript execution in general? Paused / destroyed / throttled?
Is there a way to hook into some kind of browser lifecycle event when it's going to turn things off? The only thing I could find might be the visibility API
Is there a way to artificially reproduce this behaviour to be able to test solutions? It's especially hard on desktop. Websockets can't be turned off and chromium developers don't seem in a hurry to help an issue from 2014(!): websockets not included when using connection throttling
Regardless of the above, is there a pragmatic cross-browser solution to detect / solve this problem? (for example from experience, Firefox on desktop seems to behave completely different compared to Chrome, and an iPhone will disconnect far more often than an Android)
Related Links
Safari dropping web socket connection due to inactivity when page not in focus
Not exactly sure, but you could use service workers. As much as I know, they run in background even if your tab is not opened and get terminated if your tab closes.
Btw. lifecycles of browser tabs seem to be different on every browser, since every browser handles it different. From what I see the browser can freeze tabs if it needs more memory for other things.
Here is the docs from Chrome.
I remembered that there are some events, like onload that tell you if a user has left or reopened the tab. You could use these event to reconnect etc..
I would give different advice regarding how to design your app. From what I understand your intention is to add more logic in order to understand if the user is no longer active in the browser. This entails a different problem which is browser specifics to implement that logic. With that in mind, I would instead invest in have better error handling, both in the server and client.
Errors won't be browser-specific. Handling those will make your app more resilient and agnostic to browser changes, that could eventually change, let's say, the way they hibernate a tab, any other feature that a vendor might implement in the future.
This is an idea that you can find in services architecture, but the same pattern applies to any web-app. You might want to look for Design-for-Fail concepts:
Complexity makes it infeasible to assume robustness on the part of the systems upon which one relies. Instead, one needs to design systems and applications at any given layer in the IT stack-based to assume the possibility of failure at lower levels. Design-for-fail necessitates thinking about fault tolerance at all layers. No longer can application developers confine themselves to thinking about functionality.
https://www.oreilly.com/library/view/designing-delivery/9781491903742/ch04.html
Question:
What is the best way to communicate between separate Google Chrome rendering processes (tabs) without the use of a web-server?
Background:
I am writing a large application and recently I decided to try and migrate the whole thing to the browser. Due to where I work this is Google Chrome. Previous the application consisted of a c++ based (Qt) webserver / calculation engine and the browser was only used for the GUI. Now I have moved the calculation engine to javascript and I run it in the browser.
The problem is that the GUI is slightly unstable. It will often stay running for about 12 hours but then crash with an "Aw Snap" error. Before I wasn't worried because it was a simple matter of refreshing the page. Now when the GUI crashes because it is running in the same process as the calculation engine, that crashes also.
Details:
The calculation engine is now a web-page that spawns a number of web-workers. It also opens the GUI (a separate webpage) as a popup window and communicates to it using PostMessage.
The GUI typically needs to read ~ 500 floating point numbers / second (sent as JSON) from the calculation engine and write back ~ 5 numbers / second.
Yesterday I got excited because I discovered the SharedWorker API which I thought would accomplish was I wanted. Today however, I learned that recently modifications were made to Chrome so the SharedWorker actually runs in the same process as the attached tabs and it actually forces all the tabs attached to it into one process. Apparently it didn't used to do this. Does anyone know if there are any browser flags that I can set to revert to the old behavior?
I also have read a little bit about ServiceWorkers and other new APIs such as WebRTC. I have also played around with the storage APIs and thought that maybe they could be used to get two separate processes (tabs) to communicate at the rates that I need.
I want a solution that will work locally (using switches like --allow-file-access-from-files) and that doesn't require plugin installation (since even local plugins are blocked where I work).
NOTE: I saw some other similar questions but they didn't specifically address the need for there to be separate processes (only separate tabs)
Well, it looks like I figured out the answer already. The problem turned out to be how I was trying to open the GUI window.
I had a link on the calculation engine that the user clicked on to open the window:
Open GUI
However, it turns out that adding rel="noreferrer" will cause chrome to open the window in a new process.
Open GUI in new process
After I figured this out, the SharedWorker began to function as I had expected and I was able to keep by engine tab running even when the GUI tab crashed.
I would like to see what the JavaScript interpreter is doing in real-time, which line it is reading and which function it is running, because I would like to make a full debug on every little piece of the JavaScript to make it faster. For this I need some tool to tell me what the interpreter is doing exactly, if it is defining a variable, if it's running a function, if it's in a loop, check the current intervals (defined in setInterval).
As far as I know Firebug can't do that.
Check out the javascript tab in Firebug, it's a full debugger. Set a break point and when your code hits that line you will have full debugging access to variables etc. Chrome has similar functionality in the developer tools which are included in a standard install.
If you're looking to do automated monitoring/analysis of your program, check out Chrome's Debugger Protocol. It provides a programatic API. I believe (but could be wrong) that this is what tools like Web Inspector and node-inspector are built on.
If you want something more than what the standard Firebug/Web Inspector interfaces are built on, you're going to have to either use something like this or start hacking on the internals of the V8 and Gecko JS interpreters.
As the other answer says,if you want to go step by step, setting a debug point is the way to go.
But since you seem interested in improving performance you might want to consider optimizing only the true bottlenecks in your application. To see which functions take the most to run, and other statistics you might want to take a look at console.profile() (available both in firebug and chrome).
Here is an example:
console.profile('myProfile');
//some code you want to know more about
console.profileEnd();
You can also start it manually by clicking the Profile button in the Console panel(in firebug)/ Profile panel (chrome)
In Chrome you might want to also take a look at Heap Snapshots (they tell you about memory usage).
I'm pretty new to workign with Javascript.
In most languages you can run the code quickly locally on your machine. From what I've seen, in JS you generally only use it via the browser, and so I've been uploading my code an viewing its effects in the browser. This has proven very tiresome. Also, if I mak one error, it seems like my JS/JQuery will just do NOTHING, instead of giving me a useful error, message, which is making it painfully slow to code in.
IS there some way to run JS locally to see that it is working as I go? And then only upload it to the web when I'm mostly done? What ways are there for me to do this? What ways aer there for me to unit test the Javascript locally? Say I have some JAML that should render as <p>HI</p>, how do I run this locally in a unit test?
Thanks for the help,
Alex
EDIT:
Thanks for all the great suggestions. I'll have to take a bit of time and go through them to see which ones best help me in my situation.
Since you're using jQuery, I assume that you actually want to manipulate the various elements on your page. So depending on your specific development enviroment, uploading it each time is probably the way to go anyway. If you can set up a dev enviroment on your local machine (not always possible) then go with that.
As an actual answer to your question, I suggest using Chrome's developer tools, it doesn't just have the console, but an element inspector, and a resource tracker (resource tracker is invaluable when working with JSON and AJAX, since invalid json will fail silently)
As far as I know, the firebug plugin for firefox (dont use it myself) has a similar feature set, so if you're more comfortable with that go with it.
Just remember, as a developer, your development (and debuggin) enviroment is just as important as the code that you are writing.
EDIT: Noticed that you mentioned unit testing. There are several unit testing frameworks out there for JS including one that integrates with firebug called FireUnit. Do a quick google search to find more if you want.
You don't need to upload the JS file to a server to test it. Just write an html and declare the js binding
<script
src="js/yourJSFile.js"
type="text/javascript"></script>
Edit the JS file in your favorite editor and then refresh the page to test it.
For unit testing the best option is Selenium. It allows you to record an interaction with the browser and then play it back.
You can use Firebug with Firefox to debug JS, and Google Chrome has a debugger built-in (use the Tools -> Developer Tools menu).
You can run Javascript from the local file on your machine in your browser, so you can skip the uploading step.
Also, I'd recommend using Firefox/Firebug combo for developing Javascript as it will be very handy, especially for the part you mentioned about not seeing what's going wrong with your code.
Even if you upload your javascript it gets downloaded back to you as soon as you visit the webpage that invoques it. Its run client side always. So stick to local and use firebug as the others have said. Google`s developer tool is quite nice too.
In the browser if you open the developer tools, follow the following steps:
1) Navigate to sources
2) Under sources, click snippet and open run.js
3) You can use run.js to write as much code as you want and run it locally only to see if your code is working or not (it will give you output on the console)
4) Also you can get used to some keyboard shortcuts to make it faster for you.
5) For small javascript codes, you can navigate to console and run your code there
If you want to do unit testing with Javascript there are extension of Firebug that can help you with that. I haven't try any of them, so I can't really tell you which one are worth considering, but you can easily find them if you search for the keyword "Firebug unit testing" on Google.
What seems to be comming on top is FireUnit. You can find some information about how it works here.
Consider Spider Monkey, which is a javascript engine separate from a browser. If what you are developing does not involve rendering to a webpage or can be separated from the rendering code (good practice!), then this could be useful.
I prefer Chrome to Firefox and I just found Web Server for Chrome.
It's just a Google App that quickly sets up a web server for you and will be set up anywhere you are logged into Chrome. It only allows file access to your current devices, or if you specify, other devices only on the current LAN.
You just point it to the directory with your index.html file and type http://127.0.0.1:8887 in your browser.
Additionally to the answers given you can use Jasmine for automated testing.
A tutorial that seems to help get started with automated testing on Jasmine is provided by Evan Hahn.
I used it and for me it works like a charm. Especially if test driven development is what you are going for!
Is JavaScript multithreading possible in IE6?
Are there any third party libraries for this?
JavaScript does not support native multithreading in current web browsers. Even if it did, I bet IE 6 wouldn't have supported it :)
Running your scripts in multiple iframes could be one workaround, as Jason Kester suggested in another answer.
In addition, for modern browsers you might be interested in checking out Web Workers, but this is definitely something out of the IE 6's league:
Stack Overflow: JavaScript and Threads
Dive into HTML 5: Web Workers
Firefox 3.5: Web Workers in action
John Resig: Computing with JavaScript Web Workers
Run your tasks in IFrames
Assuming you're talking about multitasking on the client side, you can open n frames on your page, each pointed to a page on your domain.
There are lots of ways to architect it from there. Probably the easiest would be to have a single .js include that you run from each frame. It phones home to parent.readyToGo() or whatever, and gets some work assigned. The worker methods can call something like parent.taskFinished() to report when they're done.
Most importantly, don't listen to anybody telling you not to run your mission critical multithreaded javascript application on IE6. I'm sure you have good reasons:)
There is no way - definitely not in IE6. You can fake it by using lots of window.setTimeout()s.
See Why doesn't JavaScript support multithreading?
Well, HTML5 is coming up with Web-Workers. But i highly doubt there is a library which creates a wrapper for using it in IE6.
Does my browser support web workers?
Google Gears is a plugin that works with IE6 and includes something called WorkerPools. Google Gears does not seem like it is being very actively developed anymore, because it has tried to move most of the ideas of Gears into HTML5. WorkerPools are basically background processes that do not share state and only communicate through messages. In HTML5 this has turned into WebWorkers. You can find more info here: http://code.google.com/apis/gears/api_workerpool.html
If you merely want to write synchronous code and thus avoid having to deal with writing event handlers all over the place, you can try: Strands