1891346 - Freeze when editing 400 rows-table in Confluence

Status: NEW

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

Description

[Marcel]

Attachment: Profile: 125.0 beta 9

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0

Steps to reproduce:

In a (company internal) Confluence page, I switched to the edit view.
There I scrolled down a table with about 400 rows and tried to edit the table.

All tested Firefox versions are affected. Tested Versions (always with a fresh profile):
Firefox 124
Firefox 125 (beta 9): https://share.firefox.dev/3TSIL4H
Firefox 126 Nightly: https://share.firefox.dev/43TV6Kp

Actual results:

Editing works, but it takes a few seconds just to print a new character I typed.

Expected results:

Firefox should not hang and behave like Microsoft Edge, which works flawlessly in that situation.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Tables' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[David Shin[:dshin]]

Hm, a lot of time being spent on handling mousemove event on <td class="confluenceTd">.
Reporter, are you able to find what that element may be (e.g. By searching for that class name in Inspector)? Instance of Confluence I have access to does not seem to have that element at all..

Comment 3

[Daniel Holbert [:dholbert]]

Layout doesn't seem to play a significant role in the attached profiles. They seem to show the page spending time on its own JS, and on the internals of the Element.setAttribute DOM API (including notifying mutation listeners), so let's tentatively reclassify as DOM:Core&HTML for now.

One possibility that's worth testing & ruling out, before diving too far into the internals here -- it's conceivable that Confluence is running different code for different browsers, based on UA-string-sniffing. So, one other request for you -- could you try an add-on like https://addons.mozilla.org/en-US/firefox/addon/user-agent-string-switcher/ and see if choosing a Chrome user-agent string via that add-on might avoid the issue?

