1957422 - Lidl LiA Assistant - Support chat does not load completely, unable to send messages

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect, P2)

Description

[Calin Tanase]

Environment:
Operating system: Android 13/Windows 10
Firefox version: Firefox 136.0/138

Steps to reproduce:

1. Go to https://assistenza-clienti.lidl.it/SelfServiceIT/s/?initChatbot=true
2. Click on "CONTINUA" inside the chat window.
3. Type something and try to send the message.

Expected Behavior:
The chat window loads completely and the messages can be sent.

Actual Behavior:
The chat windows does not load completely and the messages cannot be sent.

Notes:

• Reproduces on both Mobile and Desktop
• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/150440

Comment 1

[Calin Tanase]

Attachment: image.png

Comment 2

[Edgar Chen [:edgar]]

I can also reproduce this.

Comment 3

[Sean Feng [:sefeng211]]

I confirmed that the site indeed used .innerHTML to set these content. Searching se.createHTML(e) in devtools and setting a breakpoint for that case bh.HTML branch can be hit in both Chrome and Firefox.

It's noticeable that Chrome hits this more times than Firefox, with extra contents. Hard to tell why though...

Thanks Edgar!

Comment 4

[Edgar Chen [:edgar]]

I tried to compare how elements are generated under <div id="sit-chat-widget" class="scw-chat-widget">, but I haven’t been able to figure out why the site isn’t generating some of the content on Firefox. And the chat remains non-functional, for example, I can’t send messages, I haven’t figured out what’s missing that causes it to fail. Site uses webcomponent library (LWC) which make it hard to follow.

Comment 5

[Keith Cirkel [:keithamus]]

