2022491 - [Nightly] Facebook on mobile hangs when clicking comments

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Olli Pettay [:smaug][[e-mail]]]

Load Facebook on Android/Nightly, scroll to something which has comments, click the comment icon. Hang.

https://share.firefox.dev/4s7RBvp

Comment 1

[Dennis Schubert [:denschub]]

Looks like most of the time happens in CSS parsing? Let's assign this to the layout team.

Comment 2

[Daniel Holbert [:dholbert]]

I can reproduce in Nightly on my main Android device, as well as on desktop Nightly in responsive design mode with "Galaxy S10/S10+" device profile.

This also appears to be a regression (Nightly 2026-01-17 is "good", for example). I'll bisect.

Comment 3

[Daniel Holbert [:dholbert]]

Regression range: https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=089dbddf4b64183cb05ed64b916072609f7340b1&tochange=4fd6a053e5848cbd19e19a9e9caf9fd8ce4d1569

--> regression from bug 2020681

Comment 4

[Daniel Holbert [:dholbert]]

The profile in comment 0 doesn't seem to be symbolicated -- so here's a new performance-profile with symbols & screenshots:
https://share.firefox.dev/4rzC3PO

This captures ~90 seconds of a hang; the hang appeared to continue indefinitely, though.

Emilio: given that bug 2020681 seems to have just been a "cleanup" patch with presumably no intended behavior-change, and it had this severe consequence, and Nightly 150 moves to beta in 1 week -- maybe safest to backout bug 2020681 for now to fix this issue, and investigate/address this hang as part of re-landing that bug?

Comment 5

[Emilio Cobos Álvarez [:emilio]]

This is the function that's hanging:

function csb(a, b) {
  var c,
  d,
  e,
  f,
  g,
  h;
  a.getBoundingClientRect();
  e = a.style.height;
  d = a.offsetHeight;
  h = a.scrollHeight;
  f = a.style.overflow;
  if (d >= h) {
    g = a.style[hJe];
    a.style[hJe] = '';
    a.style.height = d + b + REe;
    a.style.overflow = BCe;
    if (h < a.scrollHeight) {
      while (a.offsetHeight >= a.scrollHeight) {
        a.style.height = (d -= b) + REe
      }
      while (a.offsetHeight < a.scrollHeight) {
        a.style.height = d++ + REe
      }
      a.style.height = e;
      a.style.overflow = f;
      a.style[hJe] = g;
      return d
    } else {
      A4b();
      c = (YQb(), YDd(nRb((hwd(true, lBe), XQb), mBe), 0));
      if (B4b(L4b(c), {
        l: ZAe,
        m: 361152,
        h: 262145
      }, false, (eCc(), dCc))) {
        a.style.height = e;
        a.style.overflow = f;
        a.style[hJe] = g
      }
    }
  }
  return h
}

I think my patch makes editor initialization not eager for <textarea> which probably changes layout subtly. In this function, a is a textarea, b is 22, hJe is padding, BCe is hidden, REe, h is 32 but a.scrollHeight and a.offsetHeight is 10 during the loop.

The textarea has the following styles:

style attribute {
  --font-size: 16px;
  font-size: 16px;
  color: rgb(0, 0, 0);
  --placeholder-color: #65686c;
  line-height: 22px;
  height: 10px;
  overflow: hidden;
}
.ssr .mentions-text textarea.native-input {
  z-index: 3;
  text-align: start;
  word-spacing: 0;
  text-indent: 0;
  letter-spacing: normal;
  -webkit-line-break: after-white-space;
  -webkit-user-select: text;
  white-space: pre-wrap;
  word-wrap: break-word;
}
.ssr textarea.native-input {
  resize: none;
  direction: inherit;
}
.ssr .input-box {
  border: none;
  background-color: transparent;
  width: 100%;
  height: 100%;
  pointer-events: auto !important;
  box-sizing: border-box;
}
html.unselectable input, html.unselectable textarea {
  -webkit-user-select: text;
}
html.unselectable * {
  -webkit-user-select: none;
}
.native-input {
  position: absolute;
  border: .5px solid lightgray;
  font-family: Roboto,sans-serif !important;
  padding: 0 6px;
  pointer-events: initial;
  box-sizing: border-box;
}

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Attachment: Test-case

Since we initialize the editor lazily now the <br> isn't there until editor initializes, and Facebook gets confused because scrollHeight collapses to 0 effectively.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2022491 - Eagerly create textarea <br> node. r=smaug,masayuki

Editor initialization already copes with it.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b007bddff81c
https://hg.mozilla.org/integration/autoland/rev/17d961b344a2
Eagerly create textarea <br> node. r=smaug,masayuki

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/58642 for changes under testing/web-platform/tests

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox150 (nightly). However, the bug still has low severity.

:hsinyi, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 11

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/17d961b344a2

Comment 12

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/17d961b344a2

Comment 13

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

FWIW, seems to be working now. Thanks for fixing :)