Closed
Bug 958415
Opened 11 years ago
Closed 3 years ago
ameba.jp shows blank page when browsing Firefox Android
Categories
(Web Compatibility :: Site Reports, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: m_kato, Unassigned)
References
()
Details
(Whiteboard: [mobile-compat-form][country-jp][webkitcss])
Attachments
(1 file)
62.65 KB,
application/json
|
Details |
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
Reporter | ||
Updated•11 years ago
|
Whiteboard: [mobile-compat-form] → [mobile-compat-form][country-jp]
Comment 1•11 years ago
|
||
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [mobile-compat-form][country-jp] → [mobile-compat-form][country-jp][webkitcss]
![]() |
||
Comment 2•11 years ago
|
||
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•11 years ago
|
||
Flags: needinfo?(hsteen)
Comment 4•11 years ago
|
||
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.
Whiteboard: [mobile-compat-form][country-jp][webkitcss] → [mobile-compat-form][country-jp][webkitcss][notcontactready]
Updated•11 years ago
|
Assignee: nobody → miket
Comment 5•11 years ago
|
||
(BTW Firefox OS gets a desktop page - which at least shows up ;-))
![]() |
||
Updated•11 years ago
|
Status: NEW → ASSIGNED
Comment 6•11 years ago
|
||
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•11 years ago
|
||
contact github |
Filed https://github.com/ameba-proteus/chikuwa.js/issues/1.
Updated•11 years ago
|
Whiteboard: [mobile-compat-form][country-jp][webkitcss][notcontactready] → [mobile-compat-form][country-jp][webkitcss][sitewait]
Updated•11 years ago
|
Assignee: miket → nobody
![]() |
||
Comment 8•10 years ago
|
||
contact github |
pinged the code owner on github.
![]() |
||
Comment 9•9 years ago
|
||
As of today, tested and still not fixed both the site and the library.
![]() |
||
Comment 10•9 years ago
|
||
NOT fixed by layout.css.prefixes.webkit to test what Edge is doing now.
Flags: needinfo?(miket)
Comment 11•9 years ago
|
||
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...)
Flags: needinfo?(miket)
Whiteboard: [mobile-compat-form][country-jp][webkitcss][sitewait] → [mobile-compat-form][country-jp][webkitcss][needsdiagnosis]
![]() |
||
Comment 12•9 years ago
|
||
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•9 years ago
|
||
Not the same site but the same company https://webcompat.com/issues/926
Comment 14•9 years ago
|
||
(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•9 years ago
|
||
Needinfoing Anne vK and Boris for comments on the state of specs and whether it's hard to change Gecko.. TIA :)
Flags: needinfo?(bzbarsky)
Flags: needinfo?(annevk)
![]() |
||
Comment 16•9 years ago
|
||
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....
Flags: needinfo?(bzbarsky)
Comment 17•9 years ago
|
||
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.
Flags: needinfo?(annevk) → needinfo?(zcorpan)
Comment 18•9 years ago
|
||
I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=29464 to track this for the CSSOM spec.
Flags: needinfo?(zcorpan)
![]() |
||
Updated•8 years ago
|
See Also: → https://webcompat.com/issues/2441
Comment 19•8 years ago
|
||
I still think Comment #6 is the cause, after taking another look.
Whiteboard: [mobile-compat-form][country-jp][webkitcss][needsdiagnosis] → [mobile-compat-form][country-jp][webkitcss][needscontact]
Comment 20•7 years ago
|
||
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•7 years ago
|
||
Thanks a lot for the update Ohzeki-san.
Updated•7 years ago
|
Priority: -- → P3
![]() |
||
Updated•6 years ago
|
See Also: → https://webcompat.com/issues/9767
Updated•6 years ago
|
Whiteboard: [mobile-compat-form][country-jp][webkitcss][needscontact] → [mobile-compat-form][country-jp][webkitcss][sitewait]
Comment 24•6 years ago
|
||
noise |
No assignee, updating the status.
Comment 25•6 years ago
|
||
noise |
No assignee, updating the status.
Assignee | ||
Updated•6 years ago
|
Product: Tech Evangelism → Web Compatibility
Comment 26•5 years ago
|
||
See bug 1547409. Moving webcompat whiteboard tags to keywords.
Keywords: webcompat:site-wait
Comment 27•3 years ago
|
||
This appears to be fixed now, wohoo!
Status: NEW → RESOLVED
Closed: 3 years ago
Keywords: webcompat:site-wait
Resolution: --- → FIXED
Whiteboard: [mobile-compat-form][country-jp][webkitcss][sitewait] → [mobile-compat-form][country-jp][webkitcss]
Assignee | ||
Updated•6 months ago
|
Component: Mobile → Site Reports
You need to log in
before you can comment on or make changes to this bug.
Description
•