(You can check what UA string your browser is sending, to confirm that the add-on has taken effect, by e.g. visiting https://www.whatismybrowser.com/detect/what-is-my-user-agent/ )

Comment 4

[Marcel]

(In reply to David Shin[:dshin] from comment #2)

Hm, a lot of time being spent on handling mousemove event on <td class="confluenceTd">.
Reporter, are you able to find what that element may be (e.g. By searching for that class name in Inspector)?

Every <td> field in that Confluence table has either class confluenceTd or confluenceTh. Not sure why they don't just use <th>, but anyway, they seem to style <td>-fields based on that class.

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

could you try an add-on like https://addons.mozilla.org/en-US/firefox/addon/user-agent-string-switcher/ and see if choosing a Chrome user-agent string via that add-on might avoid the issue?

Your guess was right. Switching the UA to Chrome indeed made the page perform smoothly as it should. So they seem to actually execute different JavaScript depending on the UA-string.

So that means we can't do anything about that situation and it purely depends on Atlassian to fix that performance bug -.-
Is this correct? If so feel free to close (as invalid probably).

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Marcel from comment #4)

Your guess was right. Switching the UA to Chrome indeed made the page perform smoothly as it should. So they seem to actually execute different JavaScript depending on the UA-string.

So that means we can't do anything about that situation and it purely depends on Atlassian to fix that performance bug -.-
Is this correct? If so feel free to close (as invalid probably).

Thanks for checking that -- I'll categorize this as Web Compat then, and perhaps we can do some outreach to Atlassian to see if they can fix it. Even if it's not strictly a bug in Firefox, it's still an issue that negatively affects Firefox users in particular, so we'd love to get it addressed if we can.

Though it might be a bit difficult to report to Atlassian in an actionable way, without having a concrete example to point them at. A few ideas:

• it might be helpful for them to have the URL of an affected page (though they also may have limited ability to see the content on deployments for privacy reasons)
• even better would probably be steps-to-reproduce-the-problem from a fresh page, if you can up with those (see below for sample steps that I tried which so far haven't worked).

I just tried to reproduce this myself in Mozilla's confluence deployment, but wasn't able to do so. Here's what I did:

• click "Create|Page"
• Press forward-slash to bring up the menu, choose "Table"
• Hover the dot at the left edge of the table row, and click the "+' to insert a new row. Click hundreds of times.
• Type some text into some of the table rows; see how the table responds.

So far I haven't been able to reproduce much of any performance issue by doing that^, but maybe your confluence deployment has different logic / a different version, or maybe it requires a particular types/amounts of content inside the table before the issue shows up, or maybe you notice some important missing steps/pieces when you look at the affected page in your Confluence instance? One relevant difference I'm seeing up-front: my table doesn't have the same structure or CSS classes as yours -- in edit mode, my table parts look like <th class="pm-table-header-content-wrap"> and <td class="pm-table-cell-content-wrap">. So I might be looking at a different version of Confluence than you.

Thanks!

Comment 6

[Marcel]

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

Even if it's not strictly a bug in Firefox, it's still an issue that negatively affects Firefox users in particular, so we'd love to get it addressed if we can.

Thanks! Just FYI: My performance issue occurs on a internal server instance that is only reachable inside the company's network, not via internet.

I will try to create a free Confluence cloud instance and port the problematic page to the cloud. If it's possible I'll make that page publicly available and post it here.
If I fail to reproduce the bug inside a cloud instance, I'll try to "extract" the bad JavaScript part somehow and use that as an example.

Anyway, I will keep you updated through this bug.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Marcel from comment #6)

Thanks! Just FYI: My performance issue occurs on a internal server instance that is only reachable inside the company's network, not via internet.

Right, gotcha. We're still interested to get it identified & raise it with Atlassian's confluence team, though, since presumably other folks could be hitting similar issues on their own Confluence deployments, on pages with similar content. (Unless the affected page happens to be doing something extremely specific to your deployment.)

I will try to create a free Confluence cloud instance and port the problematic page to the cloud. If it's possible I'll make that page publicly available and post it here.
If I fail to reproduce the bug inside a cloud instance, I'll try to "extract" the bad JavaScript part somehow and use that as an example.

Anyway, I will keep you updated through this bug.

That would be amazing -- thank you!

Comment 8

[Raul Bucata]

Moving the issue to NEW based on the triage process for UNCONFIRMED Bugzilla issues and the comments made here

Comment 9

[Dennis Schubert [:denschub]]

Marcel, can you test this again and see if this is still an issue, please? :)

Comment 10

[Marcel]

Unfortunately, it's still there https://share.firefox.dev/42TNxFb
Didn't find a way to make a test-case without publishing that private site. I forgot a bit about that as my company moved away from using such big tables in Confluence. I git one more idea. Maybe I could go to that site and just Crtl+S save it, remove company/personal data and publish that. I'll try it on Monday.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Marcel from comment #10)

Didn't find a way to make a test-case without publishing that private site. I forgot a bit about that as my company moved away from using such big tables in Confluence. I git one more idea. Maybe I could go to that site and just Crtl+S save it, remove company/personal data and publish that.

That would be great. In particular, it'd be great if you could save the page with the default Firefox UA string, and also save it when spoofing a Chrome UA string (per end of comment 4). It's possible they serve you entirely different html/JS depending on your UA string, so it'd be great to see to-what-extent the page structure differs between that broken vs. good setup.

(Note: it's possible -- but probably-fine -- that a saved copy of the page may not reproduce the bug. It seems like the jank here is in a mousemove handler per comment 2, and JS-dependent things like event-handlers often don't get set up properly in saved copies of web pages. But the saved page (particularly the html and JS files) might still be enough to go on, to let us try to get some clues to pass along to Confluence.)

Comment 12

[Daniel Holbert [:dholbert]]

(You might also have more luck with an addon like https://addons.mozilla.org/en-US/firefox/addon/single-file/ to save the page - that avoids the problem of getting a folder full of resources. I haven't personally used that add-on, but I've seen others use it to generate saved copies of pages that include all the scripts/etc.)

Comment 13

[Marcel]

I saved the page now (using the single-file Addon) and there is a difference in size of these two html-files (Firefox and Firefox using Chrome-user agent). I'll need to anonymize the page before I can post it here, as it contains personal data. Will upload it as soon as it doesn't contain any reference to people or companies anymore.

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to Marcel from comment #13)

I saved the page now (using the single-file Addon) and there is a difference in size of these two html-files (Firefox and Firefox using Chrome-user agent). I'll need to anonymize the page before I can post it here, as it contains personal data. Will upload it as soon as it doesn't contain any reference to people or companies anymore.

Just a reminder, this would be useful to do, when you're able! It'll give us an idea about what to tell Confluence about. Thanks!

Alternately, feel free to email the saved files (in whatever state of redactedness you'd like) to me -- dholbert at mozilla dot com -- rather than posting them publicly here, and I'll keep them confidential.

Alternately, if it's easier for you than redacting on your end, I'd also be happy to set up a one-on-one Zoom call at some point to take a look together. (Hypothetically you'd use Zoom to share your screen, and then you'd view these files locally -- so that you don't need to share the actual contents other than visually in that Zoom session -- and we could look at them together using Firefox's DevTools to see how they differ.) Likely we'd be able to get enough useful information from that in order to make an actionable report to Confluence.