Indeed this is difficult to debug due to salesforce code. I'm fairly sure it's using near-membrane (https://github.com/salesforce/near-membrane) which aims to sandbox code via iframes (a pseudo implementation of the proposed ShadowRealms feature). This means debugging on the main window is likely going to come up empty.

The textarea has input event listeners which seem to trigger a mutation to add scw-active on the send button (<div class=scw-btn scw-btn-send>) which doesn't happen in Firefox but does in Chrome. Putting a break point on dom mutations for the button gets us to code that mentions foreignTargetPointer & distortionCallback - (helping confirm it might be using near-membrane, see for e.g. https://github.com/salesforce/near-membrane/blob/3b4fdf15ba636108be8fbba8c5f46d7f2973a1d0/packages/near-membrane-base/src/membrane.ts#L944).

So instead searching for scw-active gets us the component code for chat-widget.min.js (https://assistenza-clienti.lidl.it/SelfServiceIT/resource/1743369242000/CCC_VCA_4_10_3/chat-widget.min.js). A few references that look a little promising, like this block of code:

            c() {
                (e = v("div")), (n = v("div"));
                for (let t = 0; t < H.length; t += 1) H[t].c();
                (i = b()),
                    (s = v("footer")),
                    (c = v("input")),
                    (o = b()),
                    (l = v("div")),
                    (a = b()),
                    (u = v("section")),
                    ot(d.$$.fragment),
                    (p = b()),
                    R && R.c(),
                    ($ = b()),
                    (y = v("section")),
                    _ && _.c(),
                    (T = b()),
                    (C = v("div")),
                    L(n, "class", "scw-messages"),
                    L(c, "type", "file"),
                    L(c, "class", "scw-native-upload"),
                    L(c, "accept", ""),
                    L(l, "class", "scw-btn-scroll-down"),
                    I(l, "scw-visible", t[6]),
                    L(u, "class", "scw-input-wrap"),
                    L(C, "class", "scw-btn scw-btn-send"),
                    I(C, "scw-active", t[13]),
                    L(y, "class", "scw-input-buttons-wrap"),
                    L(e, "class", "scw-page scw-page--chat"),
                    L(e, "inert", t[12]);
            },
...
            p(t, i) {
                if (3702919 & i[0]) {
                    let e;
                    for (D = t[7], e = 0; e < D.length; e += 1) {
                        const r = Mr(t, D, e);
                        H[e] ? (H[e].p(r, i), it(H[e], 1)) : ((H[e] = qr(r)), H[e].c(), it(H[e], 1), H[e].m(n, null));
                    }
                    for (et(), e = D.length; e < H.length; e += 1) A(e);
                    nt();
                }
                (!E || 1 & i[0]) && S !== (S = t[0].newMessages + "") && (l.innerHTML = S), (!E || 64 & i[0]) && I(l, "scw-visible", t[6]);
                const r = {};
                256 & i[0] && (r.maxLines = t[8].maxLines),
                    1024 & i[0] && (r.isTouchDevice = t[10]),
                    1 & i[0] && (r.placeholder = t[0].userInput.placeholder),
                    !f &&
                        16 & i[0] &&
                        ((f = !0),
                        (r.value = t[4]),
                        (function (t) {
                            z.push(t);
                        })(() => (f = !1))),
                    d.$set(r),
                    t[5] ? (R ? R.p(t, i) : ((R = Gr(t)), R.c(), R.m(u, null))) : R && (R.d(1), (R = null)),
                    t[11].hide ? _ && (_.d(1), (_ = null)) : _ ? _.p(t, i) : ((_ = Qr(t)), _.c(), _.m(y, T)),
                    (!E || 1 & i[0]) && N !== (N = t[0].iconSend + "") && (C.innerHTML = N),
                    (!E || 8192 & i[0]) && I(C, "scw-active", t[13]),
                    (!E || 4096 & i[0]) && L(e, "inert", t[12]);
            },

This is inside the function Zr which seems to be where the main chat widget is built. Also interesting is that this pattern of minified code is Svelte-like (the object with a pattern of { c(), m(_, _), p(_, _), d(_) } is what svelte compiles code into - c is create, m is mount, p is patch and d is detatch. Elsewhere in the file we see references of $$.on_destroy, $$.bound, etc., further confirming this). So this is a svelte component - not LWC, I believe.

Going a little further - the I(C, "scw-active", t[13]) piece which seems to toggle the class.

I think because of the near-membrane code I am having difficulty actually setting breakpoints in the chat-widget to go much further, I can't easily see what t[13] is (I imagine a boolean) nor can I seem to find how it's computed. I'll take another look later but this might provide enough of a hunch for others to go on.

Comment 6

[Sean Feng [:sefeng211]]

Three of us looked into this, we still weren't able to find the root cause. As Keith pointed out, the nature of this site is hard to debug, I think it's fair to say this bug is blocked.

Comment 7

[Jan Jaeschke [:jjaschke]]

Same happens e.g. on the German version of this site: https://kundenservice.lidl.de/SelfServiceDE/s/

Comment 8

[Keith Cirkel [:keithamus]]

Attachment: reduction.html

We just paired on this, and made an attempt to simply take the ChatWidget code and get it running on a local html file, without near-membrane conflicting - in the hopes that we could set up the app to reproduce. During pairing we couldn't get the settings of the ChatWidget class sufficiently loaded to cause the widget to do much.

However, after the call I took a look again at the websites code, to see if it constructed the ChatWidget, and it does, with a large settings object. I was able to copy-paste the settings object and get it barely functioning (see attached) - we can see with this reduction that the scw-active class is being applied on the <div class="scw-btn scw-btn-send"> element! (To reproduce, simply load the html file and type in the textarea with the placeholder "countryPlaceholderUserInput", observing the pink square which appears).

So in other words it looks like perhaps the svelte component works fine in isolation, but either something with near-membrane (or perhaps the socket connection?) are causing sufficient issues to prevent this class applying. I would hazard a guess it might be near-membrane as I'm fairly sure that code proxies all application code through iframes.

Comment 9

[Sky Schubert [:skyschub]]

Let's try to find a contact here.

Comment 10

[Sky Schubert [:skyschub]]

I sent a LinkedIn message to a Lead Software Engineer - and while they are not in the right team AFAICT, I hope they can redirect me to the right people.

Comment 11

[Sky Schubert [:skyschub]]

This is affecting all branches:

• https://customer-service.lidl.co.uk
• https://informace-pro-zakazniky.lidl.cz
• https://kundenservice.lidl.de/SelfServiceDE

and others. So far, it seems .cz has the highest page rank, so let's set the URL to that.

Comment 13

[Sky Schubert [:skyschub]]

No response from the contact in 6 months, let's try to find another one.

Comment 14

[Bernadett Farkas]

This issue is reproducible on Lidl Portugal Support Portal too, using Firefox Nightly 152.0a1 on Windows 10.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Keith, I see the same pink square after typing in both Chrome and Firefox. Is that expected?

Comment 16

[Jeff Muizelaar [:jrmuizel]]

Claude claims that this is caused by the following code in https://assistenza-clienti.lidl.it/SelfServiceIT/resource/1761076905000/CCC_VCA_4_13_0/chat-widget.min.js

      if (c.computedStyleMap().get("transition-property")?.value === "none") {
        c = x.querySelector(".scw-page-wrap");
      }

Comment 17

[Jeff Muizelaar [:jrmuizel]]

That being said turning on layout.css.typed-om.enabled doesn't seem to fix it.

Comment 18

[Keith Cirkel [:keithamus]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #15)

Keith, I see the same pink square after typing in both Chrome and Firefox. Is that expected?

Yes the reduction was not a reduced reproduction, but more the component without the near-membrane stuff. It was working in all browsers IIRC.

Comment 19

[Jeff Muizelaar [:jrmuizel]]

Bug 2047919 seems similar. It's also running the salesforce sandbox

Comment 20

[Jan Varga [:janv]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #16)

Claude claims that this is caused by the following code in https://assistenza-clienti.lidl.it/SelfServiceIT/resource/1761076905000/CCC_VCA_4_13_0/chat-widget.min.js

      if (c.computedStyleMap().get("transition-property")?.value === "none") {
        c = x.querySelector(".scw-page-wrap");
      }

That should work when the Typed OM pref is flipped.

Comment 21

[Jan Varga [:janv]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #17)

That being said turning on layout.css.typed-om.enabled doesn't seem to fix it.

The chat doesn't work for me in Safari, it works only in Chrome.

Comment 22

[Jeff Muizelaar [:jrmuizel]]

This works with fix from bug 1663090

Comment 23

[Raul Bucata]

Verified as FIXED using the RC Build

Tested with:

Browser / Version: Firefox 154.0-candidate build 1
Operating System: Windows 10 PRO x64