958415 - ameba.jp shows blank page when browsing Firefox Android

Status: RESOLVED FIXED

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

Description

[Makoto Kato [:m_kato]]

Site: http://www.ameba.jp/
ameba.jp shows blank page when browsing Firefox Android

:: Steps To Reproduce

1. Browser http://www.ameba.jp/ using Firefox Android


:: Expected Result

Firefox shows blank page even if page is loaded

:: Actual Result

redering page

:: Additional Information

Software Version: 26
Device Information: Xpedia X1
Reporter's User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:29.0) Gecko/20100101 Firefox/29.0

Comment 1

[Mike Taylor [:miketaylr]]

The main js error: InvalidAccessError: A parameter or an operation is not supported by the underlying object, which looks like 761236. So there's a callback firing too early, before the CSS has actually been parsed.

It looks like chikuwa.js's $.load function was created before Gecko (and WebKit) had support for a load event on link elements: https://github.com/ameba-proteus/chikuwa.js/blob/master/chikuwa.js#L1052-L1131, and is buggy--the callback here is firing too early:

$.load(o, function () {
  i(o); //<-- fires too early
  r(window)
})

So, I rewrote T.load (the minified version) to look like https://gist.github.com/miketaylr/8410334 and the site loads just fine.

Once that's fixed, it's just a matter of fixing the CSS layout issues, which at a quick glance are due to missing unprefixed (or moz-prefixed) styles.

Hallvord, can you run this through compatipede to get a complete list of the webkit CSS issues?

Comment 2

[Karl Dubost💡 :karlcow]

It seems the library of Ameba is online at Github.
https://github.com/ameba-proteus/chikuwa.js

And they have 5 members
https://github.com/ameba-proteus?tab=members

Comment 3

[Hallvord R. M. Steen [:hallvors]]

Attachment: ameba.json - issues found during last test run on Japanese sites

Comment 4

[Mike Taylor [:miketaylr]]

I'd like to better understand the issue with chikuwa.js so we can propose a patch to that lib before reaching out to this site for the CSS issues.

Comment 5

[Hallvord R. M. Steen [:hallvors]]

(BTW Firefox OS gets a desktop page - which at least shows up ;-))

Comment 6

[Mike Taylor [:miketaylr]]

OK. Finally figured this out.

The bug is in checkCssLoaded, specifically here: https://github.com/ameba-proteus/chikuwa.js/blob/master/chikuwa.js#L1065-L1076

