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

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I will actually quickly run a mozregression session. Should have the causing changeset soon.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 3

[Tooru Fujisawa [:arai]]

I'll check the code there to see what part is causing this.

Comment 4

[Tooru Fujisawa [:arai]]

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.

Comment 5

[Tooru Fujisawa [:arai]]

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.

Comment 6

[Julien Cristau [:jcristau] (back on 2026-01-06)]

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?

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

This needs the behavior which makes the bug mentioned in that comment fixed. Please direct questions about that to Jason.

Comment 8

[Jason Orendorff [:jorendorff]]

We're doing an eleventh-hour backout; see bug 1498257.

Comment 9

[Julien Cristau [:jcristau] (back on 2026-01-06)]

Fixed by backout for 64:
https://hg.mozilla.org/releases/mozilla-release/rev/290d09651022f524b7bcc5a5514dc616f93fe89a

Comment 10

[Ryan VanderMeulen [:RyanVM]]

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

Comment 11

[Timea Cernea [:tbabos][inactive]]

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.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Yes it works fine with all of the versions now.

Comment 13

[Timea Cernea [:tbabos][inactive]]

Thanks Henrik!

Based on Comment 11 and Comment 12, will mark this issue Verified - Fixed.

Comment 14

[Firefox Bug Husbandry Bot]

Please specify a root cause for this bug. See :tmaity for more information.