Closed Bug 1189163 Opened 5 years ago Closed 4 years ago

Unable to scroll down to see all review comments on site


(Web Compatibility :: Mobile, defect, major)

Not set


(firefox40 affected, firefox41 affected, firefox42 affected)

Tracking Status
firefox40 --- affected
firefox41 --- affected
firefox42 --- affected


(Reporter: ritu, Unassigned)




(Keywords: reproducible, Whiteboard: [js] [sitewait])


(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

1. Go to
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.
Product: Firefox for Android → Firefox
Target Milestone: --- → Firefox 42
Version: Firefox 40 → 40 Branch
[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.
Attached image Safari Correctly Renders Comments (obsolete) —
Confirmed reproducible with link above on FF 40. Does not reproduce on Safari. Is this a regression?
Keywords: reproducible
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)
[Tracking Requested - why for this release]: This issue is affecting more than one site and also affects FF40.
> 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)
Attached image star-ratings.jpg
Screen snapshot 1 shows "star ratings" that need to be clicked on to repro the bug.
Flags: needinfo?(rkothari)
Screen snapshot of the problem where scroll down to the very end does not show more comments.
(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.
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)
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)
(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.
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):

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.
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.
...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.
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:

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
Product: Core → Tech Evangelism
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.)
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":
	-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.
For reference, main.css (which has the -webkit prefixed CSS quoted in comment 22) is located at
(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.)
Whiteboard: [js] [sitewait]
Is tracking still requested for this, since it seems to be a Macy's JavaScript bug?
(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.)
Attachment #8641739 - Attachment is obsolete: true
Attachment #8641740 - Attachment is obsolete: true
Ok we have now a separate issue here for this bug.

After entering

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?
Closed: 4 years ago
Resolution: --- → INVALID
I can still reproduce the original bug here, using the URL in comment 1, in a profile with a mobile user agent. Reopening.
Resolution: INVALID → ---
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 "" "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
Server: AkamaiGHost
X-Macys-Device: Phone
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.
Seems fine now - I guess the site has changed.
Closed: 4 years ago4 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.