You WILL print this page.



  • Not sure if this is a firefox problem or what, but i was linked to the printer-friendly version of a wired.com article, and this nice dialog popped up 

    [URL=http://imageshack.us][IMG]http://img508.imageshack.us/img508/1875/picture1aj2.png[/IMG][/URL]
    By [URL=http://profile.imageshack.us/user/seventoes]seventoes[/URL]

     



  • Apple's so great at user friendly UIs that they figure nobody would have gotten to that dialog unless they were committed to printing.  Not like some jackass would use JavaScript to try and make every person who reads a particular Digg article print it.

    For the record, windows (firefox) gave me a cancel item for that page.  God help us if JavaScript allows us to override it.  Did you try printing 0 copies?
     



  • @vt_mruhlin said:

    Apple's so great at user friendly UIs that they figure nobody would have gotten to that dialog unless they were committed to printing.

    everything is an excuse for apple bashing, isnt it? :P 



  • Of course. They deserve it anyway.



  • @aythun said:

    Of course. They deserve it anyway.

    Oh you're so right. After all, it's not like the OP said this was while using FIREFOX or that Apple would dare let developers design something like a cross-platform print dialog. In a project that has 400k entries in Bugzilla, surely the fault lies with Apple. They deserve it! - QED.



  • @sootzoo said:

    @aythun said:

    Of course. They deserve it anyway.

    Oh you're so right. After all, it's not like the OP said this was while using FIREFOX or that Apple would dare let developers design something like a cross-platform print dialog. In a project that has 400k entries in Bugzilla, surely the fault lies with Apple. They deserve it! - QED.

    I don't know how it works on Apple, but on Windows, Firefox calls the system print dialog. Chrome controls behave subtly different than native Windows controls, so you can see that it is the actual dialog and no chrome replica. So in this case, it WOULD be Apple's fault.



  • I wasn't talking about this specifically. Apple as a whole is definitely deserving to be ridiculed.

    And yeah, Firefox calls the native print thingy in Linux as well.



  • @PSWorx said:

    @sootzoo said:

    @aythun said:

    Of course. They deserve it anyway.

    Oh you're so right. After all, it's not like the OP said this was while using FIREFOX or that Apple would dare let developers design something like a cross-platform print dialog. In a project that has 400k entries in Bugzilla, surely the fault lies with Apple. They deserve it! - QED.

    I don't know how it works on Apple, but on Windows, Firefox calls the system print dialog. Chrome controls behave subtly different than native Windows controls, so you can see that it is the actual dialog and no chrome replica. So in this case, it WOULD be Apple's fault.

    Except, that's not quite the standard print dialog from OSX (at least not the 10.4 version) - it's missing quite a few options. For instance, the selection of a particular printer, the other print options, etc.  For some reason, on that person's machine, there is a problem with what the application thinks it's telling the operating system, and what the operating system thinks the applicaiton is telling it.  In this case, either the application is making assumptions about the type of dialog to call and erroneously specifies (or does not specify) the full dialog. The other alternative is that something is munged with the printer drivers on that particular person's machine and bits of the .nib are messed up.

    The only thing we know for sure is that the dialog box that is presented doesn't make any sense.



  • And yeah, Firefox calls the native print thingy in Linux as well.
    The native what, now?


  • @PSWorx said:

    @sootzoo said:

    @aythun said:

    Of course. They deserve it anyway.

    Oh you're so right. After all, it's not like the OP said this was while using FIREFOX or that Apple would dare let developers design something like a cross-platform print dialog. In a project that has 400k entries in Bugzilla, surely the fault lies with Apple. They deserve it! - QED.

    I don't know how it works on Apple, but on Windows, Firefox calls the system print dialog. Chrome controls behave subtly different than native Windows controls, so you can see that it is the actual dialog and no chrome replica. So in this case, it WOULD be Apple's fault.


    Not necessarily -- this is native, but it isn't a standard print dialog. In fact, even when Firefox is working right, it doesn't conform to Apple's specifications (Firefox ought to be using sheets for print dialogs, but isn't), so this is almost certainly an issue on the Firefox side.



  • Just printed something from the Wired.com site on FFX/Mac, and it works fine for me.

    The OP's dialog is fucked in strange ways by unknown assailants.



  • @seventoes said:

    Not sure if this is a firefox problem or what, but i was linked to the printer-friendly version of a wired.com article, and this nice dialog popped up 


     

    Nice,

    i suppose for soem reason, the  top panel of the dialog (where you choose printer options) and the right panel (containing the cancel button) could not be created, leaving you with this :D



  • @tchize said:

    @seventoes said:

    Not sure if this is a firefox problem or what, but i was linked to the printer-friendly version of a wired.com article, and this nice dialog popped up 

    Nice,

    i suppose for soem reason, the  top panel of the dialog (where you choose printer options) and the right panel (containing the cancel button) could not be created, leaving you with this :D

     Some sort of low memory/resource handle situation? Does that happen on Macs or do they fail in other exciting ways?
     



  • @Kemp said:

    Some sort of low memory/resource handle situation? Does that happen on Macs or do they fail in other exciting ways?

    It looks a lot like when Windows runs out of window handles. I don't know if OSX is similar to windows in this way or not, but that's what it looks like. It's not a problem very often in XP, because it has a 32-bit window handle (max ~4,000,000,000 windows) and cleans up after any applications that don't release them correctly. I last saw it in Windows '98, which had a 16-bit window handle, so a max of 65,535 windows, and didn't clean up the handles used by bad apps or apps that crashed. As every button is a window, the window handles in 98 got used up pretty fast if you launched too many complex apps at once.



  • This reminds me of some interesting dialogs my mac gave me.


    In hindsight though any OS would start doing that after a few kernel panics, and on a dying drive.



  • @Thief^ said:

    @Kemp said:

    Some sort of low memory/resource handle situation? Does that happen on Macs or do they fail in other exciting ways?

    It looks a lot like when Windows runs out of window handles. I don't know if OSX is similar to windows in this way or not, but that's what it looks like. It's not a problem very often in XP, because it has a 32-bit window handle (max ~4,000,000,000 windows) and cleans up after any applications that don't release them correctly. I last saw it in Windows '98, which had a 16-bit window handle, so a max of 65,535 windows, and didn't clean up the handles used by bad apps or apps that crashed. As every button is a window, the window handles in 98 got used up pretty fast if you launched too many complex apps at once.



    I sort of doubt it uses the full 32 bits, firstly because some of XP's "handles" are actually pointers to internal data structures of kernel32, user32, etc. Don't know if it applies to window handles, but I've observed it with some handles I inadvertantly "follow"ed in OllyDbg. (Any non-pointer handles are probably indices into an array, so you still probably wouldn't see it go out to 4 billion elements.) Secondly because after my XP's been running and heavily used for about 4 days to a week, it runs out of window handles. Some windows refuse to appear at all, others appear with important parts missing. I believe this is a handle leak in Explorer, as logging off and back on (without reboot) or simply killing and restarting Explorer from Task Manager (provided it will come up) usually fixes it. And thirdly because each window obviously requires more than 1 byte to represent, and considering that I have 1 GB physical RAM plus 3 GB pagefile, and this is happening well before I get any out-of-memory errors...

    Also, I never saw this happen on my old Win98. Probably because it couldn't make it though one day without crashing. Much less a week.

    OSX is BSD-based, so you're dealing with a (possibly modified?) X server. Don't know enough about X to say if there's a potential problem like this, and if so, whether it's smart enough to keep one handle-leaking app from screwing up everything else running in that session.



  • @joemck said:

    OSX is BSD-based, so you're dealing with a (possibly modified?) X server. Don't know enough about X to say if there's a potential problem like this, and if so, whether it's smart enough to keep one handle-leaking app from screwing up everything else running in that session.

    X has its own family of problems (notably the pixmap cache and colourmaps), but this isn't one of them. However, macosx doesn't use X for most things.



  • @asuffield said:

    @joemck said:

    OSX is BSD-based, so you're dealing with a (possibly modified?) X server. Don't know enough about X to say if there's a potential problem like this, and if so, whether it's smart enough to keep one handle-leaking app from screwing up everything else running in that session.

    X has its own family of problems (notably the pixmap cache and colourmaps), but this isn't one of them. However, macosx doesn't use X for most things.

    OS X doesn't use X for [i]anything at all[/i] out of the box. There are exactly zero OS X components that require the optional X11 install.



  • @joemck said:

    @Thief^ said:

    @Kemp said:

    Some sort of low memory/resource handle situation? Does that happen on Macs or do they fail in other exciting ways?

    It looks a lot like when Windows runs out of window handles. I don't know if OSX is similar to windows in this way or not, but that's what it looks like. It's not a problem very often in XP, because it has a 32-bit window handle (max ~4,000,000,000 windows) and cleans up after any applications that don't release them correctly. I last saw it in Windows '98, which had a 16-bit window handle, so a max of 65,535 windows, and didn't clean up the handles used by bad apps or apps that crashed. As every button is a window, the window handles in 98 got used up pretty fast if you launched too many complex apps at once.



    I sort of doubt it uses the full 32 bits, firstly because some of XP's "handles" are actually pointers to internal data structures of kernel32, user32, etc. Don't know if it applies to window handles, but I've observed it with some handles I inadvertantly "follow"ed in OllyDbg. (Any non-pointer handles are probably indices into an array, so you still probably wouldn't see it go out to 4 billion elements.)

    True, but if the windows take 1KB of system memory then out of XP 32 bit's 2GB maximum system mem that's still 2,000,000 windows. The 3 apps I have running right now using the most handles (object handles, according to task manager, which I think includes windows) are: Visual Studio: 6,463, An instance of SvcHost.exe: 2,170, and Outlook: 1065. The count on the SvcHost one is changing constantly, but averaging ~2,170. I have 64 processes running, which puts me far too close to 98's handle limit, but a long way from XP's, which is fortunately what I'm using.

    @joemck said:

    Secondly because after my XP's been running and heavily used for about 4 days to a week, it runs out of window handles. Some windows refuse to appear at all, others appear with important parts missing. I believe this is a handle leak in Explorer, as logging off and back on (without reboot) or simply killing and restarting Explorer from Task Manager (provided it will come up) usually fixes it. And thirdly because each window obviously requires more than 1 byte to represent, and considering that I have 1 GB physical RAM plus 3 GB pagefile, and this is happening well before I get any out-of-memory errors...

    Also, I never saw this happen on my old Win98. Probably because it couldn't make it though one day without crashing. Much less a week.

    OSX is BSD-based, so you're dealing with a (possibly modified?) X server. Don't know enough about X to say if there's a potential problem like this, and if so, whether it's smart enough to keep one handle-leaking app from screwing up everything else running in that session.

    I definitely don't have any handle leak, but you can use task manager to check. Do you have the newest service pack? I'd imagine there were a fair few handle leaks (and other problems) in the earlier versions.

    Windows 98 was actually spectacularly stable given that an application crashing could kill windows (only drivers have that privelidge in XP). You could keep it up for ages if you only ran stable programs.

    I don't know much about OSX either, I was just commenting that it looked like the same problem :)
     



  • @Thief^ said:

    Windows 98 was actually spectacularly stable given that an application crashing could kill windows (only drivers have that privelidge in XP).

    Correction: in XP, drivers, any program that uses DirectX, any program that uses OpenGL, and any program running as an administrator or power user (if you count the scores of unfixed local exploits - Microsoft only release security patches for remote exploits and things that are generating bad press attention) can kill windows.

    The easiest way is usually to muck around with the video card. They can crash the hardware, so hard that not even the power button works any more, if you render the right kinds of nonsense - it's so easy to do that it happens from time to time just when debugging regular 3d code. It's important to realise that your video card can be programmed both to write to system memory and to abuse the PCI bus; unfettered access to the video card is just as good as running in kernel space, and neither the ATI nor nVidia drivers have any kind of security in place (since that would reduce framerates).



  • For the Direct-X, OpenGL and "mucking around with the graphics card" cases, it's the drivers' fault for allowing a user-space program enough access to crash the pc. Technically the crash happens at the hardware or driver level, the program can't do it alone.



  • @asuffield said:

    @Thief^ said:

    Windows 98 was actually spectacularly stable given that an application crashing could kill windows (only drivers have that privelidge in XP).

    Correction: in XP, drivers, any program that uses DirectX, any program that uses OpenGL, and any program running as an administrator or power user (if you count the scores of unfixed local exploits - Microsoft only release security patches for remote exploits and things that are generating bad press attention) can kill windows.

    The easiest way is usually to muck around with the video card. They can crash the hardware, so hard that not even the power button works any more, if you render the right kinds of nonsense - it's so easy to do that it happens from time to time just when debugging regular 3d code. It's important to realise that your video card can be programmed both to write to system memory and to abuse the PCI bus; unfettered access to the video card is just as good as running in kernel space, and neither the ATI nor nVidia drivers have any kind of security in place (since that would reduce framerates).

    I can only wonder what you're doing that it would disable the power button.  I've seen BSODs, Corruption that destroyed system files, and some other oddities related to overwriting memory and/or overloading the various busses, but I've never seen the power button be disabled before.  I do hobbyist game dev and have a penchant for trying things that aren't documented.  A lot of the more common issues are recoverable if you're patient enough (which most aren't - granted) and the OS will pull out of it given enough time.

    Regardless, there aren't many OSes that do security on driver level stuff.  You write a driver with an exploitable security vulnerability - it will bring down the OS regardless of what you're talking about unless you do explicit driver security.  When things run in Kernel Mode, they have access to quite a bit of stuff.  Windows does a pretty good job of securing common user mode -> kernel mode entry points.  But if the vendor goes around those, I'm not sure what you expect to happen.  If you have unfettered access to the video card (whatever you're meaning by that) then it's not like running in kernel space.  It is running in kernel space.

    But anyway, an application running entirely in usermode will have a very tough time BSOD'ing the machine.  Whereas in Windows 98, you could write 1 bad pointer and bring the whole thing down.



  • The "power button" on a modern machine is just a button that triggers a callback, and doesn't directly affect the power. If you press it, it calls into the OS, if you hold it, it calls into the bios. If you screw up both, the power button no longer works :)



  • @Thief^ said:

    The "power button" on a modern machine is just a button that triggers a callback, and doesn't directly affect the power. If you press it, it calls into the OS, if you hold it, it calls into the bios. If you screw up both, the power button no longer works :)

    But my point is how do you actually get to that point?  Disabling the soft shutoff, sure I can see that I've had app hangs disable that before sometimes.  But the press & hold for 4 seconds?

    I suppose thinking about it, I wouldn't be suprised if you could pull it off on Vanilla Vista...the power management stuff on that OS is really poor (not that I can complain too much, ACPI and what-such are incredibly complex and quite painful to attempt to read).



  • Well, at least your forced one copy of the one page document is going to be collated.



  • @ShadowWolf said:

    @Thief^ said:

    The "power button" on a modern machine is just a button that triggers a callback, and doesn't directly affect the power. If you press it, it calls into the OS, if you hold it, it calls into the bios. If you screw up both, the power button no longer works :)

    But my point is how do you actually get to that point?  Disabling the soft shutoff, sure I can see that I've had app hangs disable that before sometimes.  But the press & hold for 4 seconds?

    I looked into it once - if you persuade the video card to grab the PCI bus and DMA controller in a certain way and then crash so that it never releases them, then the CPU won't be able to reclaim access to the memory bus, so it won't ever be able to load any more instructions. Since the press-and-hold feature still requires the CPU to trigger the power shutdown, it won't work, and you have to go yank the power cable.

    When I was at university doing a course in 3d rendering, there was an entire row of lab workstations that would do this every damn time a program with an opengl context, running under the debugger and currently inside a call to the video driver, was suspended so that the debugger should have taken control. This was very irritating. I haven't encountered another case where it happened so reliably, but I have managed to accidentally do it three or four times in the past couple of years, and I don't even work with rendering stuff very often.



  • @asuffield said:

    @ShadowWolf said:

    @Thief^ said:

    The "power button" on a modern machine is just a button that triggers a callback, and doesn't directly affect the power. If you press it, it calls into the OS, if you hold it, it calls into the bios. If you screw up both, the power button no longer works :)

    But my point is how do you actually get to that point?  Disabling the soft shutoff, sure I can see that I've had app hangs disable that before sometimes.  But the press & hold for 4 seconds?

    I looked into it once - if you persuade the video card to grab the PCI bus and DMA controller in a certain way and then crash so that it never releases them, then the CPU won't be able to reclaim access to the memory bus, so it won't ever be able to load any more instructions. Since the press-and-hold feature still requires the CPU to trigger the power shutdown, it won't work, and you have to go yank the power cable.

    When I was at university doing a course in 3d rendering, there was an entire row of lab workstations that would do this every damn time a program with an opengl context, running under the debugger and currently inside a call to the video driver, was suspended so that the debugger should have taken control. This was very irritating. I haven't encountered another case where it happened so reliably, but I have managed to accidentally do it three or four times in the past couple of years, and I don't even work with rendering stuff very often.

    I love debugger deadlocks.  Nothing more ironic than the tool you're supposed to use to fix problems killing your machine.



  • The classic one is having a full-screen game crash, and it not having a crash-handler that switches out of full-screen before passing the crash to the debugger. You end up with the (crashed) game stuck in full screen mode, unable to see what you're doing. Most game development studios use dual-monitor setups to get around this one.

    Well, when they actually develop pc games anyway.



  • @Thief^ said:

    The classic one is having a full-screen game crash, and it not having a crash-handler that switches out of full-screen before passing the crash to the debugger. You end up with the (crashed) game stuck in full screen mode, unable to see what you're doing. Most game development studios use dual-monitor setups to get around this one.

    Well, when they actually develop pc games anyway.

    You don't even need a debugger for this. You just need a badly configured software firewall, then you game can annoy everyday users this way too. I had this happen to me once: The game, while in full screen mode, was trying to connect to the Internet. My firewall didn't know it yet and did its usual thing: Freeze the requesting process and show a confirmation message. Only that the game, since frozen, could not switch back to windowed mode, so the confirmation message wasn't visible. Same applied to the task manager. So the only way I could break out was to reboot ("short press" on the power button, since it wasn't a "real" deadlock) and change the firewall settings manually. Which I should have done before anyway, I know.



  • @Thief^ said:

    True, but if the windows take 1KB of system memory then out of XP 32 bit's 2GB maximum system mem that's still 2,000,000 windows. The 3 apps I have running right now using the most handles (object handles, according to task manager, which I think includes windows) are: Visual Studio: 6,463, An instance of SvcHost.exe: 2,170, and Outlook: 1065. The count on the SvcHost one is changing constantly, but averaging ~2,170. I have 64 processes running, which puts me far too close to 98's handle limit, but a long way from XP's, which is fortunately what I'm using.
    Actually, I'm pretty sure that every Windows version that can run 16bit programs is limited to ~32000 window handles for compatibility reasons (IIRC, there was an article about this on oldnewthing once). I have no idea if the limit was raised on 64bit Windows.



  • IIRC it uses a mapping table, so 16-bit apps under 32-bit windows are limited to 32000 handles while 32-bit apps are fine.

    Could be wrong though.
     



  • EDIT: (or it would be if I could, stupid timeout): http://blogs.msdn.com/oldnewthing/archive/2005/03/15/395866.aspx :

    To maintain compatibility with 16-bit Windows programs (which still run on Windows XP thanks to the WOW layer), there cannot be more than 65536 window handles in the system, because any more than that would prevent 16-bit programs from being able to talk meaningfully about windows. (Once you create your 65537'th window, there will be two windows with the same 16-bit handle value, thanks to the pigeonhole principle.



  • @PSWorx said:

    @Thief^ said:

    The classic one is having a full-screen game crash, and it not having a crash-handler that switches out of full-screen before passing the crash to the debugger. You end up with the (crashed) game stuck in full screen mode, unable to see what you're doing. Most game development studios use dual-monitor setups to get around this one.

    Well, when they actually develop pc games anyway.

    You don't even need a debugger for this. You just need a badly configured software firewall, then you game can annoy everyday users this way too. I had this happen to me once: The game, while in full screen mode, was trying to connect to the Internet. My firewall didn't know it yet and did its usual thing: Freeze the requesting process and show a confirmation message. Only that the game, since frozen, could not switch back to windowed mode, so the confirmation message wasn't visible. Same applied to the task manager. So the only way I could break out was to reboot ("short press" on the power button, since it wasn't a "real" deadlock) and change the firewall settings manually. Which I should have done before anyway, I know.

    I love this one.  It's why I don't use a software Firewall anymore :)



  • @Thief^ said:

    The classic one is having a full-screen game crash, and it not having a crash-handler that switches out of full-screen before passing the crash to the debugger. You end up with the (crashed) game stuck in full screen mode, unable to see what you're doing. Most game development studios use dual-monitor setups to get around this one.

     

    When games get stuck for various reasons, I usually do [Windows]-R, 'cmd', enter, alt-enter to get the fullscreen command prompt. Then I use my kill.exe to kill the offending application. Sometimes, not even the command prompt gets drawn, so I have to do this blindly.

    Explorer leaks are pretty annoying. I know my Win98 shell had a thread leak; sometimes when I used IE, explorer's thread count would go up never to come down. XP is pretty good except when it tries to read a whole video file just to preview the first frame which is almost always blank, or lock up strugging with a bad/slow codec. Oh, and I hate, hate, HATE when it opens a directory and never releases the handle. Have to kill explorer, open up a command prompt, RD manually and start explorer back up when that happens..

    The sort of problems described above also happen when the system is low on memory. (Is there a failsafe in case close buttons etc. can't get displayed?)
     



  • @asuffield said:

    @Thief^ said:

    Windows 98 was actually spectacularly stable given that an application crashing could kill windows (only drivers have that privelidge in XP).

    Correction: in XP, drivers, any program that uses DirectX, any program that uses OpenGL, and any program running as an administrator or power user (if you count the scores of unfixed local exploits - Microsoft only release security patches for remote exploits and things that are generating bad press attention) can kill windows.

    The easiest way is usually to muck around with the video card. They can crash the hardware, so hard that not even the power button works any more, if you render the right kinds of nonsense - it's so easy to do that it happens from time to time just when debugging regular 3d code. It's important to realise that your video card can be programmed both to write to system memory and to abuse the PCI bus; unfettered access to the video card is just as good as running in kernel space, and neither the ATI nor nVidia drivers have any kind of security in place (since that would reduce framerates).

    I'm not sure if nVidia cards can put any security in place very easily. As I understand it, they're designed to allow user programs to submit commands directly to the graphics card (via one of 32 or so memory-mapped command FIFOs). In fact, the nVidia driver apparently uses said FIFOs to call from userspace into the in-kernel driver by submitting a command that generates an interrupt.


Log in to reply