Web compatibility issue in bricklink.com with "at" method name

[Constellation]

We enabled at method of Array in ToT WebKit, and encountered web compatibility issue in bricklink.com.
The website includes

            var at = blUtil.getHashVar("at");

            if (at)
            {
                var trigger = JSON.parse(blUtil.decodeURLSafeB64(at));

        getVarsFromHashString:
        function(strHash)
        {
            var vars = [],
                hash;
            var hashes = strHash.slice(strHash.indexOf('#') + 1).split('&');
            for (var i = 0; i < hashes.length; i++)
            {
                hash = hashes[i].split('=');
                vars.push(hash[0]);
                vars[hash[0]] = this.decodeURL(hash[1]);
            }
            return vars;
        }
...
        getHashVars: function()
        {
            return $.getVarsFromHashString(window.location.href);
        }
...
        getHashVar: function(name)
        {
            return $.getHashVars()[name];
        }

It attempted to extract at hash value from window.location.href, and it is using array to construct hash table.
Previously, at returns undefined (if at hash value does not exist) or string (if at hash value exists). But now, it returns function, and getting a wrong code path.

This website does not work with STP 118 and Chrome Canary.

Since at is still common name, I wonder if we need to pick itemAt instead.

[Constellation]

ref #34

[ljharb]

Is this the only website this occurs in? Is it possible to contact them and get them to update their code?

[MaxGraey]

Since at is still common name, I wonder if we need to pick itemAt instead.

itemAt already used in pretty popular in 2012 sencha's ExtJS:
https://forum.sencha.com/forum/showthread.php?244131-Extjs4-this-items-itemAt-is-not-a-function

[syg]

Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1170196

I'll reach out to them and see if they can update their site.

@Constellation Is that code library code or application code? It doesn't read like library code to me, so if they fix it we might be able to stick with at.

Edit: Given that code is on an object name blUtil, which I assume stands for "Bricklink util", I'm going to say this is application code.

[syg]

I've filed a bug on Bricklink via https://www.bricklink.com/helpDesk.asp?helpDeskID=114. I'll keep folks updated on this thread.

[Constellation]

@syg This part is not library/framework code. We are also scheduling evangelist outreach.
As linked to this GitHub issue via GitHub cross-linking, we disabled this for now in WebKit/WebKit@631cd20

@apple-web-evangelist can you share information?

[syg]

Update: I've filed two bugs against bricklink.com and have not yet heard back.

[syg]

Update again: Bricklink's ticket system shows my tickets as "Closed" without any replies. I'll try to escalate, but not sure how yet.

[evilpie]

I am going to remove at from Firefox Nightly now.

[syg]

I am going to remove at from Firefox Nightly now.

Hold on, it seems like the repeated tickets did finally get routed to the engineering staff. They replied:

As an update:
we're working on it and will be solved soon.
We have to implement some new features that right now cause some incompatibility.

[evilpie]

Nice! I am going to wait if a resolution is imminent.

[codehag]

Hey folks, Pinging here to learn if there was any resolution?

[syg]

I've confirmed with Chrome (when passing --js-flags=--harmony-relative-indexing-methods) that the search function on bricklink.com works again. I will try to ship again soon.

[evilpie]

@syg Have you tried shipping since?

[syg]

Yes indeed: https://chromium.googlesource.com/v8/v8.git/+/6ac4d69eef83e087abd96f090db6ac74a7fb8038, first stable version will be 92 (if things go well).

[evilpie]

Awesome! Hopefully it will be shipping in Firefox 90 as well: https://bugzilla.mozilla.org/show_bug.cgi?id=1681371

[towerofnix]

Firefox 90 has shipped, including support for .at()!

Chrome 92 will be shipping just a week later on the 20th, and also supports.at()!