1933229 - google.com - Images in "Chat" are not loading

Status: NEW

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

Description

[Raul Bucata]

Attachment: Chr vs FF

Environment:
Operating system: Linux
Firefox version: Firefox 132.0 (release)

Preconditions:

• Clean profile

Steps to reproduce:

1. Navigate to: https://mail.google.com and perform account login
2. Access the "Chat" tab from the left pane
3. Open a chat that contains an image
4. Click on the image to open it and observe

Expected Behavior:
The image loads

Actual Behavior:
The image is stuck in a loading state

Notes:

• Reproducible on the latest Firefox Release and Nightly
• Reproducible regardless of the ETP setting
• Works as expected using Chrome

---

Created from webcompat-user-report:7708e7e2-43f5-4a32-9ffa-c0ba52eb0ee2

Comment 1

[Piuumano]

The bug is already active, even with the last upgrade ( 133.0 ).

Comment 2

[Dallace]

A slight work around is to right click on the image while it's spinning circle (aka after you've tried to display it) and select 'inspect'. The image will then come up, and then work if you click on it again. I have even had it work on different images after I've performed the above on the original one.

Personally I am seeing this on 130.0.2 on MacOs (15.1.1)
Buddy of mine is on Win10 and has tried. 133 and now 134B1

in all cases the issue is present.

Comment 4

[Daniel Holbert [:dholbert]]

Here's a profile of me reproducing the bug in Firefox:
https://share.firefox.dev/41eMRti

In Chrome, if I perform the STR and watch carefully in network devtools, I see a network request in the listing for a URL like this:
https://chat.google.com/u/0/api/get_attachment_url?url_type=FIFE_URL&content_type=image%2Fpng&attachment_token=[LONG-IDENTIFIER]&sz=w1503-h314 and this URI ends up 302-redirecting to the actual image (which has a URL like https://lh3.googleusercontent.com/chat_attachment/[ANOTHER-LONG_IDENTIFIER]DOc=w1503-h314

In Firefox, I don't see any network request with get_attachment_url or chat_attachment in the URI when I perform the STR.

Comment 5

[Daniel Holbert [:dholbert]]

Here's a profile of me reproducing the bug, waiting for a bit, and then resizing my browser window very-slightly to work around the bug:
https://share.firefox.dev/3ZkR23U

(viewport resizes apparently nudge Google to make the image-request and work around the bug; I think that viewport-resizing is the relevant piece of the "inspect" workaround in comment 2)

I included network logging in that profile so that maybe the backtraces might help figure out where we are & aren't kicking off the image load... (Edit: I forgot to check the box for log backtraces, but I got some in the next comment.)

Comment 6

[Daniel Holbert [:dholbert]]

Here's another profile similar to comment 5 but now with logging backtraces enabled and with a few lucky samples that were captured -- I'm zooming to the moment-of-truth where I resized the browser window which nudged Google to successfully load the image:
https://share.firefox.dev/49kSubf

In that region, you can see that my browser-window-resize event seems to result in a profiler-sample that has mozilla::dom::HTMLImageElement::SetSrc in the backtrace -- i.e. that's where Google is actually setting up an img element with a src attribute, after neglecting to do so earlier perhaps.

The JS backtrace is minified, but it's here (first line being the innermost function, setting src inside of some b1 function):

