Worst. search engine. ever.



  • Okay, so we're hiring at my place, and after interviewing a candidate, some of my coworkers were talking about interviews in the past, and such. One story that they brought up was that of HelpRick.com.
    From what I can gather, Rick was some mortgage broker who heard that Yahoo! et cetera were making millions of dollars in the search engine business, and he wanted a slice of the action. So he hired out some guys to create this site.

    Finding the official site for a business is sometimes harder than it should be. HelpRick is here to give it to you straight. Go ahead. Give it a try.




  • Wow, that's ... special.

    Tried my employer, no good. Well, it's a major retailer but it's a major Australian retailer, maybe Rick hasn't heard about this small south Pacific island.

    Tried one of the biggest and most popular photographic retailers in NYC... nada.

    OK, what's recognisable from the banner? Errr, Playboy appears prominently. I gave that a try, and suddenly my screen is filled with exactly zero search results. I bet Playboy are worried, because their site is so difficult to find.

    But the good news is, on Monday morning, the people operating the site are going to see a huge spike in their usage stats (assuming they know how to collect them?) and think "wheee, we're on our way to our first billion".



  • It also couldn't help me find Walmart or McDonalds (got an error searching for McDonald's, presumably someone isn't escaping quotation marks).

    Maybe that's why it can't find anything - someone's already been through and dropped all their tables?
     







  • "Hi, I'm from the Drop Table Company, and I can't seem to find anything with your search engine"



  • This is not going to turn out well.



  • Hel Prick?

     

    Looks like Rick could use all the help he can get.

    The outgoing links aren't tracked either. So basically it's a small directory, with no sql protection.

    And none of the browse links work.
     



  • The Manufacturing link ... "works" ...





  • I was just about to post that very link

    I wonder if the dir or pg parameters are sanitised.. nope, direct passthrough!

     

    http://helprick.com/theme/14382/index.php?dir=a&pg=b

    Warning: main(../../a/b): failed to open stream: No such file or directory in /var/www/vhosts/cat.doublepi.com/httpdocs/theme/14382/index.php on line 57

     

    I wonder if he's left the db details in a file called db.inc or something. 



  • @dhromed said:

    "Hi, I'm from the Drop Table Company, and I can't seem to find anything with your search engine"

    Somehow, I think it would be a great Nigerian scam name.

    Dear sir
    My name is MR DROP TABLE ...



  • reminds me of this comic:
    exploit

     



  • For how long will every thread remotely connected to SQL injection feature this comic? Is it that brillant?

     



  • @TDC said:

    For how long will every thread remotely connected to SQL injection feature this comic? Is it that brillant?

     

     

    Forever. Yes. 



  • @bairy said:

    I was just about to post that very link

    I wonder if the dir or pg parameters are sanitised.. nope, direct passthrough!

     

    http://helprick.com/theme/14382/index.php?dir=a&pg=b


    Warning: main(../../a/b): failed to open stream: No such file or directory in /var/www/vhosts/cat.doublepi.com/httpdocs/theme/14382/index.php on line 57

     

    I wonder if he's left the db details in a file called db.inc or something. 

    Unfortunately, while the 'tards who programmed this are completely FAIL, the shared host seems to have sane policies (open_basedir) in effect...

    http://helprick.com/theme/14382/index.php?dir=../a&pg=b

     

    And no good on the db.inc idea - the files appear to be include()d.

    But what's the point, when any search box is a SQL prompt... 



  • @Cypher87 said:

    reminds me of this comic:

    [...]

    Every time you hotlink a image Michael Jackson and Gary Glitter sells another album. Please think of the children! Or possibly make them stop thinking about the children.



  • @Fred Foobar said:

    And no good on the db.inc idea - the files appear to be include()d.

    But what's the point, when any search box is a SQL prompt... 

    As far as I'm aware, php doesn't let you stack multiple queries using a ;  meaning the search box only acts as a 'SELECT .. FROM specified_table' query. 



  • @bairy said:

    As far as I'm aware, php doesn't let you stack multiple queries using a ;  meaning the search box only acts as a 'SELECT .. FROM specified_table' query. 

    PHP couldn't care less about how many queries you embed in a string. PHP doesn't know what a query is. "SELECT * FROM Users" is the exact same as "Hello, world!".

    The database drivers, on the other hand, DO know what a query is. I can't speak for all of them, but the MySQL client libraries don't allow multiple queries to be embedded in the string passed to the query functions. It'll spit out a syntax error.


  • Considered Harmful

    @MarcB said:

    @bairy said:

    As far as I'm aware, php doesn't let you stack multiple queries using a ;  meaning the search box only acts as a 'SELECT .. FROM specified_table' query. 

    PHP couldn't care less about how many queries you embed in a string. PHP doesn't know what a query is. "SELECT * FROM Users" is the exact same as "Hello, world!".

    The database drivers, on the other hand, DO know what a query is. I can't speak for all of them, but the MySQL client libraries don't allow multiple queries to be embedded in the string passed to the query functions. It'll spit out a syntax error.

    You can, however, union any other table to the query.



  • @MarcB said:

    The database drivers, on the other hand, DO know what a query is. I can't speak for all of them, but the MySQL client libraries don't allow multiple queries to be embedded in the string passed to the query functions. It'll spit out a syntax error.

    Oops, yes that's what I meant. 



  • En espanol, por favor...

    Has anyone else noticed that the "results" listing (but not the main page) has a series of little flags at the bottom right corner?

    I knew what would happen, but I clicked on one anyway. Made me laugh out loud, yes it did.




  • Daniel Beardsmore wrote the following post at 11-11-2007 4:23 PM:
    http://helprick.com/theme/14382/index.php?dir=products&pg=list.php&cat=0&parent=0
     

     

    My Eyes! Please give back my eyesight!



  • @Rasit said:

    @Cypher87 said:

    reminds me of this comic:

    [...]

    Every time you hotlink a image Michael Jackson and Gary Glitter sells another album. Please think of the children! Or possibly make them stop thinking about the children.


    xkcd doesn't seem to bother blocking hot linking (they even go as far as to post the direct url under each comic).



  • Help Rick's extensive database of dozens of websites is sure to contain what I'm looking for!



  • [quote user="Renan "C#" Sousa"]

    Fun!

    http://www.helprick.com/ ... while(true){alert%28%22Owned+by+Renan%22%29%3B}...

    [/quote]

    *sigh*

    Everyone, please don't click this rubbish. You'll get (if you didn't check) an endless series of JavaScript alert boxes.

    If you're wondering how to get out of them, and you use Firefox, press ctrl-W (close tab) immediately after clicking OK. You'll get one more alert after the tab closes and that's that. I am fortunate that I already had to figure this out before when some other retard sent me to a page that did this -- I spent far too long solving that one in order to avoid having to terminate Firefox. (In iCab, I think you press cmd-shift-J with a JavaScript alert dialog open, and the script will terminate when the dialog closes.)



  • @Daniel Beardsmore said:

    [quote user="Renan "C#" Sousa"]

    Fun!

    http://www.helprick.com/ ... while(true){alert%28%22Owned+by+Renan%22%29%3B}...

    sigh

    Everyone, please don't click this rubbish. You'll get (if you didn't check) an endless series of JavaScript alert boxes.

    If you're wondering how to get out of them, and you use Firefox, press ctrl-W (close tab) immediately after clicking OK. You'll get one more alert after the tab closes and that's that. I am fortunate that I already had to figure this out before when some other retard sent me to a page that did this -- I spent far too long solving that one in order to avoid having to terminate Firefox. (In iCab, I think you press cmd-shift-J with a JavaScript alert dialog open, and the script will terminate when the dialog closes.)

    [/quote]

    So... TRWTF is you don't read urls before randomly clicking on them?I hear your bank forgot your credentials, go fill them in their website: http://c1tizensbank.com

     



  • @merreborn said:

    Help Rick's extensive database of dozens of websites is sure to contain what I'm looking for!

    The sad thing is that even their chief use-case fails. Try looking for 'Nissan', a well-known company whose website is actually not at nissan.com. Nope. Not there.



  • tryed "play boy" (and playboy) cause their bunny is shown in the upper banner. Gues what? No results.

    At last I made a successful search showing a result: "google"



  • 0 results when I search for helprick in helprick, now that's either kinda clever or a bit of an oversight.



  • @Daniel Beardsmore said:

    [quote user="Renan "C#" Sousa"]

    Fun!

    http://www.helprick.com/ ... while(true){alert%28%22Owned+by+Renan%22%29%3B}...

    *sigh*

    Everyone, please don't click this rubbish. You'll get (if you didn't check) an endless series of JavaScript alert boxes.

    [/quote]

    The Real WTFTM is that in Safari, the average Joe User can't get out of it without rebooting: the presence of the dialog disables Safari's menus, the dialog's event loop eats command-Q keyboard shortcuts, and since Safari still has a functioning event loop, the dock's quit menu doesn't turn into "force quit". Command-option-escape works, but it's an obscure keyboard shortcut that most people don't know.



  • @Carnildo said:

    The Real WTFTM is that in Safari, the average Joe User can't get out of it without rebooting: the presence of the dialog disables Safari's menus, the dialog's event loop eats command-Q keyboard shortcuts, and since Safari still has a functioning event loop, the dock's quit menu doesn't turn into "force quit". Command-option-escape works, but it's an obscure keyboard shortcut that most people don't know.

    I seem to recall there being a Force Quit item on the Apple menu, but the Apple menu itself was a WTF. The whole Mac menu bar is a complete WTF.

    The right hand side is split into three systems. The Spotlight menu is its own mechanism that you have no control over -- it can't be moved or taken away. The rest of it comes from SystemUIServer and is no relation to the main (Apple + application) menus. The "main" menu bar and SystemUIServer are two menu bars pretending to be one. But within the SystemUIServer menu, some items are "live" can be drag-rearranged and removed, and some are put there by a API that doesn't provide for this. So the items behave differently depending what put them there, and never in a useful way.

    The Apple menu *seems* to be part of the same menu service as the application menus -- i.e. you can run the cursor back and forth between them (which tends not to work with the separate menu bar that sits at the right). Which means, thus, that if the current app hangs, the Apple menu is taken out with it. Apple > Force Quit, Apple > Log Out etc are all gone. Some people will realise that you can click another app to restore a working menu bar, though, but it's still a big weak spot. It feels to me that Apple's beloved single menu bar is falling apart at the seams, and has become a huge, horrible hack to keep it still functioning in a modern OS. (Although it would still work if it was actually written properly, I'm sure!)

    But then, Windows has various states where a frozen or tied-up app causes the taskbar to stop responding. But alt-tab still works, since (I recently discovered) it's run by CSRSS instead of Explorer.



  • @Daniel Beardsmore said:

    But then, Windows has various states where a frozen or tied-up app causes the taskbar to stop responding. But alt-tab still works, since (I recently discovered) it's run by CSRSS instead of Explorer.
    The only time I've had the taskbar freeze was when something was tying up the Explorer process that runs it. You can pretty much eliminate this by enabling "Launch folder windows as separate processes" in Tools -> Folder options -> View, since it's usually the folders that you're browsing which cause freezes (thanks to the wonderful things such as Explorer trying to preview video and image files).

    Also, Windows 2000 and newer will detect that the application froze if you click it a few times, and replace it's window with one drawn by Explorer, on which you can click the [X] button to get the "Application is not responding" dialog. Or you could press Ctrl+Shift+Esc to bring up Task Manager (running at higher priority) and kill the application from there.



  • @ender said:

    The only time I've had the taskbar freeze was when something was tying up the Explorer process that runs it. You can pretty much eliminate this by enabling "Launch folder windows as separate processes" in Tools -> Folder options -> View, since it's usually the folders that you're browsing which cause freezes (thanks to the wonderful things such as Explorer trying to preview video and image files).

    Explorer in Windows 2000 is pretty good at only letting one window freeze at a time. Obviously, I wish that it used asynchronous calls so that it never freezes, but that would be far too much to hope for.

    The problem seems to be deeper, and there's no use you trying to rationalise Windows. After all, in Windows 2000 at least, Win-E opens a folder window using the taskbar's explorer.exe instead of the folder browsing explorer.exe, which is rather silly. Here's a good trick, in Windows 2000 anyway: suspend firefox.exe, and then launch a program from Quick Launch or Start -- the taskbar will show an hourglass and lock up. Note that it's only Firefox which, if not responding, will hang Explorer. Other processes don't do this, including Thunderbird.

    @ender said:

    Also, Windows 2000 and newer will detect that the application froze if you click it a few times, and replace it's window with one drawn by Explorer, on which you can click the [X] button to get the "Application is not responding" dialog. Or you could press Ctrl+Shift+Esc to bring up Task Manager (running at higher priority) and kill the application from there.

    Windows is really stupid about hung apps. If Pidgin freezes, and I try to close the buddy list, Windows tells me that "End Program - Buddy List: This program is not responding". Since when was "Buddy List" a program? But as for Explorer removing program windows and replacing them with Explorer-driven substitutes ... Eh what? Nothing doing in Windows 2000. Windows XP has some tremendously unintelligent window content caching that screenshots an un-drawn window of a hung app and will then redraw the window in from that. Snag is, at the point where it takes the screenshot, it will already have some other windows covering it over, or have their content not yet undrawn, so the hung window always gets redrawn plastered with bits of other apps' windows all over it.

    Explorer does not "draw windows" although the Windows GUI will typically draw in the title bar of hung apps automatically. Not always ... there are fringe cases where the window's title bar won't draw in automatically. e.g. Pidgin, if you suspend it.



  • @Daniel Beardsmore said:

    The problem seems to be deeper, and there's no use you trying to rationalise Windows. After all, in Windows 2000 at least, Win-E opens a folder window using the taskbar's explorer.exe instead of the folder browsing explorer.exe, which is rather silly.
    Interesting, I never noticed this - the few times I need to use Explorer, I do it through Win+R, path.@Daniel Beardsmore said:
    Explorer does not "draw windows" although the Windows GUI will typically draw in the title bar of hung apps automatically. Not always ... there are fringe cases where the window's title bar won't draw in automatically. e.g. Pidgin, if you suspend it.
    If the application freezes, it's window is hidden, and Explorer opens a window of the same size, with the same title, only with added (not responding) at the end. This window is owned by Explorer, not by the frozen application.



  • @ender said:

    If the application freezes, it's window is hidden, and Explorer opens a window of the same size, with the same title, only with added (not responding) at the end. This window is owned by Explorer, not by the frozen application.

    Ah, you're right, for XP. Windows 2000 does not do this -- I checked with my handy-dandy crash.exe and Process Explorer. In XP, after some trigger, Explorer does do this. It explains why XP has such retarded behaviour: this is where that lousy screenshot of the window (minus its menu bar) comes from. I always wondered what that was about: it explains why the window content caching isn't done until after the program hangs, and half the window is probably been overwritten by other windows anyway. There's something nice about the true window caching and double buffering in Mac OS X: no more redraw flicker, even on old computers, and hung apps do draw in correctly since the OS truly knows what the window looked like up to that point.

    For giggles, after terminating crash.exe on XP, I let Windows send off a crash report to Microsoft. Some poor slob in Redmond is going to be wondering what crash.exe is, and why it crashed. (Which is obvious: to crash is its life's purpose.)



  • @Daniel Beardsmore said:

    Windows XP has some tremendously unintelligent window content caching that screenshots an un-drawn window of a hung app and will then redraw the window in from that. Snag is, at the point where it takes the screenshot, it will already have some other windows covering it over, or have their content not yet undrawn, so the hung window always gets redrawn plastered with bits of other apps' windows all over it.

    This is only true because Windows XP and earlier don't keep a seperate memory surface for each window. The covered parts of a window don't exist, and have to be redrawn by the program itself when they're uncovered. If the program is hung, they don't redraw. In Vista, each window has it's own memory surface, which means that apps have to do a lot less redrawing than before, and apps never get other apps pasted in to them.

    This is of course where most of Vista's increase in memory usage is from (At least when using DWM, i.e. Aero/Standard theme). At the very least, it ends up with two full-screen surfaces (desktop and framebuffer) in memory where XP and previous only had one (just framebuffer), and if you open an application full-screen it grows to three (+app), where XP would still only have one (still just framebuffer).

    If Vista uses double-buffered display, then add another full-screen surface. A 1024x768,32-bit full-screen surface is 3MB, a 1680x1050 one is 7MB, and larger resolutions or dual displays add even more.

    I have 5 apps open across 2 displays, so for me, right now, Vista would use ~35MB of ram or more just for that.

    Also, XP's supposed 128MB Recommended ram requirement is a load of crap nowadays. It will run fine on 64MB (the minimum requirement, and I've done it), but I'd put the recommended at 512MB. 256MB or less tends to leave you with no free ram, and running any program (especially ones that are unnecessarily themed, eg AOL) will cause paging to happen. On a pre-built pc the crapware often uses more ram and cpu than Windows itself, sometimes making even 512MB inadequate.

    On the other hand Vista's 512MB Minimum and 1GB recommended are sensible (at least for now). Not because Vista itself uses that much, but because modern programs use so much more ram than those from when XP's requirements were written.



  • @Thief^ said:

    I have 5 apps open across 2 displays, so for me, right now, Vista would use ~35MB of ram or more just for that.
    Isn't this stored in the video memory of the graphic card (which is why Aero requires a card with 128MB RAM)?



  • @Thief^ said:

    In Vista, each window has it's own memory surface, which means that apps have to do a lot less redrawing than before, and apps never get other apps pasted in to them.

    Maybe I'm just stupid, but what reason did they have to do this? I mean, it's nice that I can now look at my windows uncovered after they crashed brutally, and I guess it's also nice that the approx. 1% of the window that uses the glass effect can be redrawn without calling all the windows beneath, but all of those seem far from being urgent, let alone enough to justice a 30MB increase in memory.

    Where is the big advantage?

    @Daniel Beardsmore said:

    But then, Windows has various states where a frozen or tied-up app
    causes the taskbar to stop responding. But alt-tab still works, since
    (I recently discovered) it's run by CSRSS instead of Explorer.

    Explorer is of course especially vulnerable, because dozens of possibly really crappy written shell extension plugins run in its context. And if one of those happens to lock up at the wrong time...
     



  • @ender said:

    @Thief^ said:
    I have 5 apps open across 2 displays, so for me, right now, Vista would use ~35MB of ram or more just for that.
    Isn't this stored in the video memory of the graphic card (which is why Aero requires a card with 128MB RAM)?

    In a word, no.

    It would be nice if we had video cards and software that worked this way. But we don't. It's not what FPSes want. 



  • @PSWorx said:

    @Thief^ said:
    In Vista, each window has it's own memory surface, which means that apps have to do a lot less redrawing than before, and apps never get other apps pasted in to them.

    Maybe I'm just stupid, but what reason did they have to do this? I mean, it's nice that I can now look at my windows uncovered after they crashed brutally, and I guess it's also nice that the approx. 1% of the window that uses the glass effect can be redrawn without calling all the windows beneath, but all of those seem far from being urgent, let alone enough to justice a 30MB increase in memory.

    Where is the big advantage?

     

    Ironically enough, X had this feature decades ago, and stopped using it because it's bad for performance. It seems like a good idea until you actually build it and examine how things work out, and then you realise that under typical loads the cost of housekeeping all the extra data outweighs the cost of just redrawing it on demand.



  • @PSWorx said:

    @Thief^ said:
    In Vista, each window has it's own memory surface, which means that apps have to do a lot less redrawing than before, and apps never get other apps pasted in to them.

    Maybe I'm just stupid, but what reason did they have to do this?

    Windows has always been horribly prone to flicker: updating any part of any window tends to cause flicker during the "undraw" stage where the window or control background is painted first. In Windows 2000, one of the most annoying cases is where a tray icon is deleted prior to being repainted.

    Having every single window buffered means that flicker goes away: the window updates are only drawn once they're completed, so you never see the window flash white or grey as it's being cleared ready for repainting. You do get used to all the flicker in Windows, but it never stops being really horrid. Mac OS 9 had the same flaw, but I think more Mac developers were prepared to perform the off-screen buffering themselves. One case where this is not done is when a notification icon is flashing in the application menu title: you often see this get visibly cleared before being redrawn with each frame. Carbon apps tend to flicker a lot more under OS 9, because the developers now rely on OS X's buffering.

    Note that each off-screen buffer should only be the size of the window, not the size of the whole desktop! If Microsoft use a whole 4 MB plus for each piddly window, then that is really bad.



  • @Daniel Beardsmore said:

    @PSWorx said:
    @Thief^ said:
    In Vista, each window has it's own memory surface, which means that apps have to do a lot less redrawing than before, and apps never get other apps pasted in to them.

    Maybe I'm just stupid, but what reason did they have to do this?

    Windows has always been horribly prone to flicker: updating any part of any window tends to cause flicker during the "undraw" stage where the window or control background is painted first. In Windows 2000, one of the most annoying cases is where a tray icon is deleted prior to being repainted.

    Having every single window buffered means that flicker goes away: the window updates are only drawn once they're completed, so you never see the window flash white or grey as it's being cleared ready for repainting. You do get used to all the flicker in Windows, but it never stops being really horrid. Mac OS 9 had the same flaw, but I think more Mac developers were prepared to perform the off-screen buffering themselves. One case where this is not done is when a notification icon is flashing in the application menu title: you often see this get visibly cleared before being redrawn with each frame. Carbon apps tend to flicker a lot more under OS 9, because the developers now rely on OS X's buffering.

    Note that each off-screen buffer should only be the size of the window, not the size of the whole desktop! If Microsoft use a whole 4 MB plus for each piddly window, then that is really bad.

    I know that redrawing can cause flicker. But I always thought that would be kind of a "beginner's mistake" showing you that your redraw routine is rubbish. If your redrawing costs so much time that it becomes visible, you use a screen buffer, of course. But I don't see the reason why you should make them mandatory for ALL windows now.

    I had the impression that most programs that could have problems with flickering already manage their own buffers. The only windows program I can remember that ever flickered enough to irritate was a freeware game written by a bunch of 15 year olds. And that it did only because they decided to re-render a complete 3D scene with their own, application level rendering engine on each redraw message.



  • @PSWorx said:

    I know that redrawing can cause flicker. But I always thought that would be kind of a "beginner's mistake" showing you that your redraw routine is rubbish. If your redrawing costs so much time that it becomes visible, you use a screen buffer, of course ... I had the impression that most programs that could have problems with flickering already manage their own buffers.

    Well, evidently not. Installers, for example, have a field that says "Copying file: foo" or "Updating Registry: {ABC-123-DEF...}" and no-one buffers these, so they flicker. Resizing a window tends to flicker horribly as controls are resized one by one and scroll bars and panes and other gubbins all lag behind. It's relative to CPU speed, though, and the effect may be pretty small on the latest computers.

    My OS X computer, an old 500 MHz iMac, does reap the benefit of system-wide buffering: screen redraw is wonderfully smooth with none of the nasty flicker of a Windows PC. Since all developers are expected to buffer their graphics anyway, it's easier for the OS or common frameworks to provide it than have to do it yourself. Even on my 1997 palmtop (36 MHz, 16 MB), the standard framework and managed runtime (OPL32) buffers and caches your windows for you unless you specifically turn that feature off. It's useful, as C apps redraw from scratch and it is slow on that system!

    But yes, my jury is still out on the validity of system-wide buffering. For older computers, though, it's a blessing and saves application developers a lot of trouble. I guess it's not too hard to make it an optional service, especially if you can choose your window manager (not applicable to Windows or OS X ;)



  • @Thief^ said:

    This is of course where most of Vista's increase in memory usage is from (At least when using DWM, i.e. Aero/Standard theme). At the very least, it ends up with two full-screen surfaces (desktop and framebuffer) in memory where XP and previous only had one (just framebuffer), and if you open an application full-screen it grows to three (+app), where XP would still only have one (still just framebuffer).

    If Vista uses double-buffered display, then add another full-screen surface. A 1024x768,32-bit full-screen surface is 3MB, a 1680x1050 one is 7MB, and larger resolutions or dual displays add even more.

    I have 5 apps open across 2 displays, so for me, right now, Vista would use ~35MB of ram or more just for that.

    Is the Vista implementation of window buffering really that simplistic? On MacOSX, each window's back buffer depends on the on-screen size of the window, and I'm fairly sure that the X windows implementation is similar.



  • @Carnildo said:

    Is the Vista implementation of window buffering really that simplistic? On MacOSX, each window's back buffer depends on the on-screen size of the window, and I'm fairly sure that the X windows implementation is similar.

    As it is in Windows, how Daniel Beardsmore explained. But the Desktop is a window as well and as such needs a window buffer. And since it spans the whole screen, you need at least one buffer the size of the whole screen in addition to the buffers of the other windows.



  • @Carnildo said:

    I'm fairly sure that the X windows implementation is similar.

    The X11 protocol doesn't specify what the server has to do, and modern servers don't usually bother implementing it because it's just a bad idea. The X11 client interface is sufficiently flexible that the server can provide backing store for as much or as little of each window as it desires.



  • @Daniel Beardsmore said:

    [quote user="Renan "C#" Sousa"]

    Fun!

    http://www.helprick.com/ ... while(true){alert%28%22Owned+by+Renan%22%29%3B}...

    *sigh*

    Everyone, please don't click this rubbish. You'll get (if you didn't check) an endless series of JavaScript alert boxes.

    If you're wondering how to get out of them, and you use Firefox, press ctrl-W (close tab) immediately after clicking OK. You'll get one more alert after the tab closes and that's that. I am fortunate that I already had to figure this out before when some other retard sent me to a page that did this -- I spent far too long solving that one in order to avoid having to terminate Firefox. (In iCab, I think you press cmd-shift-J with a JavaScript alert dialog open, and the script will terminate when the dialog closes.)

    [/quote]

    The Real WTF™ is that the alert box is a modal dialog. I mean, I know the function is called alert(), but hey, come on... If it's "the page at http://..." that's saying something, why are all my other tabs disabled?



  • @aib said:

    The Real WTF™ is that the alert box is a modal dialog. I mean, I know the function is called alert(), but hey, come on... If it's "the page at http://..." that's saying something, why are all my other tabs disabled?



    I agree.  HTTP login boxes are the same way (no copying your password from an email and then entering it in another tab).  There is one feature of Opera that I'm surprised no one has copied yet.  Every Javascript popup has a checkbox that says "stop executing scripts on this page".


Log in to reply