Closed
Bug 1189163
Opened 9 years ago
Closed 8 years ago
Unable to scroll down to see all review comments on Macys.com site
Categories
(Web Compatibility :: Site Reports, defect)
Web Compatibility
Site Reports
Tracking
(firefox40 affected, firefox41 affected, firefox42 affected)
RESOLVED
WORKSFORME
People
(Reporter: ritu, Unassigned)
References
()
Details
(Keywords: reproducible, Whiteboard: [js] [sitewait])
Attachments
(4 files, 2 obsolete files)
This is a problem in desktop and Fennec versions 39, 40 and 41. Fennec 40.0, Build Id: 2015-07-27 Fennec 30.0, Build Id: 2015-06-25 STR: 1. Go to http://m.macys.com/shop/product/alfani-skinny-pull-on-capri-pants-only-at-macys?ID=817261&CategoryID=157 2. Click on the start ratings on the right. Expected results: On the reviews page, you should see a bunch of customer review comments, 10+ at least by default. Actual results: On the reviews page, I see only one customer comment, and a tiny bit of the second one. Scroll up and down also seems to behave strangely.
Reporter | ||
Updated•9 years ago
|
status-firefox40:
--- → affected
status-firefox41:
--- → affected
status-firefox42:
--- → affected
Product: Firefox for Android → Firefox
Target Milestone: --- → Firefox 42
Version: Firefox 40 → 40 Branch
Reporter | ||
Comment 1•9 years ago
|
||
[Tracking Requested - why for this release]: Not being able to scroll down and view several comments in one go is a terrible experience for me as an end-user. There was no workaround either. This must be a regression.
tracking-firefox41:
--- → ?
tracking-firefox42:
--- → ?
Comment 3•9 years ago
|
||
Comment 4•9 years ago
|
||
Comment 5•9 years ago
|
||
Also affects this website: http://techcrunch.com/2015/07/30/pushed-over-the-edge/#.5fcvsx:VAWV
Comment 6•9 years ago
|
||
Confirmed reproducible with Macys.com link above on FF 40. Does not reproduce on Safari. Is this a regression?
Keywords: reproducible
Updated•9 years ago
|
Keywords: regressionwindow-wanted
Comment 7•9 years ago
|
||
Hi Justin, I know you are working on FF layout and this is affects the U.I. of Firefox and Usability. Do you know if we can get eyes on this?
Flags: needinfo?(dolske)
Reporter | ||
Comment 8•9 years ago
|
||
[Tracking Requested - why for this release]: This issue is affecting more than one site and also affects FF40.
tracking-firefox40:
--- → ?
Comment 9•9 years ago
|
||
> 2. Click on the start ratings on the right.
I cannot find "the start ratings on the right".
Could you attach screenshot.
Flags: needinfo?(rkothari)
Reporter | ||
Comment 10•9 years ago
|
||
Screen snapshot 1 shows "star ratings" that need to be clicked on to repro the bug.
Flags: needinfo?(rkothari)
Reporter | ||
Comment 11•9 years ago
|
||
Screen snapshot of the problem where scroll down to the very end does not show more comments.
Reporter | ||
Comment 12•9 years ago
|
||
(In reply to Alice0775 White from comment #9) > > 2. Click on the start ratings on the right. > > I cannot find "the start ratings on the right". > Could you attach screenshot. Done. Please see star-ratings.jpg. Also, my STR had a typo I meant star ratings.
Reporter | ||
Comment 13•9 years ago
|
||
I need help finding an owner for this bug. This is a pretty major issue that I run into often on desktop and fennec. Can somebody please help? Thanks!
Flags: needinfo?(dtownsend)
Flags: needinfo?(dbaron)
Comment 14•9 years ago
|
||
If this is a Firefox bug then it probably belongs in Layout somewhere, but it could well be a website bug. I'm not sure why this is suddenly a priority, the bug reproduces all the way back to Firefox 9.0 (I gave up looking at that point). Given that a regression range is unlikely to be helpful (it might not even be a regression) and I don't think we should track this.
Component: General → Layout
Flags: needinfo?(dtownsend)
Flags: needinfo?(dolske)
Product: Firefox → Core
Target Milestone: Firefox 42 → ---
Version: 40 Branch → Trunk
Please make the techcrunch issue a separate bug unless you've demonstrated that they're the same underlying problem.
Flags: needinfo?(dbaron)
Keywords: testcase-wanted
(In reply to David Baron [:dbaron] ⏰UTC-7 from comment #15) > Please make the techcrunch issue a separate bug unless you've demonstrated > that they're the same underlying problem. Also, the techcrunch issue is that something is being blocked by tracking protection; if I turn off privacy.trackingprotection.enabled then I see the techcrunch comments, but if I turn it on then I don't see comments. This does not appear to be the case for the macy's link.
Comment 17•9 years ago
|
||
Looking at the Macys site in devtools, it looks like the reviews are all inside of this element: <div style="display: block; min-height: 829px;" class="mb-modal-wrapper modal-level-1 modal-visible" id="m-j-reviews-modal-container"> ...which is "position: fixed" (from a rule targeted at .mb-modal-wrapper in this stylesheet): http://m.macys.com/mew20/styles/css/main.css In Chrome (where the reviews scroll correctly), that element has "position:absolute" applied *directly* in its style attribute, which makes the site behave as-expected. I verified that things work in Firefox if I add that to the element's style attribute.
Comment 18•9 years ago
|
||
So the issue seems to be that they're serving us an element that's "position:fixed" (and hence unscrollable), whereas they're overriding that in Chrome and giving the element "position:absolute" via the style attribute there. This might be due to UA sniffing + different behavior, or (more likely) due to them running some JS that trips over something in Firefox & bails out before they get a chance to dynamically tweak the element's style attribute. I do see several JS errors in devtools when I load the page.
Comment 19•9 years ago
|
||
...but I don't see any new JS Errors appear when I click the ratings, actually. So they may not be tripping over a JS error actually.
Comment 20•9 years ago
|
||
In chrome, the position:absolute tweak happens here in _modalView.js, at line 123: //Replace position: fixed that was set during transition to avoid //vertical scroll but which disables window scroll that we need //TO DO: moved it down to after page height changes this.$el.css('position', 'absolute'); URL of script: http://m.macys.com/mew20/scripts/views/_modalView.js This is in a function called "endOfShow" which is invoked as-follows: //Start transition setTimeout(function() { this.$el.addClass('modal-visible').one('webkitTransitionEnd', _.bind(this.endOfShow, this)); }.bind(this), 700); }, So they're chaining this functionality off of an event ("webkitTransitionEnd") which is webkit-specific.
Component: Layout → Mobile
Keywords: regressionwindow-wanted,
testcase-wanted
Product: Core → Tech Evangelism
Comment 21•9 years ago
|
||
Here's a snapshot of the script that's causing the trouble, FWIW. I verified in Firefox's devtools that the "show()" function here is getting triggered (when I click the stars), but "endOfShow()" never gets triggered (since it's keyed off of a webkit-specific event), and as a result, position never gets changed to absolute, and which means things never become scrollable. (This isn't as simple as just s/webkitTransitionEnd/transitionEnd/, either, because I don't see a transition happening at all in Firefox. They're probably using "-webkit-transition" to play the transition.)
Comment 22•9 years ago
|
||
Actually, it might be *almost* as easy as using "transitionEnd" here. The only other thing that's needed is to get the transition actually playing. They have a mix of prefixed "transition:...transform" styles in their main.css stylesheet, but they all use "-webkit-transform": .mb-fixed-modal-wrapper{ -webkit-transition:-webkit-transform 0.5s ease-in-out; -moz-transition:-webkit-transform 0.5s ease-in-out; transition:-webkit-transform 0.5s ease-in-out; To get the transition to play in standards-based browsers, they need to add one more fully-unprefixed line there: transition:transform 0.5s ease-in-out; With that, I expect we'll play the transition & fire a transitionEnd event at the appropriate time, which they can listen for & invoke endOfShow.
Comment 23•9 years ago
|
||
For reference, main.css (which has the -webkit prefixed CSS quoted in comment 22) is located at http://m.macys.com/mew20/styles/css/main.css
Comment 24•9 years ago
|
||
Comment 25•9 years ago
|
||
(I have a friend who's an engineer at Macy's -- I just sent him an email to see if he can get this filed & hopefully looked into internally there.)
Updated•9 years ago
|
Whiteboard: [js] [sitewait]
Comment 26•9 years ago
|
||
Is tracking still requested for this, since it seems to be a Macy's JavaScript bug?
Comment 27•9 years ago
|
||
(Yeah, I don't think tracking makes sense; those flags were set based on the assumption that this was bug in Firefox & a regression (comment 1), neither of which turned out to be the case. --> Clearing flags.)
Updated•9 years ago
|
Attachment #8641739 -
Attachment is obsolete: true
Updated•9 years ago
|
Attachment #8641740 -
Attachment is obsolete: true
Updated•9 years ago
|
Comment 28•9 years ago
|
||
Ok we have now a separate issue here for this bug. After entering http://m.macys.com/shop/product/alfani-skinny-pull-on-capri-pants-only-at-macys?ID=817261&CategoryID=157 We are redirected to the equivalent desktop page. I tried in Chrome same results. The Mobile site has vanished? Reviews are readable from the desktop page. Should we close as INVALID?
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Comment 29•9 years ago
|
||
I can still reproduce the original bug here, using the URL in comment 1, in a profile with a mobile user agent. Reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 30•9 years ago
|
||
Ah interesting. Daniel which user agent did you use? I tried on a clean profile with Nightly with Firefox UA for Android. And with Chrome UA. They both get me to the desktop site. Same thing on Android devices. * Mozilla/5.0 (Linux; Android 4.4.4; SH-01G Build/SB080) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.76 Mobile Safari/537.36 * Mozilla/5.0 (Android 4.4.4; Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 For example, → http GET "http://m.macys.com/shop/product/alfani-skinny-pull-on-capri-pants-only-at-macys?ID=817261&CategoryID=157" "User-Agent:Mozilla/5.0 (Linux; Android 4.4.4; SH-01G Build/SB080) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.76 Mobile Safari/537.36" HTTP/1.1 302 Moved Temporarily Connection: keep-alive Content-Length: 0 Date: Wed, 25 Nov 2015 06:55:31 GMT Location: http://www.macys.com/shop/product/alfani-skinny-pull-on-capri-pants-only-at-macys?ID=817261&CategoryID=157&bypass_redirect=yes Server: AkamaiGHost X-Macys-Device: Phone
Comment 31•9 years ago
|
||
I'm using this UA string (on Desktop, via "User Agent Switcher" add-on, from which I chose the Android mobile-device icon): Mozilla/5.0 (Linux; U; Android 4.4.4; Nexus 5 Build/KTU84P) AppleWebkit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30 I see the mobile site in a Private Browsing tab, too, so there's no cookie dependency here or anything like that.
Comment 32•9 years ago
|
||
Daniel, thanks Using your UA and a clean profile I still get the desktop site http://m.macys.com/shop/product/alfani-skinny-pull-on-capri-pants-only-at-macys?ID=817261&CategoryID=157 -> http://www1.macys.com/shop/product/alfani-skinny-pull-on-capri-pants-only-at-macys?ID=817261&CategoryID=157&bypass_redirect=yes That starts to be interesting. I think I will test from Orlando.
Comment 33•8 years ago
|
||
Seems fine now - I guess the site has changed.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 8 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•5 years ago
|
Product: Tech Evangelism → Web Compatibility
Assignee | ||
Updated•21 days ago
|
Component: Mobile → Site Reports
You need to log in
before you can comment on or make changes to this bug.
Description
•