User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160502172042 Steps to reproduce: editing and surfing google docs when many users are also editing these files Actual results: firefox freezes for some seconds

I could not reproduce the freeze issue while editing a google file on the latest Nightly 49.0a1 (Build ID: 20160605030215), nor on the latest Firefox 46.0.1 RC. Reporter, could you specify the number of users that are editing simultaneously the same file? Also, to narrow down the problem, could you please try the following? 1) Test in a clean profile https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles 2) Test in Safe Mode https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode 3) Disable hardware acceleration https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems#w_turn-off-hardware-acceleration 4) Try to get a stack trace from hung Firefox on Windows https://developer.mozilla.org/en-US/docs/How_to_Report_a_Hung_Firefox Please post back the results.

it was a plublic file from feedly.com to help translate it but the file is now offline i think there were more than 40 at the same time who edited it - but it could be more 1. tested and didnt help 2. tested and didnt help 3. not tested - cant test 4. cant test

Based on Comment 2, I'm removing the need info flag.

Shako, have you looked at this type of situation (multiple simultaneous users)?

Hi Andrew, We have discussed this situation when we creating test metrics, but at the end we didn't put such test case in our first priority case set. The main reason is test case design and test environment for this situation is much more complicated than the others. Do you think we should add such test case? If yes, considering team is moving focus to FB and Gmail, and test environment implementation, I will suggest we could start from reading the same content with multiple simultaneous users.

(In reply to Shako Ho from comment #5) > Hi Andrew, > We have discussed this situation when we creating test metrics, but at the > end we didn't put such test case in our first priority case set. The main > reason is test case design and test environment for this situation is much > more complicated than the others. > > Do you think we should add such test case? > > If yes, considering team is moving focus to FB and Gmail, and test > environment implementation, I will suggest we could start from reading the > same content with multiple simultaneous users. That sounds good to me. It seems like there are often anecdotal reports of multiple simultaneous users negatively impacting performance.

Hi Andrew, Walter will help on this test.

I did a testing in Hasal for multiple user scenario. # Previous 1 user scenario result Firefox Chrome Percentage Ubuntu: 37,450 38,000 -1.5％ Win7: 45,767 45,700 0.1% # Now, with a 5 users scenario result Win7: 40,976 40,161 1.9% I did see an acceptable difference here by comparing firefox & chrome results. # Hardware OS: Ubuntu 14.04 LTS 64-bit CPU: i7-3770 3.4GMhz Memory: 16GB Ram Hard Drive: 1TB SATA HDD Graphics: GK107 [GeForce GT 640]/ GF108 [GeForce GT 440/630] # Browsers Firefox version: 47 Chrome version: 51.0.2704.103 Is there any additional information? For example, detailed document content and/or user behavior. In that case, I can do further investigation. PS. We haven't support Windows 10 (Windows NT 10.0) testing yet.

i googled some time as this repord: https://support.mozilla.org/de/questions/917006 in my case there was also spanish language did you test different languages in your test case? and could you try to increase the user numbers to get a non normal scenario? but could also be a normal scenario for small business companys so i think this should also be tested

but im a german user and didnt type spanish ;)

(In reply to Walter Chen[:ypwalter][:wachen] from comment #8) > I did a testing in Hasal for multiple user scenario. > > # Previous 1 user scenario result > > Firefox Chrome Percentage > Ubuntu: 37,450 38,000 -1.5％ > Win7: 45,767 45,700 0.1% > > # Now, with a 5 users scenario result > Win7: 40,976 40,161 1.9% > I did see an acceptable difference here by comparing firefox & chrome > results. Thanks!

# Hardware OS: Ubuntu 14.04 LTS 64-bit CPU: i7-3770 3.4GMhz Memory: 16GB Ram Hard Drive: 1TB SATA HDD Graphics: GK107 [GeForce GT 640]/ GF108 [GeForce GT 440/630] # Browsers Firefox version: 47 Chrome version: 51.0.2704.103 # Previous *one user scenario result* Firefox Chrome Percentage Ubuntu: 37,450 38,000 -1.5％ Win7: 45,767 45,700 0.1% *five user scenario result* Firefox Chrome Percentage Win7: 40,976 40,161 1.9% # Now, with a 20 users+ scenario result Firefox Chrome Percentage Win7: 45,639 45,789 -0.3% # Result It's interesting that the performance of firefox and chrome is actually alike, but it did have some increase in page responding time. A 12% increase was found when the user online simultaneously went up by 15 people.

(In reply to Walter Chen[:ypwalter][:wachen] from comment #12) > A 12% increase > was found when the user online simultaneously went up by 15 people. Can we graph the # of users and performance for both Chrome and Firefox? Assuming it's easy to simulate, I'm thinking 1-50 users.

(In reply to Andrew Overholt [:overholt] from comment #13) > (In reply to Walter Chen[:ypwalter][:wachen] from comment #12) > > A 12% increase > > was found when the user online simultaneously went up by 15 people. > > Can we graph the # of users and performance for both Chrome and Firefox? > Assuming it's easy to simulate, I'm thinking 1-50 users. If it's harder to do: 1, 5, and 10 simultaneous users in both Chrome and Firefox would be great data points to have.

(In reply to Andrew Overholt [:overholt] (back Aug 31) from comment #14) > > If it's harder to do: 1, 5, and 10 simultaneous users in both Chrome and > Firefox would be great data points to have. Isn't that what comment 13 is? It gives Chrome and Firefox times for 1, 5, and 20 simultaneous users iiuc. (And the result is a wash; it looks like we do not have steps to reproduce this bug unfortunately.)

Sorry, I somehow completely missed that part of comment 12.

Given the benchmark giving no clues on Firefox being slower and pre-e10s nature of this bug I will close it for now. Please re-open if this still happens.