Closed Bug 750689 Opened 9 years ago Closed 3 years ago

itunes.apple.com - Back / Forward swiping overrides horizontal carousels

Categories

(Web Compatibility :: Desktop, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ibarlow, Assigned: karlcow)

References

()

Details

(Whiteboard: [country-us] [js] [sitewait])

When I go to a page like http://itunes.apple.com/gb/app/design-museum-collection-for/id510964197?mt=8 and try to use two fingers to swipe through the carousel of images, the browser seems to think I am trying to go forward or back, and slides the entire page from side to side. 

It would be great to detect when a user is hovering over a carousel or other form of scrollable area, and to map gestures that are specific to that area.
Javascript on that page seems to be overriding the ability to scroll that example with left/right arrow keys.
Does swiping work in that example if you disable javascript?
Hm, yes it does.
They should be calling preventDefault() on the scroll event. That's how you indicate that you've taken over scrolling, and it would prevent the back/forward action.

Also, if the window is narrow enough that the page requires a horizontal scrollbar, you can see that scrolling horizontally in the slide box scrolls both the slide box and the complete page. Properly calling preventDefault would fix that, too.
Given the above, should the product be changed to Tech Evangelism?
I think so.
Assignee: nobody → english-us
Component: General → English US
Product: Firefox → Tech Evangelism
QA Contact: general → english-us
There are around 25 instances of preventDefault() :)
The issue still exists.

Hallvord do you want to give it a spin?
Assignee: english-us → nobody
Component: English US → Desktop
Flags: needinfo?(hsteen)
Whiteboard: [country-us] [js]
Summary: [UX Nightly] Back / Forward swiping overrides horizontal carousels → itunes.apple.com - Back / Forward swiping overrides horizontal carousels
The DOMMouseScroll handler on .ipad-screen-shots should presumably only cancel the default action if it *actually* does something. If the Apple developers want more precise pinpointing of the broken code I can have another look..
Flags: needinfo?(hsteen)
Whiteboard: [country-us] [js] → [country-us] [js] [contactready]
Apple has been contacted by email.

Hallvord:

> In the meantime, could we get more detailed information 
> on this ticket? It we can get Hallvord to further 
> investigate it’ll help move the issue along.
Assignee: nobody → kdubost
Status: NEW → ASSIGNED
Flags: needinfo?(hsteen)
Whiteboard: [country-us] [js] [contactready] → [country-us] [js] [sitewait]
Blocks: 1098092
<div style="overflow-x: hidden; padding: 0px;" num-items="5" class="content ipad-screen-shots items5">

Versus this in Opera:

<div num-items="5" class="content ipad-screen-shots items5">

Firefox gets an element faking a scroll bar:
<div id="scroller_0" class="control"><div class="control_cap"><div style="width: 26.5508%;" class="scroll"><div class="scroll_cap"></div></div></div></div>

Presumably they added the scroll event listener to detect scroll events and let the JS logic kick in..?

I'm a bit puzzled though -  on this demo http://jsfiddle.net/hcsmLens/ I don't see any events fire when scrolling horizontally with a two-finger swipe.
For whatever reason, WebKit browsers are purposefully excluded from getting the fake scrollbar feature:

