1. Home
  2. Categories
  3. Coding Help
  4. I tracked down that iPad problem

I tracked down that iPad problem

  • blakeyrat

    Or at least I think I have, and since the other thread is a complete intellectual vacuum, I thought I'd post here and see if anybody has any ideas to fix it...

    Here's the problematic function:

    @The Original Function said:

    this.createImg = function(path)

    {

    var i = document.createElement('img');

    i.setAttribute('src', path);

    anImageArray.push(i);

    }

    20% of iPads run that function correctly no matter how many times it's called. (By "run that function" I mean they successfully make a HTTP request to the server to fetch the image.)

    80% of iPads run that function correctly the first time it's called, but not on any subsequent calls.

    I figured this might be an "optimization" from Apple; the browser might delay loading an image until the image becomes visible on the page, so I wrote a version of the function that creates the IMG tag in the same way, then attaches it to the bottom of the document.body... no luck there.

    A buddy suggested this variant:

    @Suggested Solution said:

    var i = new Image();

    i.onload = function()

    {

    anImageArray.push(this);

    };

    i.src = path;

    Unfortunately, that version shows the same problem.

    I'm stumped for the moment. Any suggestions?

    0
  • dhromed

    Do your 100 iPads connect to the interwebs in different ways?

    I hypothecate a briar patch of caching on some ipads and the race conditions that may result.

     

    0
  • blakeyrat

    I should have mentioned: path is unique for each call, so caching should be a non-issue.

    Unless the iPad is really in violation of the specs...

    0
  • blakeyrat

    GRAH ok I think the wrong bug is being barked-up. Now I think it might be a cookie issue...

    The iPad's default cookie setting is "from visited" and (natch) there's absolutely zero documentation on what this actually means. However, if I set the cookie setting to "always" then suddenly the JS works fine. So all this time I've been dinking around in the JS when it looks like the problem might be the cookie handling on our back-end... sigh.

    0
  • boomzilla
    ♿ (Parody)

    @blakeyrat said:

    So all this time I've been dinking around in the JS when it looks like the problem might be the cookie handling on our back-end... sigh.

    These are the best / worst bugs. At least it looks like something that can be fixed, and probably pretty easily, now that you know what the actual issue is. But you end up spending so many damn hours chasing red herrings. What might be interesting is if this sort of thing is biting you elsewhere, and if you've just made a giant leap in your software's effectiveness or just worked around an oddity of a particular platform.

    0
  • morbiuswilters

    @blakeyrat said:

    So all this time I've been dinking around in the JS when it looks like the problem might be the cookie handling on our back-end... sigh.

    I'm not sure how it's specific to your back-end. If Safari is set to "from visited" then it won't accept third-party cookies (which I imagine you are necessary for your software to work?)

    0
  • blakeyrat

    @morbiuswilters said:

    @blakeyrat said:
    So all this time I've been dinking around in the JS when it looks like the problem might be the cookie handling on our back-end... sigh.

    I'm not sure how it's specific to your back-end. If Safari is set to "from visited" then it won't accept third-party cookies (which I imagine you are necessary for your software to work?)

    There's no documentation anywhere (from what I can find) on what exactly "from visited" means. So, what I'm assuming is that "from visited" on Mobile Safari is the same setting as "disallow 3rd party cookies" in desktop Safari, and working forward from there.

    Being Apple, naturally there's no documentation on what the hell it means in desktop Safari either, but at least desktop Safari can get on our QA network easily and I can figure it out pretty quickly through testing.

    Anyway, it's not a tough fix, I've already done the JS part of it. It just bugs me, because it makes the back-end "wrong"... it just has to "trust" that Safari's sending the right shit, and that what he JS thinks is a "permanent" cookie is actually permanent. And since there's no way for JavaScript to determine what the cookie handling situation is, it means I have to do browser sniffing like it was good ol' 1998 again.

    It also means we can't track a user across domains which, for this particular project is not an issue, but we have many, many, many clients who have their site on multiple domains. (As an example, think of a pharma company that has a domain for each drug they make, but they're all the same "site".) We'll just have to either tell those clients "no Apple data", or cross that bridge when we come to it.

    Oh well. I knew this would be painful going in, I'm just mildly surprised it's painful in a way that has very little to do with the JS engine in the iPad.

    0
  • Scarlet_Manuka

    @blakeyrat said:

    Filed under: "from visited": vague setting name? Or vaguest setting name?

    This setting name is good. Maybe too good?

    0
  • ?

    But the big question is . . . . if the iPad had a Javascript debugger, would you have solved this problem sooner?

    0
  • blakeyrat

    @El_Heffe said:

    But the big question is . . . . if the iPad had a Javascript debugger, would you have solved this problem sooner?

    Undoubtedly. Although frankly a cookie inspector would have been more useful... hm.

    0
  • sinistral

    Google has recently gotten in hot water about working around this setting:

    As you've found out, the settings differ in wording between desktop Safari (on either Windows or Mac OS X) and mobile Safari. They "simplified" the settings on Mobile Safari, and the default setting is to only allow cookies from the same domain. Apple says this is for privacy, others say it's Apple's way of ensuring that you only use iAds (3rd party cookies are often used by ad networks...).</p

    0
  • blakeyrat

    @sinistral said:

    (3rd party cookies are often used by ad networks...)

    Yeah, for targeting and remarketing. The fallacy here is that blocking 3rd party cookies doesn't stop the ads, it just makes the ads less relevant and less valuable to everybody involved-- that is to say someone relying on web advertising makes less money from Safari and iOS visitors than he does from Chrome visitors. Which stinks, but whatever Apple, we already knew they didn't give a shit.

    AFAIK, their "iAds" platform only works within apps, so it's kind of a different story. However, they might be devaluing ads to prod sites into building otherwise-unnecessary "apps" which can then be iAds customers. I dunno.

    Don't get me wrong: Google is *definitely* in the wrong for bypassing the cookie restrictions. Apple is also in the wrong by setting the default in their browser to "fuck you, website owners", since they knew 80% of browser users will never change the default. (Number based on my pre-cookie-fix data collection.) Edit: oh and Safari is also in the wrong for pretending to store cookies it's not actually storing. If you reject the cookie, don't send it back with the next response, assholes.

    0
  • locallunatic

    @blakeyrat said:

    Edit: oh and Safari is also in the wrong for pretending to store cookies it's not actually storing. If you reject the cookie, don't send it back with the next response, assholes.

    Wait, why would you do that?  In case they are going to try some other tracking thing that doesn't work as well if it fails?  I can't think of any reasonable reason to do this but I've been writing stupid custom controls all day, anyone have an idea?

    0
  • R

    @locallunatic said:

    @blakeyrat said:
    Edit: oh and Safari is also in the wrong for pretending to store cookies it's not actually storing. If you reject the cookie, don't send it back with the next response, assholes.

    Wait, why would you do that? In case they are going to try some other tracking thing that doesn't work as well if it fails I can't think of any reasonable reason to do this but I've been writing stupid custom controls all day, anyone have an idea?

    One of the principles of good security is to never disclose a level of information about authentication failure that would allow attackers to discern the nature of said failure. The most trivial textbook example would be to always use a message like "User not recognized or password invalid" when dealing with acount logon forms and to never explicitly mention which of those two actually happened.

    The same information hiding is being applied by Apple; even though cookies are not stored, they still act as if they are. So yes; preventing ad farms etc. from 'trying some other tracking thing' is exactly why they do it.

    0
  • blakeyrat

    @Ragnax said:

    One of the principles of good security is to never disclose a level of information about authentication failure that would allow attackers to discern the nature of said failure.

    We're talking about setting a cookie. It has nothing to do with security. (Or authentication, in this case.)

    0
  • R

    @blakeyrat said:

    @Ragnax said:
    One of the principles of good security is to never disclose a level of information about authentication failure that would allow attackers to discern the nature of said failure.
    We're talking about setting a cookie. It has nothing to do with security. (Or authentication, in this case.)

    It has to do with securing the user's browsing behavior, as in preventing it from being tracked by third party advertisements. My bad on the use of 'authentication' though; that should've read 'authorization'.

    0
Log in to reply