Loading https://shop.lego.com with Firefox 64beta only shows a white page

VERIFIED FIXED in Firefox 64

Status

()

defect
VERIFIED FIXED
6 months ago
6 months ago

People

(Reporter: whimboo, Assigned: jorendorff)

Tracking

(Blocks 1 bug, {regression})

64 Branch
mozilla66
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox63 unaffected, firefox64blocking verified, firefox65blocking verified, firefox66blocking verified)

Details

()

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:65.0) Gecko/20100101 Firefox/65.0 ID:20181202215653

When visiting the Lego shop with a recent Firefox 64 beta build content is shown only for a split of a second, and then only a white page is visible. Loading the shop with the last Firefox 63 release it works fine.

It would be great to get a regression range. Sadly I don't have the time to do that right now.

Also not sure how severe this problem is. As such asking for blocking the 64 release for now.
I will actually quickly run a mozregression session. Should have the causing changeset soon.
13:43.12 INFO: No more inbound revisions, bisection finished.
13:43.12 INFO: Last good revision: 5d6bf0312e088bb2424a8177589a9fd4aa44bfa8
13:43.12 INFO: First bad revision: f0c6e521429cfaff0585ec6eaf734e9fcf873f8a
13:43.12 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5d6bf0312e088bb2424a8177589a9fd4aa44bfa8&tochange=f0c6e521429cfaff0585ec6eaf734e9fcf873f8a

That means it is a regression from bug 1259822. What I wonder is that the patch on this bug got backed out for Firefox 63 and 64 beta, but not 65, and that it fails for me for all 64 beta and also Nightly. So it looks like there are still webcompat issues around.
Blocks: 1259822
Component: General → JavaScript Engine
Flags: needinfo?(jorendorff)
Product: Firefox → Core
I'll check the code there to see what part is causing this.
Flags: needinfo?(arai.unmht)
This should be again idx library, the same issue as bug 1498257.
  https://github.com/facebookincubator/idx/blob/master/packages/idx/src/idx.js

Here's the prettified code with (fake) line numbers, from the website.

https://shop.lego.com/_build/579a9c26a8ca21271abd.main.js~30083325.js
>    1: (window.webpackJsonp = window.webpackJsonp || []).push([
>    2:     [51], {
> ...
> 1979:         ShFV: function(e, n, t) {
> 1980:             "use strict";
> ...
> 2003:                 v = function(e) {
> 2004:                     function n(n) {
> 2005:                         var t;
> 2006:                         t = e.call(this, n) || this;
> 2007:                         var r = !!l()(Object(f.e)(), function(e) {
> 2008:                                 return e.functional
> 2009:                             }),
> 2010:                             a = Object(p.d)(),
> 2011:                             i = Object(p.c)(r);
> ...

in line 2008 there, `e` is null, and the property access fails.


https://shop.lego.com/_build/c6a843a2414c6086ec61.vendor~7d359b94.js
>    1: (window.webpackJsonp = window.webpackJsonp || []).push([
>    2:     [14], {
> ...
>  299:         UVUI: function(t, e, n) {
>  300:             "use strict";
>  301:
>  302:             function r(t, e) {
>  303:                 try {
>  304:                     return e(t)
>  305:                 } catch (t) {
>  306:                     if (t instanceof TypeError) {
>  307:                         if (o.test(t)) return null;
>  308:                         if (i.test(t)) return
>  309:                     }
>  310:                     throw t
>  311:                 }
>  312:             }
>  313:             var o = /^null | null$|^[^(]* null /i,
>  314:                 i = /^undefined | undefined$|^[^(]* undefined /i;
>  315:             r.default = r, t.exports = r
>  316:         },

and the caller is `e(t)` in line 304 there.
and inside the catch clause, it's checking the error message.
the pattern only matches to the message before the improvement.
Flags: needinfo?(arai.unmht)
See Also: → 1498257
To be clear, the error message of the error thrown there is:
  TypeError: e is null; can't access its "functional" property

which doesn't match the pattern in line 313 above.

and the previous message is
  TypeError: e is null

which matches.
So this was supposed to be backed out of 64, but the backout was backed out in https://bugzilla.mozilla.org/show_bug.cgi?id=1259822#c25?
Flags: needinfo?(aryx.bugmail)
This needs the behavior which makes the bug mentioned in that comment fixed. Please direct questions about that to Jason.
Flags: needinfo?(aryx.bugmail)
Assignee

Comment 8

6 months ago
We're doing an eleventh-hour backout; see bug 1498257.
Flags: needinfo?(jorendorff)
This was backed out from 65 & 66 as well.
https://hg.mozilla.org/releases/mozilla-beta/rev/5cfb828cce2d
https://hg.mozilla.org/integration/mozilla-inbound/rev/8fc0458ea017
Assignee: nobody → jorendorff
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Flags: qe-verify+

Comment 11

6 months ago
Verified - Fixed on latest Nightly 66.0a1 (2018-12-10), Beta 65.0b3 (64-bit) and Release 64.0 (64-bit) on Windows 10, Mac OS 10.14 and Ubuntu 16.04.

Shop.lego.com site is loading without any issues on my end on the mentioned versions. However, I couldn't reproduce it on the affected Beta version (b10, b13) neither on Nightly versions back to August.

Given that I could not NI? Henrik to verify this, Tooru can you please give it a look? Just want to be sure it is indeed fixed.
Flags: needinfo?(arai.unmht)
Yes it works fine with all of the versions now.

Comment 13

6 months ago
Thanks Henrik!

Based on Comment 11 and Comment 12, will mark this issue Verified - Fixed.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.