1326392 - Unable to log in on starbucks.com

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Ioana Chiorean]

I am unable to log into Starbucks.com from Firefox Nightly on Linux ( tested with clean profile too) 
I am ok login in from Chrome. 

I am only getting this in the console:
TypeError: Not allowed to define a non-configurable property on the WindowProxy object

Comment 1

[Mike Taylor [:miketaylr]]

Hmm, I'm unable to login in DevEdition on Mac as well (but I don't get that same error).

Comment 2

[Mike Taylor [:miketaylr]]

Ah, I do get that error (after disabling uBlock):

TypeError: Not allowed to define a non-configurable property on the WindowProxy object  signin:12:4067
  bound call self-hosted:919:17
  cC https://www.starbucks.com/account/signin:12:4067
  hX https://www.starbucks.com/account/signin:12:20349
  hJ/< https://www.starbucks.com/account/signin:12:20097
  bound call self-hosted:919:17
  bD</< https://www.starbucks.com/account/signin:12:2945
  eJ https://www.starbucks.com/account/signin:12:8405
  hX https://www.starbucks.com/account/signin:12:20349
  hJ/< https://www.starbucks.com/account/signin:12:20097
  bound call self-hosted:919:17
  anonymous/< https://www.starbucks.com/account/signin%20line%2012%20%3E%20Function:1:81
  <anonymous> https://www.starbucks.com/account/signin:13:2

Comment 3

[Mike Taylor [:miketaylr]]

mozregresion explodes when trying to grab a taskcluster build, so this is as far as I got: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1f77b78797d6&tochange=b0b3dcfa5557

Comment 4

[Mike Taylor [:miketaylr]]

But, https://hg.mozilla.org/mozilla-central/rev/e12159b9f891 is in there (Bug 1107443), which is what added the WindowProxy TypeError so seems like a safe guess.

Comment 5

[Mike Taylor [:miketaylr]]

unminified script that is throwing here: https://gist.github.com/miketaylr/db1808426aa694e9bfed00aa566c2eea

Comment 6

[Mike Taylor [:miketaylr]]

So the gist of Bug 1107443 is that (for now) it shouldn't throw in Release or Beta, but ideally we can pin down the exact bug and ask Starbucks to fix it.

Comment 7

[Mike Taylor [:miketaylr]]

They have two functions r and d that call Object.defineProperty without passing `configurable:true`. So if window gets the property in either of these fns, it would throw (`configurable:false` being the default).

function d(t, e) {
    if (Object.defineProperty && Object.keys) try {
        var n = Object.keys(t);
        return n.forEach(function(n) {
            Object.defineProperty(e, n, {
                get: function() {
                    return t[n]
                },
                set: function(e) {
                    return t[n] = e, e
                }
            })
        }), e
    } catch (r) {
        l([r])
    }
    for (var o in t) c.call(t, o) && (e[o] = t[o]);
    return e
}

function r(t, e, n) {
    if (o.call(t, e)) return t[e];
    var r = n();
    if (Object.defineProperty && Object.keys) try {
        return Object.defineProperty(t, e, {
            value: r,
            writable: !0,
            enumerable: !1
        }), r
    } catch (i) {}
    return t[e] = r, r
}

Boris, do we know if others browsers want to implement this behavior (soon)? Or, do you know who might know?

Comment 8

[Boris Zbarsky [:bzbarsky]]

> So if window gets the property in either of these fns, it would throw (`configurable:false` being the default).

The default is actually "whatever the current configurability is", not "false", and the code we have doesn't throw unless you _explicitly_ specify false.  So the page is doing that somewhere.  I haven't found where yet, but they're calling Object.defineProperty via .call() as far as I can tell, not directly.  The only thing I've found about it so far is that it's using "uniqueStateKey" as the property name.  Probably part of this:

        bundle.init("uniqueStateKey", 30, null, null, [{
...
                     "uniqueStateKey", "uniqueStateKey", "uniqueStateKey", 100, "AFebLlFZAQAALG3Ncz-XbvW4UAHkso5yg40nZw8ROEH1jovbUATjKjnL1jnJ", "X-", 79e2, "cookieName")

but I'm not sure where bundle.init is coming from...

In any case, the answer to your actual question is in bug 1178638 and it's that no one will talk to me.  We should probably accept that the ES spec is busted, stop caring about trying to fix it, and turn off these checks on nightly as well.

Comment 9

[Mike Taylor [:miketaylr]]

Ah, thanks. My mistake.

Debugging minified JS in our current devtools is basically impossible... :/ and I'm not sure it's worth doing the whole MITM dance since this issue affects other sites. If there were strong signals that Chrome was about to make this same change, I'd say we dig in further and ask Starbucks to fix it... but yeah.

Comment 10

[Mike Taylor [:miketaylr]]

Ioana, this should work in tomorrow's nightly -- can you test and close if so? Thanks!

Comment 11

[Ioana Chiorean]

Works like magic! Thanks guys!