https://itunes.apple.com/htmlResources/1583/web-storefront-preview.js

    jQuery.fn.AppGallery = function(e) {
.
.
        var n, r, i = jQuery.browser.webkit,
.
.
.
                        if (!i) {
                            r(this.container);
                            var l = {
                                orientation: "horizontal",
                                track_wrapper: jQuery("#scroller_" + n),
                                track_well: "null",
                                track_well_cap: "null",
                                track_thumb: jQuery(".scroll", this.container),
                                track_thumb_cap: jQuery(".scroll_cap", this.container),
                                content_wrapper: this.container,
                                content: jQuery(".image-wrapper", this.container)
                            };
                            jQuery(this.container).is_scrollable(l)
                        }

That's why you can swipe to scroll in WebKit-based browsers but not in Firefox.
Flags: needinfo?(hsteen)
Recontacted today Apple engineers I have in contact.
no move here from Apple and silence from the other side.
It seems like there's no longer a website to browse iTunes content - the URL in question just tries to open iTunes. INVALID?
Same as Bug 1098092 They changed the way to handle things. Yup INVALID.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
Mac App store pages don't seem to redirect to the App Store yet automatically, so this bug is still reproducible on those pages, e.g. https://itunes.apple.com/ca/app/microsoft-remote-desktop/id715768417?mt=12
Ah indeed this page exhibits the issue. Thanks Markus.
https://itunes.apple.com/ca/app/microsoft-remote-desktop/id715768417?mt=12

The body starts with

<body onload="detectAndOpenMacAppStore();" 
      class="software geo-ca ac-platter-content lang-en-ca lang-en ac-gn-current-music mac-app-store-detected">

In https://itunes.apple.com/htmlResources/77ec/web-storefront-preview.js:formatted  

function checkIfAskPermissionApprovalSheet() {
  if ( - 1 < navigator.userAgent.indexOf('AskPermission')) {
    var e = document.getElementsByTagName('html') [0];
    e.className = 'approval-sheet'
  }
}
function detectAndOpenItunes(e) {
  if ( - 1 < navigator.userAgent.indexOf('AskPermission')) return;
  if ( - 1 < navigator.userAgent.indexOf('iPhone') && navigator.userAgent.match(/google/i) === null || - 1 < navigator.userAgent.indexOf('iPod') && - 1 < window.location.href.indexOf('ign-iphone')) {
    e = window.location.href;
    var t = 'ign-iphone=1';
    if (!e.indexOf(t)) {
      var n = e.indexOf('?') === - 1 ? '?' : '&';
      e += n + t
    }
    return window.location.href != e && setTimeout(function () {
      window.location.href = e
    }, 1),
    !1
  }
  var r = its.detect.itunesDetected(),
  i = its.detect.shouldAutolaunch(),
  s = its.detect.macBookStoreDetected() && its.detect.currentPageIsMacBookStore(e);
  return itms.PageData.itunesDetectedCallback(r, i, s),
  r && i ? its.detect.openItunes(e)  : !0
}
function detectAndOpenMacAppStore(e) {
  if ( - 1 < navigator.userAgent.indexOf('AskPermission')) return;
  var t = its.detect.macAppStoreDetected(),
  n = its.detect.shouldAutolaunch();
  return itms.PageData.macAppStoreDetectedCallback(t, n),
  t && n ? its.detect.openItunes(e)  : !0
}


btw opening the same link in Safari Developer Preview and I do not have an automatic redirection either.

In Safari the body element is slightly different.

<body onload="detectAndOpenMacAppStore();" 
      class="software geo-ca ac-platter-content lang-en-ca lang-en ac-gn-current-music mac-app-store-detected">
  

For the issue at stake, aka the scrolling with two fingers.
This indeed still not really working.

When clicking instead of scrolling a record of the position is sent to the console.

    jQuery(n.track_wrapper).bind({
      click: function (e) {
        var r = t['orientation'] == 'vertical' ? e.pageY : e.pageX;
        r > u.max && (r = u.max),
        r < u.min && (r = u.min),
        console.log(e.pageX, i.x),
        n.set_scroll(r)
      }
    }),


They have this special mousewheel.

  var r = [
    'DOMMouseScroll',
    'mousewheel'
  ];
  $.event.special.mousewheel = {
    setup: function () {
      if (this.addEventListener) for (var e = r.length;
      e;
      ) this.addEventListener(r[--e], i, !1);
       else this.onmousewheel = i
    },
    teardown: function () {
      if (this.removeEventListener) for (var e = r.length;
      e;
      ) this.removeEventListener(r[--e], i, !1);
       else this.onmousewheel = null
    }
  },

  $.fn.extend({
    mousewheel: function (e) {
      return e ? this.bind('mousewheel', e)  : this.trigger('mousewheel')
    },
    unmousewheel: function (e) {
      return this.unbind('mousewheel', e)
    }
  });
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Contacted apple through the partner mailing-list.
Status: REOPENED → ASSIGNED
I think the site has been redesigned, but either way we get the same behave as Safari now.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago3 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.