Jump to content

[Messenger] Selecting all rows (checkboxes) takes a long time the more messages are listed

teraßyte

By teraßyte

  • Status: Moved to Github

While viewing the messenger I opened the menu to “Select rows based on type” (checkbox above the messages list) and clicked the All option.

  1. The JS took ~6 seconds to run and select All checkboxes.

  2. I then clicked None to deselect everything. It took about ~5 seconds.

  3. I then loaded a second page of messages (50 total) and selecting again the All option took ~14 seconds.

  4. I clicked again None and it took ~12 seconds.

  5. A third page (75 messages) took ~27 seconds and I even received a warning from Chrome that the page was unresponsive and I could wait or close it. ( I clicked wait.)

  6. Same thing when deselecting all 75 messages: ~24 seconds and again Chrome warned me the page was unresponsive.

Clearly, there’s some JS issue. It shouldn't take this long. The more messages are listed, the more time it takes.

    •

    User Feedback

    Recommended Comments

    teraßyte Grand Master

    teraßyte

    Clients

    Even clicking a single checkbox myself to select a message takes 1~2 seconds before the action is done. On v4 it’s instant.

    Something is slowing down considerably the JavaScript in v5 (at least on Windows 10 + Chrome v132):

    • Tooltips are laggy

    • The editor lags behind if I type too fast (I mentioned it to @Matt in another topic and even posted a video)

    • The JS to select rows based on their type is extremely slow, too

    • Other JS-related things feel slow, too

    Matt Finger Community Regular

    Matt Finger

    Invision Community Team

    I just wanted to provide an update while we are working on slow-feeling UI components in Chrome.

    It’s actually most likely some updated CSS selectors and rules that are slowing down position-related JavaScript that relies on forced reflows which run very slowly in Chrome.

    The tooltips, for example, were about 5x slower using jQuery until rewriting in native JS because jQuery triggered loads of reflows under the hood to get element sizing. This is also why some pages are worse than others: some pages contain layouts that are more “problematic” in terms of how Chrome internally computes the position.

    As a side note, the slow editor issue should be resolved in the next release, but it’s one of those things that is very hard to test as it works performantly on our machines. I could only reproduce noticeable lag when holding down backspace or when working with very long content.

    •