The codebase is assuming this condition evaluating to true means the CSS is loaded:
  if (styleSheet.ownerNode.getAttribute('href') === url) {

However, that's only true for WebKit based browsers, in my tests.

See http://dhtml5.com/tmp/stylesheets-length.html

This testcase injects a slow CSS files (takes 1 second to load) and logs document.styleSheets.length and document.styleSheets[0].ownerNode.href.

Opera Presto, Firefox, Internet Explorer: immediately update document.styleSheets collection
Chrome, Safari: update document.styleSheets collection after load event of stylesheet.

As a result of the false positive, the script fires the callback too early (which is throwing the error mentioned in Comment 1 because that particular callback is looping through cssRules in order to set the correct DPR of background images, and well, there are no rules yet). 

Obviously this code was written before more than IE had <link>.onload, so I think it's pretty safe to just replace the buggy code with a proper load event, especially given the fact that this is a mobile site. I can file a bug on chikuwa.js (and offer a patch too).

Comment 7

[Mike Taylor [:miketaylr]]

Filed https://github.com/ameba-proteus/chikuwa.js/issues/1.

Comment 8

[Karl Dubost💡 :karlcow]

pinged the code owner on github.

Comment 9

[Karl Dubost💡 :karlcow]

As of today, tested and still not fixed both the site and the library.

Comment 10

[Karl Dubost💡 :karlcow]

NOT fixed by layout.css.prefixes.webkit
to test what Edge is doing now.

Comment 11

[Mike Taylor [:miketaylr]]

Both Edge and IE10 Mobile behave the same as Firefox, wrt the test case from Comment 6. But, the page *does* load in IE10 Mobile. So either the page changed in some way, or my analysis of the cause of the bug was incorrect.

Moving back to needsdiagnosis.

(It seems pretty clear that the project on GitHub is DOA...)

Comment 12

[Karl Dubost💡 :karlcow]

When using Firefox Android.
We are redirected to https://s.amebame.com/
It downloads all.js and then main.css
and stops everything it doesn't go further. 

Whatever happens it happens very quickly.

The console displays:

"InvalidAccessError: A parameter or an operation is not supported by the underlying object" 
in https://s.amebame.com/201602091421/js/all.js

btw one of their scripts has a beautiful typo: Andorid

    $.os.version = function() {
        var e = (navigator.userAgent.match(/(OS|Andorid) ([0-9_\.]+)/) || []).pop();
        if (!e) return 0;
        var t = e.replace(/_/g, ".").split(".");
        var n = (t[0] || "0") + (t[1] || "0").slice(0, 1) + (t[2] || "0").slice(0, 1);
        return n
    }();



In the document head:

First script to redirect to https, no issue.

    <script>if (location.protocol === 'http:') {
             var url = 'https://' + location.host + location.pathname + location.search + location.hash;
             location.replace(url);
             }</script>

Then loading all.js

     <script type="text/javascript" src="/201602091421/js/all.js"></script>

Then setting a version number:

     <script>$.version = '201602091421';</script>

Then the meaty part.

    require.config({
        baseUrl: ($.version ? ('/' + $.version) : '') + '/js/module'
    });

    $.setLogLevel('WARN');
    $.urls = {
        api: 'https://api.amebame.com',
        stat: 'https://ssl-stat.amebame.com',
        ustat: 'https://ssl-ustat.amebame.com',
        content: 'http://content.amebame.com',
        graph: 'https://api.amebame.com/graph',
        tracking: 'https://track.amebame.com/track/log',
        user: 'https://user.ameba.jp/',
        blog: 'http://s.ameblo.jp/',
        profile: 'http://profile.ameba.jp/',
        now: 'http://now.ameba.jp/',
        groupo: 'http://group.ameba.jp/',
        peta: 'http://peta.ameba.jp/',
        amember: 'http://amember.ameba.jp/',
        pigg: 'http://s.pigg.ameba.jp',
        fresh: 'https://amebafresh.tv/',
        sync: 'https://sy.ameblo.jp/sync/?org=sy.amebame.com',
        amebaTopics: 'http://ametopi.jp',
        amoad: {
            home_r: '//j.amoad.com/js/r_deca.js'
        },
        amebajp: 'http://www.ameba.jp',
        sslAmeba: 'https://ssl.ameba.jp',
        bdd: 'https://ss.ameba-ad.com',
        point: 'https://d-money.jp/',
        accounts: 'https://accounts.user.ameba.jp'
    };

    $.appId = {
        home: '934',
        operation: '932',
        pigg: '9409332',
        dokusho: '5543072250',
        amatus: '6951760968'
    };
    $.os.iosCaAppPending = false;


Then finally the CSS.

    <link href="/201602091421/css/main.css" type="text/css" rel="stylesheet"></head>

And nothing more goes after this. The body gets empty with a class.

    <body class="android"></body>


In the list of URLs I see that some of them are under https and some under http such as

        content: 'http://content.amebame.com',

I wonder if it's why it's bailing out.

Comment 13

[Karl Dubost💡 :karlcow]

Not the same site but the same company https://webcompat.com/issues/926

Comment 14

[Hallvord R. M. Steen [:hallvors]]

(In reply to Mike Taylor [:miketaylr] from comment #11)
> Both Edge and IE10 Mobile behave the same as Firefox, wrt the test case from
> Comment 6. But, the page *does* load in IE10 Mobile. So either the page
> changed in some way, or my analysis of the cause of the bug was incorrect.

Or your analysis is perfect but they have a workaround for IE10 somewhere..? :)
Still the same issue. I see the site loading just fine if I add this:

                n.on('load', function(){this.loaded=true;});

to the code that creates the LINK element and add a loaded check to the if clause checking the href of the node:

                if (c.ownerNode.getAttribute("href") === t && c.ownerNode.loaded) {

However, I think we should not contact Ameba again until we've checked how this is / should be spec'ed and done something to make browsers align on one behaviour. It's just silly to have small incompatibilities like this around. This site "votes for" the Chrome way, so perhaps that's what we should spec?

Comment 15

[Hallvord R. M. Steen [:hallvors]]

Needinfoing Anne vK and Boris for comments on the state of specs and whether it's hard to change Gecko.. TIA :)

Comment 16

[Boris Zbarsky [:bzbarsky]]

Changing Gecko might not be too bad if all we're trying to affect is document.styleSheets and maybe node.sheet.  I'd be somewhat worried about compat fallout, though, and node.sheet would need testing.

As for the specs, I can't tell what they're saying to do here, because I can't tell whether the "Once a resource has been obtained" wording in https://html.spec.whatwg.org/multipage/semantics.html#link-type-stylesheet means once the steps in https://html.spec.whatwg.org/multipage/semantics.html#concept-link-obtain complete or once the fetch completes....

Comment 17

[Anne (:annevk)]

Simon is in charge of document.styleSheets. Simon, as far as I can tell from reading this bug the question is about defining more exactly when document.styleSheets is updated. Apparently this differs per browser.

Comment 18

[Simon Pieters [:zcorpan]]

I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=29464 to track this for the CSSOM spec.

Comment 19

[Mike Taylor [:miketaylr]]

I still think Comment #6 is the cause, after taking another look.

Comment 20

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

Makoto-san called me as an employee of CyberAgent, Inc.

With the employee’s hat, I don’t have any work related to abema.jp directly, but I heard summaries of the current status from them:

* We don’t have any active owners for chikuwa.js (https://github.com/ameba-proteus/chikuwa.js).
  * Suguru-san, who Karl tried to contact at https://github.com/ameba-proteus/chikuwa.js/issues/1, has been left from CyberAgent.
* We cannot upgrade chikuwa.js on ameba.jp immediately because its internal branch is pretty different from the open sourced code.
* We’re working to replace the part using chikuwa.js with more standard ways. When we finished its work, this compat issue would be fixed.

We apologize for that we didn’t have any response about this bug.

Comment 21

[Karl Dubost💡 :karlcow]

Thanks a lot for the update Ohzeki-san.

Comment 23

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 24

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 25

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 26

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 27

[Dennis Schubert [:denschub]]

This appears to be fixed now, wohoo!