set HTMLImageElement.src
[...]
js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) [js/src/vm/Interpreter.cpp]
b1 [https://www.gstatic.com/_/apps-fileview/_/js/k=apps-fileview.prv.en.DjH5N_oSW-A.O/am=DAY/d=0/rs=AO0039s443KAuOoPToyjI8MEc7l0PvrTkA:2230:834]
X3/< [https://www.gstatic.com/_/apps-fileview/_/js/k=apps-fileview.prv.en.DjH5N_oSW-A.O/am=DAY/d=0/rs=AO0039s443KAuOoPToyjI8MEc7l0PvrTkA:2396:502]
m [https://www.gstatic.com/_/apps-fileview/_/js/k=apps-fileview.prv.en.DjH5N_oSW-A.O/am=DAY/d=0/rs=AO0039s443KAuOoPToyjI8MEc7l0PvrTkA:161:71]
qh [https://www.gstatic.com/_/apps-fileview/_/js/k=apps-fileview.prv.en.DjH5N_oSW-A.O/am=DAY/d=0/rs=AO0039s443KAuOoPToyjI8MEc7l0PvrTkA:161:12]
W3.prototype.C [https://www.gstatic.com/_/apps-fileview/_/js/k=apps-fileview.prv.en.DjH5N_oSW-A.O/am=DAY/d=0/rs=AO0039s443KAuOoPToyjI8MEc7l0PvrTkA:2395:24]
js::RunScript

Comment 7

[Daniel Holbert [:dholbert]]

Side note, the relevant overlay content here ends up getting rendered in a full-screen iframe. I think it's that iframe getting its size adjusted that triggers the image to be loaded. (If I manually grant that iframe height:99% for example, in devtools, then the image suddenly loads.)

For Chrome's automatic no-resize-required network request from comment 4 here, they helpfully show a JS backtrace (though I think really it's the JS backtrace for where the <img> gets its src attribute set). That backtrace's innermost portion looks just like the backtrace that I quoted in comment 6; and further up the stack, it has V3.setSize which sounds suspiciously like the iframe getting (re)sized.

So I wonder if this is just a case where there's a race condition with the initial iframe setup, which results in Chrome treating the iframe as getting a resize event of some sort as part of its initial display, vs. Firefox treating the iframe as not getting any such event.

Comment 8

[Daniel Holbert [:dholbert]]

OK, a few new developments:
(1) This is indeed a case where the resize event is firing in Chrome but not in Firefox, for the iframe's inner document, when the iframe goes from display:none to display:block. I can confirm this by inspecting the iframe's document in DOM inspector, and then using Web Console (now in the context of that document) to run addEventListener("resize", ()=>{console.log(iframe resized)}). From that point on, Chrome prints the log message when I show the iframe (i.e. when I click to bring up the image overlay view), whereas Firefox does not.

(2) This is actually a regression, though it's an old-ish one. Regression range is:
Last good: 2022-11-20
First bad: 2022-11-21
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d2c6287383301f29964047d5c718640eb4bbcccb&tochange=a29b80b107103df84e493008e420e30aea857da1
The aforementioned simple console.log() experiment and the comment 0 STR both give expected-results (logging succeeds, image shows up) in the "last good" build vs. actual-results (no logging, image does not show up until I resize browser viewport when throbber is up) in the "first bad" build.

(3) I confirmed that the relevant thing in the regression range was enabling container queries in Nightly builds. In particular, I can elicit "good" results from the first-bad build, Nightly 2022-11-21, by simply toggling layout.css.container-queries.enabled to false. (Note that that pref doesn't exist anymore.)

(4) I confirmed that the iframe here does indeed use container-queries (e.g. it has @container (width < 840px){ inline in a <style> element), so the relevance of container queries is credible.

Comment 9

[Daniel Holbert [:dholbert]]

emilio, maybe you could take a look? This is somehow related to (and regressed by the enabling of) container queries - see comment 8. Though I don't yet have a reduced testcase.

Comment 10

[Daniel Holbert [:dholbert]]

Notably, this does not reproduce when I test with my MoCo corporate google account; images load and the resize event handler fire just fine there. But it does reproduce in my personal Google account (in two personal accounts that I've tested, actually). So for now at least, it seems that the STR require you to be using a regular/personal Google account in order to trigger this.

I assume this is due to enterprise Google accounts being on a slightly older deployment of their styles/scripts etc., with this bug only having been introduced relatively recently on Google's side. (I did confirm that the chat iframe in question here -- the one that pops up to load the img element -- has substantially different CSS in my moco vs. personal accounts.)

(As an extreme last resort, we could theoretically reach out to Google about whatever deployment might've introduced this, to learn more and/or see if they're up for rolling something back; but it'd be good to understand the bug a bit better before we do that -- to at least capture a reliably-reproducing testcase, and/or land a fix on our side when possible.)

Comment 11

[Emilio Cobos Álvarez (:emilio)]

So I can't repro on any of my accounts...

for (let e = iframe; e; e = e.parentElement) {
  if (getComputedStyle(e).containerType != "normal") {
    console.log(e);
  }
}

Doesn't say anything... So I don't know how anything inside the iframe can prevent a resize event from happening on the window...

Comment 12

[Daniel Holbert [:dholbert]]

Aha, that was a good clue. I found an element in the outer document that has a nondefault container-type -- <c-wiz which has container-type: inline-size -- and if I mock that up in the reduced testcase that I had so far been able to unsuccessfully construct, then I do see that it prevents resize events from being fired inside the iframe, for some reason.

which is to say: I now have a reduced testcase. \o/ I'll spin that off to a helper platform-bug.

Comment 13

[Daniel Holbert [:dholbert]]

I filed bug 1935189 with a reduced testcase.

Comment 14

[Daniel Holbert [:dholbert]]

[transferring needinfo to the platform bug]

Comment 15

[Daniel Holbert [:dholbert]]

In reply to Daniel Holbert [:dholbert] from comment #12)

Aha, that was a good clue. I found an element in the outer document that has a nondefault container-type -- <c-wiz which has container-type: inline-size

Actually, retesting now, I'm seeing a different element that has a nondefault container-type (and only that one element):

<div class="CRPU9d" jsname="z1ikhe">

which has these styles:

.CRPU9d {
	container-type: inline-size;
}

I found that element by running this in my web console:

for (let e of document.querySelectorAll("*")) {
  if (getComputedStyle(e).containerType != "normal") {
    console.log(e);
  }
}

That element is present in my personal gmail session but not-present in my MoCo gmail session, when I'm viewing a chat message. This element doesn't actually have any children so it's not really doing anything, but that doesn't seem to matter for the purposes of this bug or bug 1935189; maybe any such element is sufficient to trigger container queries' layout/style interleaving...

Comment 16

[Daniel Holbert [:dholbert]]

Once we've got a fix for the underlying bug (bug 1935189), it's likely that it'll take 1-2 months to reach release (possibly riding the trains as part of current 135 Nightly -- not yet sure if the fix will be trivial/safe enough to be considered upliftable to current beta 134).

In light of that, I just sent a message to our Google contacts to see if they're interested & able to work around this issue on their side, in the short term -- maybe by e.g. removing or putting display:none' on the element that I found in comment 15 that seems to be causing this (for me at least), or by rolling back a recent update.

Comment 17

[Daniel Holbert [:dholbert]]

Google's folks have a fix that should address this, so this might become fixed on their end in a week or so.

Comment 18

[Daniel Holbert [:dholbert]]

Our bug 1935189 isn't yet fixed, but our contacts at Google confirmed that they've shipped a workaround that should avoid this issue for nearly all users. (Not sure about the exact details of which users might still be affected; maybe there are multiple situations that can apply container-type: inline-size in the outer document, and some of the edge-casier-ones were trickier to prevent.)

So: this should be fixed in most cases. I confirmed that I'm not able to reproduce this anymore. (In one of my previously-affected Google accounts, I'm getting expected-results; in a different previously-affected Google account, I'm just getting an immediate file-download when I click on an image in chat, which is slightly annoying but is at least not this bug.)

Raul, would you mind retesting to confirm that this issue has gone away for you?