4 ms·

This stuff all bugs me. On my 4 year old Mac sometimes app's just won't start. They bounce once then exit. The only fix is to restart. No idea why. Been happeni

by bobsy 14y ago

This stuff all bugs me. On my 4 year old Mac sometimes app's just won't start. They bounce once then exit. The only fix is to restart. No idea why. Been happening for years. In Firefox on Windows. I write a bad bit of JavaScript and the browser just freezes and there is nothing I can do apart from ctrl+alt+del. I really don't know why tab's aren't sand boxed to at least let you exit them. Photoshop has minor annoyances. If the color picker is open new files don't open. Been like that for 4 versions. For some reason Filezilla refuse's to open a directory sometimes and hangs for about a minute before letting you retry. To speed this up you can press the disconnect button. Been like this for ages across all my computers.. I have some bugs in my product which are simply too time intensive to fix with the current schedule of features which I need to implement. If I was running things these bugs would be cleaned up first but.. sales is running the show and the next feature will kick start a new promotion and so on. For us at least, there is too much demand to move forward and not enough developers to maintain this development speed. This is why bugs creep into the product and this is why some of the more obscure ones can still be found in the product 30/60/90 day's after being reported.

pmjordan 14y ago
I write a bad bit of JavaScript and the browser just freezes This one always gets me. The browser people are (rightly) obsessed with security, but a simple DoS attack like this has worked for years.
- jiggy2011 14y ago
  Basically this is just the halting problem.
  - rand_r 14y ago
    The browser doesn't have to know or care if some javascript on a page is doing an infinite loop. It's quite possible to sandbox a tab so that it can't take down the browser, just like an OS sandboxes processes so that one can't take down the kernel and other processes just from using too much CPU.
    - jiggy2011 14y ago
      That is true in that Chrome always seems handle this better than Firefox for example. I guess it is to do with scheduling the browser UI threads and the JS threads. Although perhaps there are issues with locks and contention because there is probably some shared state between the browser UI thread and the JS engine/DOM on that tab. Thing is once you start implementing stuff inside the browser to handle these situations your browser is moving away from being a document reader program and into the realms of being a full blown OS in it's own right running on top of another OS with shared state between the two. That adds a load of complexity on it's own.
      - pmjordan 14y ago
        Even without a true sandbox, and with JITed/compiled code, you should be able to run it on a stack of its own, either a distinct kernel thread or a user space thread. If the code doesn't call out to event-handling code frequently enough, a watchdog thread can send it a signal; the signal handler may then choose to cause the thread to pause execution or reschedule or whatever. It's not exactly simple, but also not that outlandishly difficult compared to creating the JIT compiler in the first place! Of course, it depends if you're merely having to avoid blocking the UI thread or if you're also interested in preventing runaway CPU usage. Browsers stopped being document readers well over a decade ago, even if they seem like one to the user.
        jiggy2011 14y ago
        I don't think it's so much technical difficulty as much as it is that you are dealing with metrics that are hard to pin down. For example, how frequently should the UI code be called out to? I guess that would depend on the speed of the computer it is running on. If it's a very slow computer then stuff is just going to be slow whatever you do , doesn't mean it's crashed. Otherwise you'd end up with a situation where you have to say "sorry , your computer doesn't meet the minimum requirements to view this webpage". Also expectations are going to differ depending on the use case. For example if I load up a huge 1GB spreadsheet I can live with the fact that the spreadsheet program is going to be unusable for a minute or two while it loads the data. On the other hand if I click on a link and the page on the other end has a buggy flash applet or whatever then having my browser suddenly lock up is way more frustrating. I suppose part of this stems from the fact that sometimes a browser is a document reader and sometimes it's an application runtime but there's no way to tell which it should be for a particular page. You could add a header or something but that would just get horribly abused.
- icebraining 14y ago
  After a bit, Firefox pauses the script and asks if you want to terminate it. It's not a real problem in my experience.
rwallace 14y ago
> In Firefox on Windows. I write a bad bit of JavaScript and the browser just freezes and there is nothing I can do apart from ctrl+alt+del. I really don't know why tab's aren't sand boxed to at least let you exit them. In Chrome they are, that's why I switched. Try it and see?

by bobsy 14y ago

pmjordan 14y ago

I write a bad bit of JavaScript and the browser just freezes This one always gets me. The browser people are (rightly) obsessed with security, but a simple DoS attack like this has worked for years.

jiggy2011 14y ago
Basically this is just the halting problem.
- rand_r 14y ago
  The browser doesn't have to know or care if some javascript on a page is doing an infinite loop. It's quite possible to sandbox a tab so that it can't take down the browser, just like an OS sandboxes processes so that one can't take down the kernel and other processes just from using too much CPU.
  - jiggy2011 14y ago
    That is true in that Chrome always seems handle this better than Firefox for example. I guess it is to do with scheduling the browser UI threads and the JS threads. Although perhaps there are issues with locks and contention because there is probably some shared state between the browser UI thread and the JS engine/DOM on that tab. Thing is once you start implementing stuff inside the browser to handle these situations your browser is moving away from being a document reader program and into the realms of being a full blown OS in it's own right running on top of another OS with shared state between the two. That adds a load of complexity on it's own.
    - pmjordan 14y ago
      Even without a true sandbox, and with JITed/compiled code, you should be able to run it on a stack of its own, either a distinct kernel thread or a user space thread. If the code doesn't call out to event-handling code frequently enough, a watchdog thread can send it a signal; the signal handler may then choose to cause the thread to pause execution or reschedule or whatever. It's not exactly simple, but also not that outlandishly difficult compared to creating the JIT compiler in the first place! Of course, it depends if you're merely having to avoid blocking the UI thread or if you're also interested in preventing runaway CPU usage. Browsers stopped being document readers well over a decade ago, even if they seem like one to the user.
      - jiggy2011 14y ago
        I don't think it's so much technical difficulty as much as it is that you are dealing with metrics that are hard to pin down. For example, how frequently should the UI code be called out to? I guess that would depend on the speed of the computer it is running on. If it's a very slow computer then stuff is just going to be slow whatever you do , doesn't mean it's crashed. Otherwise you'd end up with a situation where you have to say "sorry , your computer doesn't meet the minimum requirements to view this webpage". Also expectations are going to differ depending on the use case. For example if I load up a huge 1GB spreadsheet I can live with the fact that the spreadsheet program is going to be unusable for a minute or two while it loads the data. On the other hand if I click on a link and the page on the other end has a buggy flash applet or whatever then having my browser suddenly lock up is way more frustrating. I suppose part of this stems from the fact that sometimes a browser is a document reader and sometimes it's an application runtime but there's no way to tell which it should be for a particular page. You could add a header or something but that would just get horribly abused.
icebraining 14y ago
After a bit, Firefox pauses the script and asks if you want to terminate it. It's not a real problem in my experience.

rwallace 14y ago

> In Firefox on Windows. I write a bad bit of JavaScript and the browser just freezes and there is nothing I can do apart from ctrl+alt+del. I really don't know why tab's aren't sand boxed to at least let you exit them. In Chrome they are, that's why I switched. Try it and see?