Explore beyond Internet Explorer using Internet Explorer



  •  Posting this one for two reasons. One, for a mature web-based product released in 2012 by a major corporation (let's call them Microsoft for anonymity), this is pretty egregious. And two, because it'll be fun watching certain people yell about how it isn't egregious (let's call them Buttermuffin Snakepit for anonymity).

    This is Javascript -> .

    Javascript lives inside a browser -> [.]

    The browser lives inside an OS -> {[.]}

    But Javascript doesn't know that, because it should be blind to anything outside the browser ->  {[.]} "I can't see shit!"

    Unless you're Internet Explorer, up to and including 10:  -> {[.]}  >  "hahahaha, I can see your cursor!"

    Because Internet Explorer exposes information about your mouse cursor's position and clicks via Javascript:

    [url="http://seclists.org/bugtraq/2012/Dec/81"]SecLists[/url]

    [url="http://iedataleak.spider.io/demo"]Demo[/url]

    Web security in 2012, folks!



  • Now I'm confused (emphasis added):
    @SecLists said:

    As a user of Internet Explorer, your mouse movements can be recorded
    by an attacker even if you are security conscious and you never
    install any untoward software.

    But...but..but..you've already installed Internet Explorer!


  • Winner of the 2016 Presidential Election

    No, OEMs are always bundling crapware with their stock distributions nowadays.



  • @Lorne Kates said:

    Because Internet Explorer exposes information about your mouse cursor's position and clicks via Javascript:

    ... and then what happens?

    I mean by all means I agree JS shouldn't have access to that data, but... uh... it strikes me as kind of a "but so what?" situation. So what?


  • Winner of the 2016 Presidential Election

    @blakeyrat said:

    @Lorne Kates said:
    Because Internet Explorer exposes information about your mouse cursor's position and clicks via Javascript:

    ... and then what happens?

    I mean by all means I agree JS shouldn't have access to that data, but... uh... it strikes me as kind of a "but so what?" situation. So what?

    It does seem a bit contrived, but the example shown is grabbing a phone number clicked into eg Skype. Some security software offers on-screen keyboards as a guard against keyloggers, it could potentially grab passwords / PINs from those.



  • @joe.edwards said:

    @blakeyrat said:
    @Lorne Kates said:
    Because Internet Explorer exposes information about your mouse cursor's position and clicks via Javascript:

    ... and then what happens?

    I mean by all means I agree JS shouldn't have access to that data, but... uh... it strikes me as kind of a "but so what?" situation. So what?

    It does seem a bit contrived, but the example shown is grabbing a phone number clicked into eg Skype. Some security software offers on-screen keyboards as a guard against keyloggers, it could potentially grab passwords / PINs from those.

     

    Or any other virtual keyboard.  Windows 8 is supposed to run on a tablet, right? And tablets have virtual keyboards in pretty much fixed position + dimensions?

     



  • @Lorne Kates said:

    Or any other virtual keyboard. Windows 8 is supposed to run on a tablet, right? And tablets have virtual keyboards in pretty much fixed position + dimensions?

    Tablets don't have a cursor position, except in the millisecond in which there is an actual touch. Unless there's more to this than what's in the bug description, it's useless for on-screen keyboards on touchscreens.



  • @Lorne Kates said:

    Or any other virtual keyboard.  Windows 8 is supposed to run on a tablet, right? And tablets have virtual keyboards in pretty much fixed position + dimensions?
     

    Note: actual question, not sarcasm. I know, it's a first for me, too.



  • @blakeyrat said:

    @Lorne Kates said:
    Or any other virtual keyboard. Windows 8 is supposed to run on a tablet, right? And tablets have virtual keyboards in pretty much fixed position + dimensions?

    Tablets don't have a cursor position, except in the millisecond in which there is an actual touch. Unless there's more to this than what's in the bug description, it's useless for on-screen keyboards on touchscreens.

    That makes it easier to harvest password. "Oh, person pressed Shift+F, then a-s-t-e-r-t-h-a-n-a-b-u-l-l-e-t", in rapid succession.


    Boom, just harvested password.


  • @blakeyrat said:

    I mean by all means I agree JS shouldn't have access to that data, but... uh... it strikes me as kind of a "but so what?" situation. So what?
     

    Oh, man. I was just hoping that either the sheer stupidity if IE or  the joke at the submission would lead you to not make this comment. You seem to be immune to such kind of conclusions.



  • @Lorne Kates said:

    Because Internet Explorer exposes information about your mouse cursor's position and clicks via Javascript:

    And then all we need to do is raise the building one foot using the Max Schumann maneuver, and get Matt Damons mom to bust us of of jail, and we'll have the mouse click positions where a virtual keyboard for an unknown application was possibly used to tap out the combination to the vault at the Bellagio, the Mirage and the MGM Grand.

    These "security researchers" are really having to try hard these days to justify their own existence.



  • @daveime said:

    These "security researchers" are really having to try hard these days to justify their own existence.

    They have to try at least as hard as the guys who make the malware.



  • @gu3st said:

    That makes it easier to harvest password. "Oh, person pressed Shift+F, then a-s-t-e-r-t-h-a-n-a-b-u-l-l-e-t", in rapid succession.


    Boom, just harvested password.
    Pretty sure that on my virtual keyboard that would be:

    F-q-s-t-e-r-t-h-q-n-q-b-u-l-l-e-t

    Boom.... nothing happens



  • @bjolling said:

    @gu3st said:

    That makes it easier to harvest password. "Oh, person pressed Shift+F, then a-s-t-e-r-t-h-a-n-a-b-u-l-l-e-t", in rapid succession.


    Boom, just harvested password.
    Pretty sure that on my virtual keyboard that would be:

    F-q-s-t-e-r-t-h-q-n-q-b-u-l-l-e-t

    Boom.... nothing happens

     

    What? Did someone switch the "a" and "q" keys on your virtual keyboard as a practical joke? You know, you can just pry them off and put them back into place. Be sure to use a sharp-edged screwdriver.

     



  • @Lorne Kates said:

    @bjolling said:
    @gu3st said:
    That makes it easier to harvest password. "Oh, person pressed Shift+F, then a-s-t-e-r-t-h-a-n-a-b-u-l-l-e-t", in rapid succession.

    Boom, just harvested password.

    Pretty sure that on my virtual keyboard that would be:

    F-q-s-t-e-r-t-h-q-n-q-b-u-l-l-e-t

    Boom.... nothing happens

    What? Did someone switch the "a" and "q" keys on your virtual keyboard as a practical joke? You know, you can just pry them off and put them back into place. Be sure to use a sharp-edged screwdriver.
    Who'd have thought thirty year ago we'd all be postin' here discussing differences in keyboard layouts

     



  • @bjolling said:

    Who'd have thought thirty year ago we'd all be postin' here discussing differences in keyboard layouts
     

    I did. That was the topic of my essay in pre-school. I only got a "B" on the paper. The teacher thought "Worse Than Fail" was a cop-out acronym, and that I wasn't fully commiting myself to the spirit of the subject.



  • Oh, please spare me. In a decade or so, we've gone from "hey, this API lets me get the cursor position... how useful" to playing Barney Fife with every single damned thing that anyone tries to do. Anything resembling a useful app development platform is mocked for its very utility. Do the regulars here just deploy lists of "vulnerabilities" now, instead of actual software? That's the impression I get. Oh, but let me guess: you're working on a "library" that will keep your colleagues from ever having to worry about anything... so long as they genuflect at your (object-oriented) altar.

    What a bunch of snake oil salesmen we have become.



  • @bridget99 said:

    Oh, please spare me. In a decade or so, we've gone from "hey, this API lets me get the cursor position... how useful" to playing Barney Fife with every single damned thing that anyone tries to do. Anything resembling a useful app development platform is mocked for its very utility. Do the regulars here just deploy lists of "vulnerabilities" now, instead of actual software? That's the impression I get. Oh, but let me guess: you're working on a "library" that will keep your colleagues from ever having to worry about anything... so long as they genuflect at your (object-oriented) altar.

    What a bunch of snake oil salesmen we have become.

     

    And that's why the [url="http://www.tannr.com/herp-derp-youtube-comments/"]Herp Derp Youtube Comment[/url] extension needs to be forked to work with Community Server.



  • @blakeyrat said:

    @Lorne Kates said:
    Or any other virtual keyboard. Windows 8 is supposed to run on a tablet, right? And tablets have virtual keyboards in pretty much fixed position + dimensions?

    Tablets don't have a cursor position, except in the millisecond in which there is an actual touch. Unless there's more to this than what's in the bug description, it's useless for on-screen keyboards on touchscreens.

    Just out of curiosity how does that work with, for example, [url=http://www.swype.com/]Swype[/url] or [url=https://play.google.com/store/apps/details?id=com.keymonk.latin&feature=nav_result#?t=W251bGwsMSwyLDNd]Keymonk[/url]?



  • You know this all goes back to the brilliant idea to let JavaScript access actual screen coordinates right? (Not sure who wanted that... analytics people?)


  • Winner of the 2016 Presidential Election

    @Delve said:

    @blakeyrat said:
    @Lorne Kates said:
    Or any other virtual keyboard. Windows 8 is supposed to run on a tablet, right? And tablets have virtual keyboards in pretty much fixed position + dimensions?

    Tablets don't have a cursor position, except in the millisecond in which there is an actual touch. Unless there's more to this than what's in the bug description, it's useless for on-screen keyboards on touchscreens.

    Just out of curiosity how does that work with, for example, Swype or Keymonk?

    As far as Keymonk is concerned, I don't know that Javascript actually supports reading multiple XY positions (multitouch) simultaneously. I don't mean gestures, but actual XY tracking. @Delve said:

    Filed under: unintended interactions, what we didn't think ofwe've never heard of will kill us


  • @MiffTheFox said:

    You know this all goes back to the brilliant idea to let JavaScript access actual screen coordinates right? (Not sure who wanted that... analytics people?)

    First of all, it's not JavaScript, it's DOM. Anything that uses DOM has access to the Event object.

    Secondly, screen coords are useless for analytics purposes. The real problem is the people who defined DOM were fucking idiots, and the way they defined the window coordinates was fucking idiotic, and now we're stuck with it forever.



  • @blakeyrat said:

    @Lorne Kates said:
    Or any other virtual keyboard. Windows 8 is supposed to run on a tablet, right? And tablets have virtual keyboards in pretty much fixed position + dimensions?

    Tablets don't have a cursor position, except in the millisecond in which there is an actual touch. Unless there's more to this than what's in the bug description, it's useless for on-screen keyboards on touchscreens.

     

    Wrong. If you ever used a windows device with both a touch-screen and a touchpad/mouse, like any tablet convertible in the last two decades, you'd know that.

    The cursor is hidden after touch in windows 7 and 8, but it still has a position at the last place you touched. It becomes visible again if you move the mouse. It is not even hidden in Windows XP. Not sure about Vista, not used that yet with a touchscreen.



  • @georgir said:

    Wrong.

    No my statement is correct, Microsoft's implementation is wrong. But they probably implemented that way because the DOM spec requires it. Because God forbid the W3C be exposed to things like gasp touchscreens, pen tablets, or computers with more than one monitor-- those are UNTHINKABLE to the W3C!

    It's good to know that this "exploit" is (in theory, perhaps, possibly, maybe, kinda) actually an exploit, but:

    1) Nobody talking about it has explained the mouse cursor position issue you just explained, so I don't know how we were expected to know it's an exploit (perhaps, maybe) since we're not telepathic

    2) You'll have to forgive me if I'm not exactly shaking in my boots until this gets fixed



  • @blakeyrat said:

    1) Nobody talking about it has explained the mouse cursor position issue you just explained, so I don't know how we were expected to know it's an exploit (perhaps, maybe) since we're not telepathic
     

    Several banks required PIN input via mouse-only, on-screen keyboards to prevent keyloggers. This exploit is a vector to log those entries.

    And just the fact that it exposes information external to the browser is enough to worry, patch and review. At the very least, the IE team should ask the question "Are we accidentally exposing OTHER privileged information via the same mechanism?"



  • @georgir said:

    Wrong. If you ever used a windows device with both a touch-screen and a touchpad/mouse, like any tablet convertible in the last two decades, you'd know that.

    The cursor is hidden after touch in windows 7 and 8, but it still has a position at the last place you touched. It becomes visible again if you move the mouse. It is not even hidden in Windows XP. Not sure about Vista, not used that yet with a touchscreen.

    Windows 7 with a touchscreen just moves the mouse and clicks like XP, and I've used it with both a digitizer and an actual touchscreen. Haven't used Win8 though.

    And also Javascript DOM HTML5 has has touch sensing, at least implemented in Mobile Safari and IE10, which are practically the only browsers you'd be using with a touchscreen anyways*. Javascript DOM HTML5 has accelerometer support too, should you want to write your next iWantToBurnTheRope in a web browser or whatever.

    * Pre-emptive strike: The Android browser is Mobile Safari.



  • @MiffTheFox said:

    And also Javascript DOM HTML5 has has touch sensing, at least implemented in Mobile Safari and IE10, which are practically the only browsers you'd be using with a touchscreen anyways*. Javascript DOM HTML5 has accelerometer support too, should you want to write your next iWantToBurnTheRope in a web browser or whatever.

    * Pre-emptive strike: The Android browser is Mobile Safari.

    I don't follow your conclusion that Mobile Safari and IE10 are "practically the only browsers you'd be using with a touchscreen anyways." There are lots of other browsers available, of course. Also, I thought the android browser was related (i.g., WebKit) but distinct from Safari.



  • @boomzilla said:

    I don't follow your conclusion that Mobile Safari and IE10 are "practically the only browsers you'd be using with a touchscreen anyways." There are lots of other browsers available, of course. Also, I thought the android browser was related (i.g., WebKit) but distinct from Safari.

    Eh, maybe Chrome and Firefox on Android. It is webkit, yes, but the user agent specifically identifies itself as Safari. Don't know what lots is. Opera? Does that even support Javascript? Dolphin's what I use, but that doesn't really count since it's a fork of Webkit anyways.



  • @MiffTheFox said:

    Eh, maybe Chrome and Firefox on Android. It is webkit, yes, but the user agent specifically identifies itself as Safari. Don't know what lots is. Opera? Does that even support Javascript? Dolphin's what I use, but that doesn't really count since it's a fork of Webkit anyways.

    Yeah, and IE says Mozilla in its user agent. At least Dolphin and Chrome seem to be relatively popular alternatives to the defaults, and I'm not sure why they wouldn't count just because they both use WebKit.



  • Opera supports Javascript, AFAIK. I stopped using it a couple years ago though.

    Edit: Browsers self-report their user agent. It is, as any self-reporting regime, not entirely reliable. You used to be able to tell Opera to call itself whatever you wanted it to, though I don't know if that feature is still available.



  • @MiffTheFox said:

    And also Javascript DOM HTML5 has has touch sensing, at least implemented in Mobile Safari and IE10, which are practically the only browsers you'd be using with a touchscreen anyways*.

    Uh, what? I don't know what "practically" means in your little world, but every Windows or OS X computer can potentially have users with only a touchscreen (or pen-based) input device. For example, almost every POS system ever. Or for Mac designer types, Wacom makes a combination pen-tablet/monitor expressly for this purpose.



  • @blakeyrat said:

    @MiffTheFox said:
    And also Javascript DOM HTML5 has has touch sensing, at least implemented in Mobile Safari and IE10, which are practically the only browsers you'd be using with a touchscreen anyways*.

    Uh, what? I don't know what "practically" means in your little world, but every Windows or OS X computer can potentially have users with only a touchscreen (or pen-based) input device. For example, almost every POS system ever. Or for Mac designer types, Wacom makes a combination pen-tablet/monitor expressly for this purpose.

    In fact the developer behind me has a pen-based input device instead of a mouse.  It made it very easy for him to complete this maze: http://www.cssplay.co.uk/menu/amazing.html



  • @blakeyrat said:

    @MiffTheFox said:
    And also Javascript DOM HTML5 has has touch sensing, at least implemented in Mobile Safari and IE10, which are practically the only browsers you'd be using with a touchscreen anyways*.

    Uh, what? I don't know what "practically" means in your little world, but every Windows or OS X computer can potentially have users with only a touchscreen (or pen-based) input device. For example, almost every POS system ever. Or for Mac designer types, Wacom makes a combination pen-tablet/monitor expressly for this purpose.

    Fine, if you want to talk about pen input and not touchscreens Wacom's drivers contain a NPAPI plugin. I don't know of any non-wacom touchscreens that aren't fancier then "move the mouse to X, Y and click" in terms of what the controller sends to the device. I've worked with POS touchscreens before and they are not those fancy-ass capactive touchscreens Apple designed in California.



  • @MiffTheFox said:

    Fine, if you want to talk about pen input and not touchscreens Wacom's drivers contain a NPAPI plugin. I don't know of any non-wacom touchscreens that aren't fancier then "move the mouse to X, Y and click" in terms of what the controller sends to the device. I've worked with POS touchscreens before and they are not those fancy-ass capactive touchscreens Apple designed in California.

    I can't speak for OS X, but Windows has native support for pen and touch-screen input devices and has since at least Windows 2000.

    Any click emulation you're seeing is done by the OS for compatibility.



  • @blakeyrat said:

    @MiffTheFox said:
    Fine, if you want to talk about pen input and not touchscreens Wacom's drivers contain a NPAPI plugin. I don't know of any non-wacom touchscreens that aren't fancier then "move the mouse to X, Y and click" in terms of what the controller sends to the device. I've worked with POS touchscreens before and they are not those fancy-ass capactive touchscreens Apple designed in California.

    I can't speak for OS X, but Windows has native support for pen and touch-screen input devices and has since at least Windows 2000.

    Any click emulation you're seeing is done by the OS for compatibility.

    But that doesn't change the fact that the hardware is just giving the OS co-ordinates of when a touch event occurs.



  • Nope. In Windows that SOP for touchscreens is to leave the cursor wherever it last was touched. This is still viable



  • @Sutherlands said:

    It made it very easy for him to complete this maze: http://www.cssplay.co.uk/menu/amazing.html
    I just scrolled the page so I could enter the section with the exit coming from outside the browser window. Still not as simple as simply clicking on the exit, though.



  • @blakeyrat said:

    @georgir said:
    Wrong.

    No my statement is correct, Microsoft's implementation is wrong. But
    they probably implemented that way because the DOM spec requires it.
    Because God forbid the W3C be exposed to things like gasp
    touchscreens, pen tablets, or computers with more than one monitor--
    those are UNTHINKABLE to the W3C!

    It's good to know that this "exploit" is (in theory, perhaps, possibly, maybe, kinda) actually an exploit, but:

    1) Nobody talking about it has explained the mouse cursor position issue you just explained, so I don't know how we were expected to know it's an exploit (perhaps, maybe) since we're not telepathic

    2) You'll have to forgive me if I'm not exactly shaking in my boots until this gets fixed

    Wrong, again. Or, to be more precise, WTF are you even talking about?

    I was talking about your claim that "Tablets don't have a cursor position, except in the millisecond in which there is an actual touch". Once again, that is wrong. Windows tablets always have a mouse cursor position, even if it is not displayed. The cursor might not be visible but it is still there, on the last coordinates that you touched. And that has nothing at all to do with the DOM spec or the browser, it is this way on the OS level.

    I'm amazed how you manage to both acknowledge that you didn't know the above (and were therefore wrong in stating the opposite) and also still claim "No my statement is correct" in the same post. Are you trying to melt my logic circuits or something?

    P.S. About your new rant...

    The DOM spec most certainly does not require the browser to report cursor coordinates when they are outside the browser window (maybe unless the last mousedown was inside and there still has not been a mouseup).

    Also, touch APIs or other things "UNTHINKABLE to the W3C" are already making their way in browsers, both in the form of vendor-specific APIs as well as W3C proposals. They only complement the mouse cursor, do not replace or disable it, so have no relation to the vulnerability being discussed. So WTF are you on about again?

     



  • @georgir said:

    @blakeyrat said:
    ...

    I'm amazed how you manage to both acknowledge that you didn't know the above (and were therefore wrong in stating the opposite) and also still claim "No my statement is correct" in the same post. Are you trying to melt my logic circuits or something?

    You must be new here.



  • @georgir said:

    I was talking about your claim that "Tablets don't have a cursor position, except in the millisecond in which there is an actual touch". Once again, that is wrong. Windows tablets always have a mouse cursor position, even if it is not displayed. The cursor might not be visible but it is still there, on the last coordinates that you touched. And that has nothing at all to do with the DOM spec or the browser, it is this way on the OS level.

    I'm amazed how you manage to both acknowledge that you didn't know the above (and were therefore wrong in stating the opposite) and also still claim "No my statement is correct" in the same post. Are you trying to melt my logic circuits or something?

    My statement didn't mention Windows, you might notice. You assumed or deluded (probably space aliens on your shoulder whispering into your brain) that when I said "tablets" what I meant to say was, "tablets running Microsoft(tm) Windows(tm) OS(tm) for Tablets(tm)(c)(r)".

    I think that answers your confusion. Tablets do not have a cursor position, except during the millisecond the screen is actually touched.

    @georgir said:

    Also, touch APIs or other things "UNTHINKABLE to the W3C" are already making their way in browsers, both in the form of vendor-specific APIs as well as W3C proposals. They only complement the mouse cursor, do not replace or disable it, so have no relation to the vulnerability being discussed. So WTF are you on about again?

    ONLY A DECADE LATE! Such fast action! TURBO SPEED W3C!

    Or did you swallow the kool-aid and think Apple invented the tablet computer?



  • @blakeyrat said:

    @georgir said:
    I was talking about your claim that "Tablets don't have a cursor position, except in the millisecond in which there is an actual touch". Once again, that is wrong. Windows tablets always have a mouse cursor position, even if it is not displayed. The cursor might not be visible but it is still there, on the last coordinates that you touched. And that has nothing at all to do with the DOM spec or the browser, it is this way on the OS level.

    I'm amazed how you manage to both acknowledge that you didn't know the above (and were therefore wrong in stating the opposite) and also still claim "No my statement is correct" in the same post. Are you trying to melt my logic circuits or something?

    My statement didn't mention Windows, you might notice. You assumed or deluded (probably space aliens on your shoulder whispering into your brain) that when I said "tablets" what I meant to say was, "tablets running Microsoft(tm) Windows(tm) OS(tm) for Tablets(tm)(c)(r)".

    I think that answers your confusion. Tablets do not have a cursor position, except during the millisecond the screen is actually touched. @georgir said:

    Also, touch APIs or other things "UNTHINKABLE to the W3C" are already making their way in browsers, both in the form of vendor-specific APIs as well as W3C proposals. They only complement the mouse cursor, do not replace or disable it, so have no relation to the vulnerability being discussed. So WTF are you on about again?
    ONLY A DECADE LATE! Such fast action! TURBO SPEED W3C!

    Or did you swallow the kool-aid and think Apple invented the tablet computer?

    Maybe not the table computer, but the leaf for sure, donchaknow!



  • @daveime said:

    @Lorne Kates said:
    Because Internet Explorer exposes information about your mouse cursor's position and clicks via Javascript:

    And then all we need to do is raise the building one foot using the Max Schumann maneuver, and get Matt Damons mom to bust us of of jail, and we'll have the mouse click positions where a virtual keyboard for an unknown application was possibly used to tap out the combination to the vault at the Bellagio, the Mirage and the MGM Grand.

    These "security researchers" are really having to try hard these days to justify their own existence.

     

    Yeah, except that the guys reporting the issue aren't security researchers - they're an ad analytics company, sniping at other ad analytics companies.



  • @blakeyrat said:

    My statement didn't mention Windows, you might notice. You assumed or deluded (probably space aliens on your shoulder whispering into your brain) that when I said "tablets" what I meant to say was, "tablets running Microsoft(tm) Windows(tm) OS(tm) for Tablets(tm)(c)(r)".
    OK.  Fair enough.  So please explain.  Exactly what tablets are you talking about that do not behave as described by georgir



  • @El_Heffe said:

    Exactly what tablets are you talking about that do not behave as described by georgir?

    And for which of those is IE available, thus making them even slightly relevant in the context of this discussion?



  • @bridget99 said:

    Oh, please spare me. In a decade or so, we've gone from "hey, this API lets me get the cursor position... how useful" to playing Barney Fife with every single damned thing that anyone tries to do. Anything resembling a useful app development platform is mocked for its very utility. Do the regulars here just deploy lists of "vulnerabilities" now, instead of actual software?

    Sorry, did you just say that ActiveX was O.K?



  • @El_Heffe said:

    OK. Fair enough. So please explain. Exactly what tablets are you talking about that do not behave as described by georgir

    I said tablets don't have a "MouseX" because they don't have a mouse. That is true for all tablets. I don't feel I need to explain it further because it's SO GODDAMNED FUCKING OBVIOUS YOU IDIOTS.



  • @blakeyrat said:

    @El_Heffe said:
    OK. Fair enough. So please explain. Exactly what tablets are you talking about that do not behave as described by georgir

    I said tablets don't have a "MouseX" because they don't have a mouse. That is true for all tablets. I don't feel I need to explain it further because it's SO GODDAMNED FUCKING OBVIOUS YOU IDIOTS.

    Wow, I guess Android tablets aren't tablets then, becuase Android's browser has a screenX and a screenY for mousemove events.

    [Android does have a mouse position]

    Open this page up under Android to test for yourself.


  • Winner of the 2016 Presidential Election

    @MiffTheFox said:

    @blakeyrat said:
    @El_Heffe said:
    OK. Fair enough. So please explain. Exactly what tablets are you talking about that do not behave as described by georgir

    I said tablets don't have a "MouseX" because they don't have a mouse. That is true for all tablets. I don't feel I need to explain it further because it's SO GODDAMNED FUCKING OBVIOUS YOU IDIOTS.

    Wow, I guess Android tablets aren't tablets then, becuase Android's browser has a screenX and a screenY for mousemove events.

    Open this page up under Android to test for yourself.

    Guys, blakeyrat's argument is perfectly valid, except for any tablet that actually exists.



  • @MiffTheFox said:


    [Android does have a mouse position]

    Open this page up under Android to test for yourself.

     

     B-b-b-BLAKEYRANT BREAKER! 

    WOODEN TABLE BONUS x2!

    You can't give up! GO FOR BROKE!

     



  •  Nice boobie, Javascript.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.