1337753 - No new content displayed on the website.(Naver)

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P3)

Description

[lgbrowser5]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3; NetHelper70; CNS_UA; AD_LOGON=4C47452E4E4554; rv:11.0) like Gecko

Steps to reproduce:

Steps to reproduce:

1. Open Firefox app 
2. Go to http://m.news.naver.com/hotissue/main.nhn?sid1=103&cid=945553
3. Scroll down
4. When scroll end, nothing happens.





Actual results:

When scroll end , nothing happens.



Expected results:

Chrome Browser 
When scroll end , add more page.
This issue reproduce with PC and Mobile.

Comment 1

[Carmen Fat [:cfat] - Ecosystem QA]

Hello

I was able to reproduce the issue using Huawei Honor 5x (Android 5.1.1) on all versions of Firefox:
- latest Nightly build 54.0a1 (2017-02-08);
- latest Aurora build 53.0a2 (2017-02-08);
- Beta 52.0b4-build 1;
- Release 51.0.2.

After scrolling reaches bottom of the page, a loading animation sign is displayed, but there is no new content displayed on the website.
Also, when using Google Chrome, the page is loading and displaying new website content.
Note that I also tested with another website that loads content when scrolling down the page (www.9gag.com), but the behavior was the expected one: content was loaded and displayed properly.

Since this bug report is not related to Reader View component, I think that Graphics, Panning and Zooming is a more appropriate component for it.

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

I see the same issue on desktop Firefox with the URL. I bet this is tech evangelism

Comment 3

[Mike Taylor [:miketaylr]]

The code around here looks suspicious (but we're correctly identified as android).

http://static.news.naver.net/mnews/resources/20170125_142939/js/generated/hotissue.defendency.js

if (a.os().android && (a.os().version >= 4.4 || a.navigator().chrome)) {
            jindo.$Element(document.body).delegate("click", "a, .u_hssbt", jindo.$Fn(this._linkClickEventHandler, this).bind());
            this._oPersist = new Persist();
            var g = this._oPersist.persist();
            if (g) {
                this._welPersistContent.html(g.list).show();
                this._nPage = g.page;
                this._oLastArticle = g.lastArticle;
                if (g.photoAreaHeight > 0) {
                    this._oData.oMasonry._oMasonry._welContainer = $Element($$.getSingle(".photo_wall .photo_inr"));
                    this._oData.oMasonry._elContainer = $$.getSingle(".photo_wall .photo_inr")
                }
                var d = function() {
                    window.scrollTo(0, g.scrollTop);
                    document.body.scrollTop === g.scrollTop && clearInterval(b)
                }
                  , b = setInterval(d, 25);
                h = true
            }
        }


Let's move to TE speculatively.

Tom, can you take a closer look?

Comment 4

[Thomas Wisniewski]

It turns out that it's not related to UA-sniffing, but rather this function in http://static.news.naver.net/mnews/resources/20170209_150315/js/generated/default.dependency.js:
>isExistInViewportHeight: function(e) {
>    var b = jindo.$Element(e);
>    var f = document.documentElement.scrollTop || document.body.scrollTop;
>    var d = window.innerHeight;
>    var c = b.offset().top,
>        a = b.height();
>    if (c + a >= f && c <= f + d) {
>        return true
>    }
>    return false 
>},

The problem is that Firefox doesn't track document.body.scrollTop, but document.documentElement.scrollTop. Other browsers including Safari, Chrome and Edge seem to all be tracking the value on body rather than documentElement, so maybe this is something we should finally standardize.

In the meantime, the site can easily fix this by changing all the places in their files where they only read one value but not the other (funny enough they're inconsistently accounting for this in some places, but not others). Fixing the above function, for instance, would just require changing that one line to:

>    var f = document.documentElement.scrollTop || document.body.scrollTop;

But there are quite a few other spots in just this script where they read the scroll position, so their devs should be mindful of this in future changes (and maybe call a common function rather than writing out the above everywhere).

Comment 5

[Mike Taylor [:miketaylr]]

There's also document.scrollingElement, in newer browsers: https://developer.mozilla.org/en-US/docs/Web/API/Document/scrollingElement

Comment 6

[Thomas Wisniewski]

Just clearing the ni? since I forgot to do so last time (sorry for the bugspam).

Comment 7

[Mike Kaply [:mkaply]]

> Other browsers including Safari, Chrome and Edge seem to all be tracking the value on body rather than documentElement, so maybe this is something we should finally standardize.

Is there a separate bug for this?

Comment 8

[Mike Taylor [:miketaylr]]

(In reply to Mike Kaply [:mkaply] from comment #7)
> > Other browsers including Safari, Chrome and Edge seem to all be tracking the value on body rather than documentElement, so maybe this is something we should finally standardize.
> 
> Is there a separate bug for this?

This is already taken care of via scrollingElement (to solve this very problem). See link in Comment #5.

Comment 9

[Mike Kaply [:mkaply]]

> This is already taken care of via scrollingElement (to solve this very problem). See link in Comment #5.

sorry, I misread. When you said "standardize" I thought you meant implementing their behavior in Firefox.

Is this a case where we should have the other browsers behavior in Firefox?

Comment 10

[Mike Taylor [:miketaylr]]

No, that would probably break as many sites as it fixed. There's a ton of code that's like this in the wild:

if (Firefox) {
// do the thing the spec says
} else {
// do the non-standard WebKit thing
}

Personally, I would ignore the comment about standardization (Tom forgot about scrollingElement, and Firefox's behavior is what the relevant standards define) -- the future-friendly standards-based solution to this problem is document.scrollingElement.

Comment 11

[Mike Kaply [:mkaply]]

I have attempted to contact them here:

https://m.help.naver.com/support/issue/report.nhn?serviceNo=5603

Comment 12

[Adam Stevenson [:adamopenweb]]

Thanks Mike! Setting status to sitewait.

Comment 13

[Julien Cristau [:jcristau]]

Too late for firefox 52, mass-wontfix.

Comment 14

[Mike Taylor [:miketaylr]]

Hi, does this still reproduce?

Comment 15

[Mike Kaply [:mkaply]]

I can't reproduce this anymore.