Closed Bug 1205027 Opened 4 years ago Closed 3 years ago

Steam store website does not load the rest of the webpage when scrolling down

Categories

(Core :: General, defect)

27 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox42 - ---
firefox43 - ---
firefox44 - ---
firefox45 - wontfix
firefox46 - wontfix
firefox47 + wontfix
firefox48 + wontfix
firefox49 + fixed

People

(Reporter: mkdante381, Assigned: emk)

References

(Depends on 1 open bug, )

Details

(Keywords: regression, testcase)

Attachments

(4 files, 6 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150914185908

Steps to reproduce:

1. Go to http://store.steampowered.com/
2. Login
3. Scroll down on this site
4. Firefox does not load the rest of the page, when user scroll down. 

Don't help refresh site, clear cookies and cache. I tested it on a clean profile and this problem is on all latest Firefox beta/developer/Nightly and maybe stable


Actual results:

Firefox don't load properly site http://store.steampowered.com/
Default this site load content, when user scroll down. Latest Firefox versions beta/developer/Nightly They have a problem with it.


Expected results:

Firefox don't load properly site http://store.steampowered.com/
Don't load content, when user scroll down on this site. It does not help to change the settings
Severity: normal → critical
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Summary: Problem with Steam site → Problem with Steam store site
WFM ith FF43, attach screenshot please.
Flags: needinfo?(mkdante381)
Severity: critical → normal
Now I have Firefox 41RC build1
Default Steam site load more recommendations, when user scroll down(load the rest of the page). Default is infinite scroll, because Steam site load more recommendations. Firefox not load properly this site. Scroll down and after inscription "Keep scrolling for more recommendations" firefox load only part this site.
https://box.everhelper.me/attachment/288207/RyS5pvQgr6uDt4YdZp4YCrfZd6qnqnm3/392492-xOMpheu1XX2yP34o/screen.png
Flags: needinfo?(mkdante381)
When this bug will be repaired?
I recorded this in Firefox. https://youtu.be/pM4aShybdFs
FF sometimes not load more with this site and help only press F5, but still does not load recommnedations.
This is from Google Chrome https://youtu.be/dC_E1PZNyO4. No problem with load more recommendations on this site and in this browser.
[Tracking Requested - why for this release]:
Problem on 41stable, 42beta, 43 developer, 44 Nightly
Bug is not repaired? Why Mozilla not fix this? Problem is also with youtube.com on Windows 7. Youtube freeze in Firefox and problem with playing YT movies.
My bug report "Firefox freeze on http://www.youtube.com and also freeze on youtube movies":
https://bugzilla.mozilla.org/show_bug.cgi?id=1215403
Flags: needinfo?(epinal99-bugzilla2)
Bug is not fixed because we need a reduced testcase of the issue, not the all Steam page.
It could be a tech evangelism issue perhaps.
Flags: needinfo?(epinal99-bugzilla2)
Keywords: testcase-wanted
Alice, any idea?
Not tracking because, for now, we don't have a proof that it is a firefox issue and not steam.
Seriously? I must use Google Chrome because Mozilla not report this to Lord GAben or Steam Support. THX for not repair this bug. THX for nothing...
OK 2 problems: 
-1st problem is scroll down and FF not load recommendations, sometimes load one recommendations list
-2nd problem is the drop-down lists for Games, Software, Hardware, and For You disappear when you try to click one of the items

Problem is resolved, when you install Greasemonkey and this script:
https://greasyfork.org/pl/scripts/13121-fix-drop-down-menus-on-steam-store

With this script FF load more recommendations list and no problem with lists for Games, Software, Hardware, and For You on this site.
About an hour ago work great. Now this script fix only this drop-down lists... Mozilla report this to Valve
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
See Also: → 1205244
Why is this bug report closed? Are you sure that the same underlying issue?
Sry my bad. I changed accidentally
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Component: Untriaged → Layout
Product: Firefox → Core
Summary: Problem with Steam store site → Steam store website does not load the rest of the webpage when scrolling down
Blocks: 1205244
(--> Removing bug 1205244 from "blocks" list; it doesn't seem to have any connection to the actual bug here, other than that it's a distinct issue on the same site.  Note that it is on this bug's "see also" list, which does make sense, but a "blocking" relationship does not make sense.)
No longer blocks: 1205244
I can't reproduce this bug. I tested latest Firefox Nightly, 45.0a1 (2015-11-07), and latest release, Firefox 42.0.  In both cases, I started with a fresh profile, logged in to Steam using the URL from comment 0, and I was able to scroll down through several pages of recommendations (with periodic "keep scrolling -i|" throbber animations) just fine.

Maybe Steam fixed this? Can you still reproduce this endless-scrolling issue, mkdante?
Flags: needinfo?(mkdante381)
(In reply to mkdante381 from comment #10)
> Seriously? I must use Google Chrome because Mozilla not report this to Lord
> GAben or Steam Support. THX for not repair this bug. THX for nothing...
(In reply to mkdante381 from comment #13)
> About an hour ago work great. Now this script fix only this drop-down
> lists... Mozilla report this to Valve

FYI, we don't have any special channel to report issues to Valve (and Mozilla has limited resources, which is why bugs like this one sometimes sit for a little while).  You should consider yourself just as empowered as we are to reach out to sites like Steam when they're broken! :)

Having said that, per comment 18, I can't reproduce this, so I'm not sure there's a bug here anymore.
Look on movies in Comment 4 and sites in "See Also". Default steam site load infinite list recommendations(look on 2nd film on Google Chrome). Steam not fixed this. Tested on fresh profile Nightly, Dev Edition and beta. Google Chrome load properly this site.
Flags: needinfo?(mkdante381)
I think your noticed it, but you need to have a Steam account to reproduce the issue (because Steam doesn't display the responsive game list for a guest, this list being based on the player's game library).

I tested with the latest Nightly and it's still reproducible.

I'm on Win 7 with resolution at 125%.
I did watch the movies in comment 4, but I can't reproduce that issue locally (and I was indeed logged in to my account when I tested).  Infinite-scrolling seems to "just work" here (including with multiple page-fulls of content). 

In any case, this is unlikely to be a layout issue; it looks like something is preventing Steam from adding more content to the website, which could be a DOM issue or a JS issue or a Steam bug, but unlikely a Layout bug. --> Bumping to Core|General for now.

Do you see anything appear in Error Console (Ctrl+Shift+J) right when you hit the bottom of the page & the infinite scrolling fails to work? If so, that might give us a hint about what's happening here.
Component: Layout → General
Thanks! That's quite a lot of output. Do you know how much of that is from *when you actually trigger this bug*? (vs. from when the page initially loads, vs. from earlier in your browsing session.)

If you didn't already do so, it might be worth visiting Steam, clearing the console (with its "Clear" button at the right edge of its top buttons), and then scrolling to trigger the bug, and only capturing the console output at that point.
Flags: needinfo?(mkdante381)
ReferenceError: reference to undefined property v.ajaxSettings.traditional jquery-1.8.3.min.js:2:78395
GET 
XHR 
http://store.steampowered.com/apphover/286040 [HTTP/1.0 200 OK 582ms]
ReferenceError: reference to undefined property f.opts.start jquery-1.8.3.min.js:2:7176
ReferenceError: reference to undefined property t[0] jquery-1.8.3.min.js:2:25929
ReferenceError: reference to undefined property f.opts.easing jquery-1.8.3.min.js:2:6838
GET 
http://cdn.akamai.steamstatic.com/steamcommunity/public/images/avatars/d5/d5b61b854638fe3deb151e823e17aeb64eb161f9.jpg [HTTP/1.0 200 OK 60ms]
GET 
http://cdn.akamai.steamstatic.com/steamcommunity/public/images/avatars/5c/5c400205ecd50edc5ad4173efe20137139a502b2.jpg [HTTP/1.0 200 OK 0ms]
GET 
http://cdn.akamai.steamstatic.com/steamcommunity/public/images/avatars/a3/a31d5e6759554dc72c7d00b13a11a332908aaddd.jpg [HTTP/1.0 200 OK 241ms]
GET 
http://cdn.akamai.steamstatic.com/steamcommunity/public/images/avatars/0b/0bdbcaabf12f5a6eb2e90f1393092bca7a6efb34.jpg [HTTP/1.0 200 OK 224ms]
GET 
http://cdn.akamai.steamstatic.com/steamcommunity/public/images/avatars/0f/0f12721883857f0d5fdbe5f372c2d5e0c34359a1.jpg [HTTP/1.0 200 OK 36ms]
GET 
XHR 
http://store.steampowered.com/apphover/286690 [HTTP/1.0 200 OK 667ms]
GET 
XHR 
http://store.steampowered.com/explore/recommended/ [HTTP/1.0 200 OK 0ms]
GET 
XHR 
http://store.steampowered.com/explore/render/ [HTTP/1.0 200 OK 0ms]
ReferenceError: reference to undefined property ele.index home.js:1145:7
GET 
http://cdn.akamai.steamstatic.com/steam/apps/351640/header.jpg [HTTP/1.0 200 OK 314ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/261180/header.jpg [HTTP/1.0 200 OK 275ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/293780/header_292x136.jpg [HTTP/1.0 200 OK 100ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/265610/header_292x136.jpg [HTTP/1.0 200 OK 196ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/269770/header_292x136.jpg [HTTP/1.0 200 OK 195ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/339350/header_292x136.jpg [HTTP/1.0 200 OK 177ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/377160/header_292x136.jpg [HTTP/1.0 200 OK 226ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/377160/ss_4733a1f56becbff21118435bd49561d0ed2392e7.600x338.jpg [HTTP/1.0 200 OK 673ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/377160/ss_f7861bd71e6c0c218d8ff69fb1c626aec0d187cf.600x338.jpg [HTTP/1.0 200 OK 615ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/377160/ss_910437ac708aed7c028f6e43a6224c633d086b0a.600x338.jpg [HTTP/1.0 200 OK 598ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/730/header_292x136.jpg [HTTP/1.0 200 OK 2273ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/730/ss_34090867f1a02b6c17652ba9043e3f622ed985a9.600x338.jpg [HTTP/1.0 200 OK 3275ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/730/ss_1d30c9a215fd621e2fd74f40d93b71587bf6409c.600x338.jpg [HTTP/1.0 200 OK 3203ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/730/ss_baa02e979cd3852e3c4182afcd603ab64e3502f9.600x338.jpg [HTTP/1.0 200 OK 3269ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/311210/header_292x136.jpg [HTTP/1.0 200 OK 349ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/311210/ss_ca7376d838d5714f916936f0070824c27c4c5641.600x338.jpg [HTTP/1.0 200 OK 770ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/311210/ss_150874824f4fff0915e63ea2ade5410e576a2b70.600x338.jpg [HTTP/1.0 200 OK 742ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/311210/ss_4b270e7a32d3a93a8119e7bcc3d8dcaa784f84f1.600x338.jpg [HTTP/1.0 200 OK 1122ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/570/header_292x136.jpg [HTTP/1.0 200 OK 2450ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/570/ss_09f21774b2309fcb67a2d9f8b385b47c48e985ff.600x338.jpg [HTTP/1.0 200 OK 2978ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/570/ss_2a951d65c6084004dcdc292d4944c0fb4a059624.600x338.jpg [HTTP/1.0 200 OK 3440ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/570/ss_6a426a8d2d15ce7d7d9077f81c95daf3257fe387.600x338.jpg [HTTP/1.0 200 OK 3361ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/252490/header_292x136.jpg [HTTP/1.0 200 OK 694ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/252490/ss_e5884f9f2965ec5f6d8d071e8991a157619977a0.600x338.jpg [HTTP/1.0 200 OK 1089ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/252490/ss_a33a5b55729ab35bd8f91fe94af2399c333e65d2.600x338.jpg [HTTP/1.0 200 OK 820ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/252490/ss_8e1fe9d8d20a441c0c4d1ea055898b2a400227a3.600x338.jpg [HTTP/1.0 200 OK 869ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/242760/header_292x136.jpg [HTTP/1.0 200 OK 852ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/242760/ss_07cd1f1a1698be47f7477877fd76eae312d886df.600x338.jpg [HTTP/1.0 200 OK 1213ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/242760/ss_a070580ddb4ffeec2a284a1b9ba3a3b1594d61bb.600x338.jpg [HTTP/1.0 200 OK 1401ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/242760/ss_8bea38878c6e1590447cf2ccbc9e192567494d2f.600x338.jpg [HTTP/1.0 200 OK 1304ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/105600/header_292x136.jpg [HTTP/1.0 200 OK 3506ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/105600/ss_8c03886f214d2108cafca13845533eaa3d87d83f.600x338.jpg [HTTP/1.0 200 OK 3550ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/105600/ss_ae168a00ab08104ba266dc30232654d4b3c919e5.600x338.jpg [HTTP/1.0 200 OK 3663ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/105600/ss_1a091473c0b53e98d7a0708dd3ec0978dd56ba45.600x338.jpg [HTTP/1.0 200 OK 3830ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/214850/header_292x136.jpg [HTTP/1.0 200 OK 1110ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/214850/ss_a7a8ed4541285790334e31d684f49d03910f8f26.600x338.jpg [HTTP/1.0 200 OK 1368ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/214850/ss_cba05b6eadfc98a5a54d2061f40c3e1ebf6eeb3c.600x338.jpg [HTTP/1.0 200 OK 1585ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/214850/ss_f3524136ce6cc737c049a17dec6500bb2b80bf75.600x338.jpg [HTTP/1.0 200 OK 1517ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/363890/header_292x136.jpg [HTTP/1.0 200 OK 1449ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/363890/ss_0c0c7efdab936efa87ef5e42dff22a0ea13ea385.600x338.jpg [HTTP/1.0 200 OK 2067ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/363890/ss_1ed774c372d6e7568a9f25bca9f27fc1e9f5d081.600x338.jpg [HTTP/1.0 200 OK 3544ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/363890/ss_3931a5ce8245a36450f71a570a5f679b8e39fc06.600x338.jpg [HTTP/1.0 200 OK 2158ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/325180/header_292x136.jpg [HTTP/1.0 200 OK 1935ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/325180/ss_81591b5197669c2c931ae76e9056d09d54b174d6.600x338.jpg [HTTP/1.0 200 OK 1719ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/325180/ss_de61652291c21dc3222703756e0bc211cf4b5a68.600x338.jpg [HTTP/1.0 200 OK 1766ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/325180/ss_796b7b40f586855426ee861a2a2d7fcabeb0446d.600x338.jpg [HTTP/1.0 200 OK 1913ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/335930/header_292x136.jpg [HTTP/1.0 200 OK 1880ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/335930/ss_9c35342b89a0f000898e071962bbe736209acce0.600x338.jpg [HTTP/1.0 200 OK 2256ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/335930/ss_47ca14579620ada3a29606983a155742c4fbaa11.600x338.jpg [HTTP/1.0 200 OK 2312ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/335930/ss_2a46660e30f4d532f29270dd2a2e5d6e9acfda85.600x338.jpg [HTTP/1.0 200 OK 3838ms]
GET 
http://cdn.akamai.steamstatic.com/steamcommunity/public/images/avatars/eb/eba5fbc3c962fd082517c02ac9301cb6d89bdd41.jpg [HTTP/1.0 200 OK 3479ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/234140/capsule_616x353.jpg [HTTP/1.0 200 OK 2900ms]
GET 
XHR 
http://store.steampowered.com/apphover/339350 [HTTP/1.0 200 OK 830ms]
GET 
http://cdn.akamai.steamstatic.com/steam/apps/3730/capsule_616x353.jpg [HTTP/1.0 200 OK 453ms]
GET 
XHR 
http://steamcommunity.com/actions/GetNotificationCounts [HTTP/1.0 200 OK 443ms]
ReferenceError: reference to undefined property r[s] jquery-1.8.3.min.js:2:70689
GET 
http://cdn.akamai.steamstatic.com/steam/apps/6920/header.jpg [HTTP/1.0 304 Not Modified 41ms]
Flags: needinfo?(mkdante381)
Thanks. The various "ReferenceError: reference to undefined property" issues there sound like they're the issue, though it's hard to know for sure.  For what it's worth, I don't see those errors in my Browser Console, when I (unsuccessfully) try to reproduce the bug -- so that increases my confidence that they're related to whatever's going wrong, as opposed to just being some harmless background noise.

I'm not sure I can help more here (and I can't reproduce, as noted above). [I mostly poked into this bug after taking a look at the other recent Steam bug, bug 1205244, which is more in my area of knowledge].  Hopefully someone else may be able to come along who can help more.

One more random thought, though: maybe there's some weird localization dependence here? Have you tried the en-US version of Firefox and/or Steam, to see if you can reproduce the issue there?  (If this is localization-dependent, that would explain why you can reproduce and I can't.)
AKAMAI CDM seems to stop serving information when this happens.
(In reply to Danial Horton from comment #27)
> AKAMAI CDM seems to stop serving information when this happens.

That could explain why this is reproducible for some people (mkdante381) and not others (me, Loic) -- maybe the CDN node is behaving differently in different parts of the world.

Danial, does comment 27 mean you've been able to reproduce this bug?
Flags: needinfo?(danialhorton)
(Sorry -- correcting myself, it looks like Loic was able to reproduce it eventually (comment 21) after not initially being able to reproduce it (comment 1). I still can't repro; just tried again [logged in], and infinite-scrolling works just fine for me.)
Flags: needinfo?(danialhorton)
:Loic, how confident are you of the regression range in comment 11?

If you're pretty confident (i.e. if this definitely worked before that range & definitely does not after), and if you can still reproduce this, then perhaps I could kick off some Try builds at intermediate points in that range & have you test them to see if they're broken?  Then, we can get a narrower range (ideally the exact commit) & have a better idea of what piece of Firefox code might be involved here? (& what developer to tag to look into this further)
Flags: needinfo?(epinal99-bugzilla2)
I will test again the regression range, I'm back in 5-10 min.
I confirm the regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b5d24ef1eb37&tochan
ge=f191c70fcbfb
Flags: needinfo?(epinal99-bugzilla2)
Thanks, Loic! What platform are you on? I'll kick off some intermediate Try builds in that range, for your platform, if you're up for testing a few more builds to figure out what changeset is responsible.
[Also: promoting this up from UNCONFIRMED, since multiple people can reproduce, and flagging as regression.]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(epinal99-bugzilla2)
Keywords: regression
Platform: Win 7 64b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Flags: needinfo?(epinal99-bugzilla2)
(Hmm, my Try runs seem to have insta-failed, with infrastructure issues. I'll see if I can find someone who knows what's up... maybe the changesets are too old and need some tweak to work with our current TreeHerder infrastructure.)
(Apparently we simply can't do Try builds that old, because our automated-build infrastructure now depends on things that have been added to the tree (in pieces) over a while, which aren't present in old builds. :-/  So, I can't provide intermediate try builds for further bisecting, as I was hoping to do. We may need to just settle for the regression range in comment 11, for now.

Though: Loic, if you have a build environment set up and feel up to doing local intermediate builds, that's one possibility too. But it may be painful; i.e. you'd probably need an old mozilla-build & an old MSVC.)
I don't have such a build environment, sorry.
Same problem here (Windows 8.1 64bit, Firefox 42). I tested this with an Ubuntu Live CD (Firefox 35.0.1), still, same issue. It scrolls down once, then stops. Other web browsers work fine.
Error log:

This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.[Learn More] store.steampowered.com

Use of getPreventDefault() is deprecated.  Use defaultPrevented instead. jquery-1.8.3.min.js:2:0

This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.[Learn More] steamcommunity.com

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://steamcommunity.com/login/checkstoredlogin/?redirectURL=actions%2FGetNotificationCounts. (Reason: CORS header 'Access-Control-Allow-Origin' missing). <unknown>
I just finally hit this bug myself, FWIW. (in Nightly with my normal browsing profile).  I'm hitting it intermittently; I suspect, but am not sure, that it's easier to trigger if I wait for a bit after the page finishes loading before I try to scroll down.

I initially thought the "Cross-Origin Request Blocked" message in comment 41 might be relevant, but it seems to just be background noise (unrelated to this bug) -- it gets spammed periodically, even before I've done any scrolling.  So, not related to the infinite-scroll breakage.
Now that I can reproduce this a good fraction of the time, I did some local targeted builds to narrow the regression range from comment 11.

From my local testing, it's looking like this is a regression from https://hg.mozilla.org/mozilla-central/rev/8434bf06134c (bug 922931).  That changeset seems to only modify the type & size of boxes that we generate for broken images (i.e. whether or not we show a placeholder icon).  So, that must be impacting Steam's logic somehow, when it loads in content dynamically.
I noticed that the scrolling works fine for me now, although Steam's been having a sale for the last few days, so they've probably made some changes in their website that may have affected the problem.
Yes, I tested with FF42 and 45, I am not able anymore to reproduce the issue, I guess Steam fixed it on its side.
reporter, is it fixed for you too?
Flags: needinfo?(mkdante381)
As soon as their sale ended, the old page layout came back, along with the scrolling issue.
Nope Loic you check when was Steam sale. Now Steam sale is end and of course site not load recommendations. Steam not fix this bug. This www site is written for webkit browser engine. Firefox has problem, but other browsers not have this problem. Mozilla Firefox group pls add more compatibility with sites written for webkit browser engine.
Flags: needinfo?(mkdante381)
Why this is not fixed?
Blocks: 922931
Attached file Testcase (obsolete) —
Looks like Chrome and Edge do not display a placeholder (or display a zero-sized placeholder) unless <img> has an explicit size.
Attached file Testcase
...But they will display a placeholder if the src attribute is not empty. Weird...
Attachment #8708620 - Attachment is obsolete: true
Version: 41 Branch → 27 Branch
It didn't fix it for me.
Flags: needinfo?(kabamaru.igano)
Same result here with the 32b-build.
It didn't fix it for me. I tested this builds with fresh profile, asyncpanzoom on and off, acceleration on and off. Errors in console:


Use of getPreventDefault() is deprecated.  Use defaultPrevented instead. jquery-1.8.3.min.js:2:40351

This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; 
see https://developers.mozilla.org/docs/Mozilla/Performance/ScrollLinkedEffects for further details and to join the discussion on related tools 
and features! store.steampowered.com

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://steamcommunity.com/login/checkstoredlogin/?redirectURL=actions%2FGetNotificationCounts. (Reason: CORS header 'Access-Control-Allow-Origin' missing). <unknown> only scroll down and not load
Flags: needinfo?(mkdante381)
This bug is also on Internet Explorer 11
End Steam sale and bug is not fixed
[Tracking Requested - why for this release]:
Not fixed on all Firefox
I can't really call this a recent regression. But, it is an important site that we would like to work in Firefox.  Marking affected for 45+.  It is likely too late to take a fix for beta 46. 

In comment 43, sounds like it was a regression in Firefox 27, and the fix was not verified.   emk, any thoughts? Can you try again to find a fix we can verify?
It was verified that the fix attempt had no effect (see comment 54 & 55).
Flags: needinfo?(VYV03354)
Masatoshi can you assign yourself to the bug if you are going to still work on it? 

Thank you masatoshi and mkdante381, and I'm sorry this slipped through the cracks, I think because the issue comes and goes on Steam.
I'm not working on this anymore.
Catching up on this one...

It seems like the fix for bug 922931, while spec-compliant, isn't interoperable with Blink/Webkit. Steam depends on the Blink/Webkit behavior, which causes this bug. The question for us is whether we:

A. match Blink/Webkit (and perhaps change the HTML spec) or,
B. we ask Steam to fix this on their site (if we can find such a fix.)

Masatoshi: did you have other ideas here? What code changes did you already try?
Flags: needinfo?(VYV03354)
Bug 922931 has made Firefox more close to other browsers. I guess Steam is doing some poor UA detection (but I have not confirmed it myself because I do not have a Stream account).
Flags: needinfo?(VYV03354)
(In reply to Masatoshi Kimura [:emk] from comment #66)
> Bug 922931 has made Firefox more close to other browsers. I guess Steam is
> doing some poor UA detection (but I have not confirmed it myself because I
> do not have a Stream account).

We should do one of two things IMO, either get Steam to change their site and get a commitment from Google to change Chrome's behavior to match the spec, or we should make Firefox behave like Chrome and push for getting the spec updated to match that behavior.
(In reply to Masatoshi Kimura [:emk] from comment #66)
> Bug 922931 has made Firefox more close to other browsers. I guess Steam is
> doing some poor UA detection (but I have not confirmed it myself because I
> do not have a Stream account).

We're able to reproduce this bug on Firefox using the Chrome UA string. Now looking for the offending JS/CSS so we can reach out to Steam.
Assigning a default non-zero size to a null image isn't web-compatible (as speculated in bug 922931 comment 4) and I think we need to revert this change.
Attachment #8755054 - Flags: review?(VYV03354)
Attached patch Rebased patch. (obsolete) — Splinter Review
Attachment #8755054 - Attachment is obsolete: true
Attachment #8755054 - Flags: review?(VYV03354)
Attachment #8755071 - Flags: review?(VYV03354)
Comment on attachment 8755071 [details] [diff] [review]
Rebased patch.

Chrome and Edge do not assign a non-zero default size for null images, but they DO assign it for non-null broken images. This patch will break the latter behavior (see the rightmost column of the attached testcase).
Attachment #8755071 - Flags: review?(VYV03354) → review-
Assignee: nobody → bugs
This patch now differentiates a null image from a broken one.
Attachment #8755071 - Attachment is obsolete: true
Attachment #8755819 - Flags: review?(VYV03354)
Comment on attachment 8755819 [details] [diff] [review]
Prevent 0-sized null images from displaying broken icon.

Did you verify that this patch fixed the issue?
Flags: needinfo?(bugs)
I tried the 32b version on http://store.steampowered.com/ it's not fixed.
Flags: needinfo?(epinal99-bugzilla2)
I tried the 64-bit version and it didn't fix the issue.
Comment on attachment 8755819 [details] [diff] [review]
Prevent 0-sized null images from displaying broken icon.

r- because this patch does not fix the issue.

And this is the reason I doubted a browser sniffing, but it is also refuted by comment #68. Honestly, I don't think we can do anything about this without a minimized test case.
Flags: needinfo?(mkdante381)
Flags: needinfo?(kabamaru.igano)
Flags: needinfo?(bugs)
Attachment #8755819 - Flags: review?(VYV03354) → review-
(In reply to Masatoshi Kimura [:emk] from comment #78)
> Comment on attachment 8755819 [details] [diff] [review]
> Prevent 0-sized null images from displaying broken icon.
> 
> r- because this patch does not fix the issue.
> 
> And this is the reason I doubted a browser sniffing, but it is also refuted
> by comment #68. Honestly, I don't think we can do anything about this
> without a minimized test case.

The earlier patch [1] fixes the issue on Steam but was r- because we lose "broken" image icons for null images.
The latest patch [2] tries to preserve the behavior from bug 922931 but doesn't fix Steam. 

[1] https://bugzilla.mozilla.org/attachment.cgi?id=8755071&action=edit
[2] https://bugzilla.mozilla.org/attachment.cgi?id=8755819&action=edit
(In reply to Masatoshi Kimura [:emk] from comment #78)
> I don't think we can do anything about this
> without a minimized test case.

Steam uses scrollWidth and scrollHeight to do the scroll effects. Here's a minimized test case:
http://media.junglecode.net/test/1205027/th.html

Note the scrollWidth and scrollHeight values for img_1 and img_4 in the test in Firefox vs. other browsers.
The minimized test confirms the root cause of this bug. Displaying the "broken" icon shouldn't change the intrinsic width of the img element, but it does.
Flags: needinfo?(VYV03354)
What information do you expect?
(In reply to Masatoshi Kimura [:emk] from comment #82)
> What information do you expect?

I think we should revert the fix for bug 922931 until we fix the intrinsic width issue. Do you agree?
I took a closer look at this today. I confirmed that I can still reproduce the infinite-scroll breakage (intermittently), even in a build with attachment 8755819 [details] [diff] [review] applied. It helps if I limit my bandwidth with a tool like "wondershaper" (on Linux), BTW.

So, to the extent that we should take that fix (and/or revert bug 922931), I think that might want to happen independently of this bug. More factors seem to have crept in here, which keep Steam broken even when we revert the image behavior.

In the meantime: it looks like Steam's JS here is reasonably debuggable.  I poked around a bit, and I think the problem boils down to this (in "home.js", http://store.akamai.steamstatic.com/public/javascript/home.js?v=OBmrNU_JnUEp&l=english ):

(1) During their page setup function "OnDynamicStoreReady", they make the following call, which is intended to set up the infinite-scroll loading:
> 236  $J('#content_more').autoloader({
>          template_url: 'http://store.steampowered.com/explore/render/',
>          recommendations_url: 'http://store.steampowered.com/explore/recommended/',
>          additional_url: 'http://store.steampowered.com/explore/more'});

(I've added some newlines/whitespace for readability.)

That ends up invoking this line, with "this" and "ele" both pointing to the node for <div id="content_more">:
> 1071    var offset = $(ele).offset();
> 1072    this.nNextTrigger = $(ele).height() + offset.top - 750;

Here, "nNextTrigger" is intended to be the scrolling threshold at which point the extra content loads should be triggered.

Later on, after you scroll, we trigger this code (inside of "scrollFunc"):

> 1338    var scrollFunc = function( event ){
> 1345      var nCurrentScroll = $(window).scrollTop() + $(window).height();
> 1346      if(nCurrentScroll > this.nNextTrigger)
> 1347      {
> 1348        loadFunc.apply(this);
> 1349      }

When the bug reproduces, it's because "nCurrentScroll" is too small (or rather, nNextTrigger is too large & unattainable) -- and we never hit the loadFunc.apply() line.
If I use devtools to place a JavaScript breakpoint at line 1072 (just after Steam has read "$(ele).offset()"), and I repeatedly print out $(ele).offset() while JS is paused on that line, I can see that it gets progressively smaller as the page loads.

In particular: in my debug build right now (with Jet's patch applied), I see the following (lines starting with ">" are commands that I typed):
   > offset
   Object { top: 4056, left: 0 }
   > $(ele).offset()
   Object { top: 3179, left: 0 }
   > $(ele).offset()
   Object { top: 3179, left: 0 }
   > $(ele).offset()
   Object { top: 3079, left: 0 }
   > $(ele).offset()
   Object { top: 3079, left: 0 }

So: it looks like $(ele).offset() *initially* returns something huge -- and that's what Steam is using to set its (unattainable) scroll threshold -- and then as the page continues to load, it returns something considerably smaller.
In contrast: in Chrome, I see $(ele).offset() changing by smaller amounts, and in the positive direction instead of the negative direction.

So for us, nNextTrigger is an overestimate (and hence unattainable); whereas for Chrome, nNextTrigger is an underestimate (and hence very attainable).

(Presumably the shrinking height in Firefox is due to empty/broken images finishing loading and collapsing away.)


Possible resolutions here:
 (1) Maybe there's a later time that Steam should be triggering its "nNextTrigger" initialization code (after content has loaded and $(ele).offset() has stabilized)
 (2) Maybe Steam should update nNextTrigger with the updated "$(ele).offset()" value, after all of its content has loaded.
 (3) Maybe Gecko shouldn't be let the slow-loading images shrink their size by as much as they currently do.  (i.e. backout bug 922931)

So I think I'm now on the same page as Jet in comment 83 (though if we can come up with a specific suggestion for Steam, that'd be great too, and it'd like get this fixed for our users faster).
(In reply to Daniel Holbert [:dholbert] from comment #84)
> I can still reproduce [...] even in a build with
> attachment 8755819 [details] [diff] [review] applied. It helps if I limit my
> bandwidth with a tool like "wondershaper" (on Linux), BTW.
> 
> So, to the extent that we should take that fix (and/or revert bug 922931), I
> think that might want to happen independently of this bug. More factors seem
> to have crept in here, which keep Steam broken even when we revert the image
> behavior.

(Sorry, maybe disregard the "happen independently" and "more factors" part here -- I hadn't noticed the details in comment 79, and I thought attachment 8755819 [details] [diff] [review] was maybe-expected to be a fix for this bug)
Here's a reduced testcase, inspired by Jet's testcase.  This one isn't fixed by attachment 8755819 [details] [diff] [review], and it's a bit closer to the steam page -- reading offsetTop of an element at the bottom of the page during pageload, and again a bit later on.

For the offsetTop read that happens *during pageload* -- before the images have had a chance to load the remote resource & determine their actual sizes -- we're currently behaving as if the images are 24px by 24px, which is a bit arbitrary.  This produces an initial offsetTop value that is much larger than what's actually reflected in the final layout.  And that causes problems on Steam by producing an unattainable scroll-target, as described in comment 84.

Chrome & pre-regression Firefox produce this output (in the web console):
  initial offsetTop: 0
  final offsetTop: 8

Post-regression Firefox produces this output (in the web console):
  initial offsetTop: 192
  final offsetTop: 8

(note: There are 8 1px-tall images here. "192" comes from = 8 * 24px, the arbitrary height that we're using during image-load.)
Comment on attachment 8755819 [details] [diff] [review]
Prevent 0-sized null images from displaying broken icon.

Review of attachment 8755819 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/generic/nsImageFrame.cpp
@@ +797,5 @@
> +        if(imageLoader) {
> +          nsCOMPtr<imgIRequest> currentRequest;
> +          imageLoader->GetRequest(nsIImageLoadingContent::CURRENT_REQUEST,
> +                                  getter_AddRefs(currentRequest));
> +          imageOK = !currentRequest;

This patch doesn't help with my just-attached "testcase 1", because "imageOK" isn't expressive enough here.

In "testcase 1", during the layout-flush for the initial offsetTop read, we get here with a non-null |currentRequest|, because we're getting ready to receive image data but we haven't received any yet (or something like that).

So, imageOK ends up being false (since currentRequest is truthy, and imageOK = !currentRequest).
(In reply to Masatoshi Kimura [:emk] from comment #91)
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=30a484555128
> This build fixed the testcase 1 visible and kept broken images visible.
> Please verify the fix on Stream.
> 
> Win32:
> https://archive.mozilla.org/pub/firefox/try-builds/VYV03354@nifty.ne.jp-
> 30a484555128933fed39b41a2e377f55fe435d6f/try-win32/firefox-49.0a1.en-US.
> win32.installer.exe


WFM normally with Steam Store, like it should be.
Flags: needinfo?(epinal99-bugzilla2)
Daniel, thank you very much for the excellent detective work!
Could you review this patch?
Attachment #8755819 - Attachment is obsolete: true
Attachment #8757591 - Flags: review?(dholbert)
I tried the 64bit build and it solves the issue. Great work, thank you!
Flags: needinfo?(kabamaru.igano)
Comment on attachment 8757591 [details] [diff] [review]
Set the intrinsic size only if the image is actually broken

Review of attachment 8757591 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thank you for writing a fix!

Could you include a reftest or a mochitest as well, perhaps based on my attached testcase?  Probably worth giving the testcase a quick review pass, too; hence, marking f+ for now, but r+ once it's got a solid test to keep this fixed.

Two small nits, too:

::: layout/generic/nsImageFrame.cpp
@@ +794,5 @@
> +        bool imageBroken = false;
> +        // check for broken images. valid null images (eg. img src="") are
> +        // not considered broken because they have no image requests
> +        nsCOMPtr<nsIImageLoadingContent> imageLoader = do_QueryInterface(mContent);
> +        if(imageLoader) {

Add a space before open-paren -- "if(" --> "if ("

@@ +804,5 @@
> +            currentRequest &&
> +            NS_SUCCEEDED(currentRequest->GetImageStatus(&imageStatus)) &&
> +            (imageStatus & imgIRequest::STATUS_ERROR);
> +        }
> +        // invalid image specified, make the image big enough for the "broken" icon

Replace the comma here with semicolon or a period, for improved grammar/readability.
Attachment #8757591 - Flags: review?(dholbert) → feedback+
(Thanks to Jet for keeping the ball rolling here, too! I'll transfer assignee back over to emk, since he's got the final patch here.)
Assignee: bugs → VYV03354
Attached patch patch v5 (obsolete) — Splinter Review
Fixed nits and added a mochitest.
Attachment #8757591 - Attachment is obsolete: true
Attachment #8757628 - Flags: review?(dholbert)
Status: NEW → ASSIGNED
Comment on attachment 8757628 [details] [diff] [review]
patch v5

Review of attachment 8757628 [details] [diff] [review]:
-----------------------------------------------------------------

Still needs a commit message; maybe something about "Only size <img> to broken-image size if it's actually broken"?

Anyway, r=me with a commit message & nits below addressed.

::: layout/generic/test/test_intrinsic_size_on_loading.html
@@ +3,5 @@
> +<!--
> +https://bugzilla.mozilla.org/show_bug.cgi?id=1205027
> +-->
> +<head>
> +  <title>Test for intrinsic size on loading</title>

s/for/for images'/

s/on loading/while loading/
...or even "while load is pending"

("on" is ambiguous -- it can be read to mean "after", but that's not at all what you want it to mean here.)

@@ +4,5 @@
> +https://bugzilla.mozilla.org/show_bug.cgi?id=1205027
> +-->
> +<head>
> +  <title>Test for intrinsic size on loading</title>
> +  <script type="text/javascript" src="/tests/SimpleTest/SimpleTest.js"></script>        

Drop end-of-line whitespace after </script>.

@@ +45,5 @@
> +  <script>
> +    initialOffsetTop = marker.offsetTop;
> +    var img = new Image();
> +    img.onerror = fail;
> +    img.src = "file_SlowImage.sjs?continue";

Please add a comment here, explaining what you're doing.  (I think this is to prompt the sjs "server" to proceed to serve data to our <img> elements, but that wasn't immediately obvious.)
Attachment #8757628 - Flags: review?(dholbert) → review+
Thanks for correcting my poor English :)
Attachment #8757628 - Attachment is obsolete: true
Attachment #8757662 - Flags: review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/17dcafc58287fb1f605ea6c396589f467aeff811
Bug 1205027 - Only size <img> to broken-image size if it's actually broken. r=dholbert
Backed out for wpt windows-1251.html permafail on Windows:

https://hg.mozilla.org/integration/mozilla-inbound/rev/ea07d83adaf4

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=17dcafc58287fb1f605ea6c396589f467aeff811
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=28981471&repo=mozilla-inbound

17:34:06     INFO - TEST-FAIL | /html/infrastructure/urls/resolving-urls/query-encoding/windows-1251.html | loading js <script> - assert_equals: expected "%3F" but got "%C3%A5"
17:34:06     INFO - onload/</elm.onload<@http://web-platform.test:8000/html/infrastructure/urls/resolving-urls/query-encoding/resources/resolve-url.js?encoding=windows-1251&pipe=sub:229:7
17:34:06     INFO - Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1398:20
17:34:06     INFO - Test.prototype.step_func_done/<@http://web-platform.test:8000/resources/testharness.js:1438:17
17:34:06     INFO - EventHandlerNonNull*onload/<@http://web-platform.test:8000/html/infrastructure/urls/resolving-urls/query-encoding/resources/resolve-url.js?encoding=windows-1251&pipe=sub:228:18
17:34:06     INFO - Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1398:20
17:34:06     INFO - async_test@http://web-platform.test:8000/resources/testharness.js:513:13
17:34:06     INFO - onload@http://web-platform.test:8000/html/infrastructure/urls/resolving-urls/query-encoding/resources/resolve-url.js?encoding=windows-1251&pipe=sub:224:3
17:34:06     INFO - EventHandlerNonNull*@http://web-platform.test:8000/html/infrastructure/urls/resolving-urls/query-encoding/resources/resolve-url.js?encoding=windows-1251&pipe=sub:2:1
17:34:06     INFO - TEST-TIMEOUT | /html/infrastructure/urls/resolving-urls/query-encoding/windows-1251.html | loading image <img src> - Test timed out
17:34:06     INFO - TEST-TIMEOUT | /html/infrastructure/urls/resolving-urls/query-encoding/windows-1251.html | loading image <embed src> - Test timed out
17:34:06     INFO - TEST-TIMEOUT | /html/infrastructure/urls/resolving-urls/query-encoding/windows-1251.html | loading image <object data> - Test timed out
17:34:06     INFO - TEST-TIMEOUT | /html/infrastructure/urls/resolving-urls/query-encoding/windows-1251.html | loading image <input src> - Test timed out
17:34:06     INFO - TEST-UNEXPECTED-TIMEOUT | /html/infrastructure/urls/resolving-urls/query-encoding/windows-1251.html | loading image <video poster> - Test timed out
Flags: needinfo?(VYV03354)
The test assumes that the default intrinsic width is 300. Do you know where did this value come from?
Flags: needinfo?(james)
This test polls while the image width is 300 or 0:
>      // <video poster> doesn't notify when the image is loaded so we need to poll :-(
>      var interval;
>      var check_video_width = function() {
>        var width = elm.offsetWidth;
>        if (width != 300 && width != 0) {
>          clearInterval(interval);
>          elm.onload();
>        }
>      }

Before this patch, this poll ended even before the image is loaded because our default intrinsic width is 24 (not 300). The test polls only for <video poster> as the comment suggests.
The image loading test timeouts for all other elements/attributes even before this patch:
https://dxr.mozilla.org/mozilla-central/rev/4d63dde701b47b8661ab7990f197b6b60e543839/testing/web-platform/meta/html/infrastructure/urls/resolving-urls/query-encoding/windows-1251.html.ini

I concluded that this patch did not introduce this timeout; this patch only exposed existing timeout (and a wpt bug). I'll re-land this patch with an appropriate test-manifest update once comment #105 is also resolved.
https://html.spec.whatwg.org/#concept-video-intrinsic-width

"The default object size is a width of 300 CSS pixels and a height of 150 CSS pixels."
Flags: needinfo?(james)
Tested on Nightly VYV03354@nifty.ne.jp release and bug is resolved. I'm waiting for final results.
(In reply to Masatoshi Kimura [:emk] from comment #110)
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=f29529833916
https://treeherder.mozilla.org/#/jobs?repo=try&revision=98a90bd9c6a6

If I changed the condition to |if (width != 300 && width != 24)|, win7 wpt2 timeouts without a patch and (expected) fails with a patch. This result supports my theory.
https://hg.mozilla.org/integration/mozilla-inbound/rev/4353662915021fe5da16a9df0bf4ab4efee426c5
Bug 1205027 - Only size <img> to broken-image size if it's actually broken. r=dholbert
I gave up and bumped the assertion count for now. It is almost impossible to debug without a local environment. Bug 1067022 had no useful information.
https://hg.mozilla.org/mozilla-central/rev/435366291502
Status: ASSIGNED → RESOLVED
Closed: 4 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Fixed in Nightly 50, Aurora 49. This is possible to fixed this in latest stable and beta?
I'd like to ride this on the train because this patch has an undetermined regression on OS X. Sorry for a little longer inconvenience.
Ok, thanks, updating the status flags accordingly
Depends on: 1322497
Depends on: 1326738
You need to log in before you can comment on or make changes to this bug.