1696836 - Firefox can't load some websites but other browsers can in Windows 10 (version 20H2)

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Piotr]

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

Steps to reproduce:

For example:

1. Log in to you account on https://allegro.pl/
2. Open new tab and go here: https://allegro.pl/myaccount/newpayments_incoming.php
3. When website loads normally you must refresh this website (F5 key on keyboard) few times (you must be patient, sometimes this can take some time)
4. When website is can't load or it's load in part you can see that this stops when it try connect to analytics.google.com so it is very strange behavior.

On other browsers on Windows 10 20H2 version this website works without issue. Only with Firefox is a problem. On Windows 10 1909 version on another machine I can't notice this issue. Also on Ubuntu I don't have any problems with this website with firefox.

Can you fix it? I can't work on my computer with Windows 10 20H2 system. I musted to switch to another browsers (Google Chrome, Microsoft Edge). I contacted with owner of the website but this is not the first problem with firefox on Windows 10 20H2 so you should fix it.

Actual results:

Sometimes I can't load this website on Windows 10 20H2 64-bit: https://allegro.pl/myaccount/newpayments_incoming.php

When website can't load or it's load in part you can see in the bottom of the browser that this stops when it try connect to analytics.google.com so it is very strange behavior.

This can be not problem only with this website.

Expected results:

I should load this website always: https://allegro.pl/myaccount/newpayments_incoming.php

Comment 1

[Piotr]

Of course this is version of firefox 86.0 but I sended this bug from another computer with Linux machine. How I can change operating system in this bug report?

Comment 2

[Piotr]

Of course this is problem with website: https://allegro.pl/myaccount/newpayments_incoming.php

This is not with main website https://allegro.pl/ but I wrote about this website because you can't load https://allegro.pl/myaccount/newpayments_incoming.php without login to your account on https://allegro.pl/

Comment 3

[Piotr]

This is what I did and of course this doesn't help so this issue is still exist.

1. I runed Firefox in safe mode
2. I deleted all cookies
3. I refreshed firefox (refresh option)
4. I deleted all files for firefox in Appdata (Roaming, Local, LocalLow)
5. I started Windows 10 in safe mode
6. I created other local user account in Windows 10

All above steps didn't help. I only did not delete keys for firefox in Registry Editor for Windows 10. I don't want to broke my system so that is why I didn't change anything in Registry Editor. If you have knowledge what keys I can delete please tell me.

I think that this is problem with compatibility for Windows 10 20H2 because in Windows 10 1909 I don't have this problem with this website.

Comment 4

[sdoca]

I am also seeing issues with Firefox not loading websites that it was able to load last week without issue Either sites load very slowly (3-5 minutes) or won't load at all in Firefox 86 but load quickly in Edge and Chrome.

Example of site that will not load (secure connection failures after 3-5 mins):
https://www.alberta.ca/
https://www.scte.org/

Example site that take 3-5 minutes to load:
https://linuxfoundation.org/

Comment 5

[Daniel Bodea [:danibodea]]

I can confirm that all these webpages properly load and render the content in Nightly v88.0a1 and Release v86.0.1 in Windows 10 Pro Version 10.0.19041 Build 19041.

I will now manually install update 20H2.
-> Update is installed and I am "up to date". Windows is Version 10.0.19042 Build 19042.
All the websites reported showing issues properly loaded on my system on Nightly v88.0a1 and Release v86.0.1 OR Release v86.0 after having installed update 20H2.

This being said, I can't seem to reproduce your issue on my system. Considering the fact that the reporter has also tested and reproduced it in safe mode and even after deleting all Firefox data in AppData, I imagine it may be an issue related to the hardware specifications of your system.

@Piotr: can you share the info on the "about:support" page from the browser that reproduces the issue?
@sdoca: can you also share the information requested in the line above?

From a secondary point of view, I am a little confused about what this update is and how it applies/influences our browser's behavior.
The Update was named 20H2, but my Windows version is now 10.0.19042 Build 19042.
Do you have the same Windows version I mentioned above?

Comment 6

[sdoca]

Attachment: sdoca-Firefox-Support.txt

Comment 7

[sdoca]

BTW, this is the version of Windows on my machine:
OS Name: Microsoft Windows 10 Pro
Version: 10.0.18363 Build 18363

Comment 8

[Piotr]

@Bodea Daniel

This is information about firefox.

Name Firefox
Version 86.0.1
ID compilation 20210310152336
User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

Windows 10 information:

Windows 10 Home
Version 20H2
Compilation: 19042.867

I also tried Firefox beta and Firefox Nigtly. Issue exists also in these version. Can you tell me how I can verify what is the problem. You checked allegro website? I have problem only with website from this link: https://allegro.pl/myaccount/newpayments_incoming.php

You must log in to this website if you only paste this link and did not log-in this not reproduce my problem.

Comment 9

[Piotr]

I deleted some updates for Windows 10 and I returned to Windows 10 version 2004 but this issue still exist. I will try in this weekend to reinstalling my operating system if it not fix my issue maybe you can tell me how I check what is the problem? Maybe with the console in firefox I can check what is the problem? I am sure that people from Mozilla can help me. If we can fix my issue I will be happy. This is very important for me.

Comment 10

[Piotr]

Yesterday I reinstalled my operating system and I change version to Windows 10 Pro 20H2 for testing. Issue still exist. I also cleande and wiped all data of my SSD disk (low level format) and this doesn't help. So this problem is with firefox itself or hardware problem. I will try also on Linux in the future if I will not find fix for this issue.

Comment 11

[Piotr]

I also tried in this weekend Ubuntu 20.04 LTS system on my machine and I have this same problem with this website: https://allegro.pl/myaccount/newpayments_incoming.php

I also tried on my another computer with Ubuntu 18.04.5 LTS and I can confirm that Mozilla Firefox still have problem with above website on another machines but on my machine this problem is often. On other machines this problem is also exist but is rare.

For example on my machine with Gigabyte H410M S2H on Windows 10 2004 or 20H2 I have problem with this website every second loading. On this same computer with Ubuntu 20.04 LTS I have problem with this website every twenty loading. On another machines I have problem with this website every fifty loading. So this is very strange behaviour but I noticed that only Mozilla Firefox have problem with this website. This is problem with javascript because I noticed in console that some links can't load.

I also noticed problems with this website (https://www.ikea.com/pl/pl/) on other machines with Mozilla Firefox.
What is behaviour? Problems with Cart. I can't order my products and buy it. On other browser I can do this.

So I think that Mozilla Firefox have a lot of troubles. I pleased for help but Mozilla people don't want to fix it and I can notice disinterest this subject by these peoples so this is very disturbing.

If you will not change your work I will be must to change browser. I am fan of Mozilla Firefox from years but this browser now have a lot of problems with loading websites. I hope that you will change your mind.

Yours faithfully,
Piotr

Comment 12

[Piotr]

[Tracking Requested - why for this release]:

Comment 13

[Daniel Bodea [:danibodea]]

Hello Piotr! Unfortunately, I can't figure out what exactly it is you are seeing wrong with the loading of these pages.

Please detail what you see differently from another browser. They always load correctly in my case.
Some picture attachments with examples of good and bad rendering of pages might help me reproduce it locally.

• BTW, are you using Firefox Sync to log in to Firefox with your account before trying to reproduce? (moving all user data into the browser before attempting to reproduce? we might want to avoid this to see if it reproduces in a clean profile.)
• Do you have any addons installed on the profile you are able to reproduce?
• I've seen that you've already reproduced it in safe mode; please make sure that you did it correctly:
  https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems

Thanks!

Comment 14

[Daniel Bodea [:danibodea]]

(In reply to sdoca from comment #4)

I am also seeing issues with Firefox not loading websites that it was able to load last week without issue Either sites load very slowly (3-5 minutes) or won't load at all in Firefox 86 but load quickly in Edge and Chrome.

Example of site that will not load (secure connection failures after 3-5 mins):
https://www.alberta.ca/
https://www.scte.org/

Example site that take 3-5 minutes to load:
https://linuxfoundation.org/

Hi, sdoca!

1. Can you also provide some screenshots with web pages with good and bad versions of them?
2. It might be important to make sure it also reproduces in safe mode:
   https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems
3. Your issues are most probably different than the one you commented on. A new issue should be logged in this situation.
   Thanks!

Comment 15

[Daniel Bodea [:danibodea]]

I have managed to discover what the original issue is by comparing the build reported as affected to the behavior seen in Firefox ESR v78.10.1esr. It appears that a menu is not being displayed in the later versions of Firefox.

Exact steps to reproduce:

1. Open build.
2. Load https://allegro.pl/myaccount/newpayments_incoming.php#_=_
3. Step needed after stress testing the website: human confirmation/verification
   (Click the "Click to Verify" button and then drag the puzzle piece to match the image)
4. Click the "Login with Facebook" button and log in with a valid account.
   Observe: The "https://allegro.pl/myaccount/newpayments_incoming.php#_=_" is finally displayed.
   Expected result: A left-side menu with drop-down sections is displayed.
   Actual result: The left-side menu with drop-down sections is MISSING.

• Mozregression results:
  2021-05-17T14:18:39.746000: DEBUG : Found commit message:
  Bug 1656494 - Add tests for default browser notification bar. r=Gijs

Differential Revision: https://phabricator.services.mozilla.com/D87804

• This might be incorrect, so I have tried again:
  This time, I've set mozregression to reuse the profiles and all builds turned out as bad.

• Again:
  Bug 1671885 - Add a test case for ech retry r=necko-reviewers,dragana

Differential Revision: https://phabricator.services.mozilla.com/D97992

I do not know what influences these builds to render as GOOD/BAD inconsistently, but the lastes ESR appears to be consistently BAD and the latest Nightly as GOOD. NI me if I can still help.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Bug 1671885 sounds plausible?

Comment 17

[Kershaw Chang [:kershaw]]

Bug 1671885 should not be the root cause, since echConfig is not enabled at all. I also can't reproduce this locally. This web page looks the same on ESR and nightly to me.

Bodea, could you try to capture http logs on ESR and nightly?
Thanks.

Comment 18

[Piotr]

(In reply to Bodea Daniel [:danibodea] from comment #15)

I have managed to discover what the original issue is by comparing the build reported as affected to the behavior seen in Firefox ESR v78.10.1esr. It appears that a menu is not being displayed in the later versions of Firefox.

Exact steps to reproduce:

1. Open build.
2. Load https://allegro.pl/myaccount/newpayments_incoming.php#_=_
3. Step needed after stress testing the website: human confirmation/verification
   (Click the "Click to Verify" button and then drag the puzzle piece to match the image)
4. Click the "Login with Facebook" button and log in with a valid account.
   Observe: The "https://allegro.pl/myaccount/newpayments_incoming.php#_=_" is finally displayed.
   Expected result: A left-side menu with drop-down sections is displayed.
   Actual result: The left-side menu with drop-down sections is MISSING.

• Mozregression results:
  2021-05-17T14:18:39.746000: DEBUG : Found commit message:
  Bug 1656494 - Add tests for default browser notification bar. r=Gijs

Differential Revision: https://phabricator.services.mozilla.com/D87804

• This might be incorrect, so I have tried again:
  This time, I've set mozregression to reuse the profiles and all builds turned out as bad.

• Again:
  Bug 1671885 - Add a test case for ech retry r=necko-reviewers,dragana

Differential Revision: https://phabricator.services.mozilla.com/D97992

I do not know what influences these builds to render as GOOD/BAD inconsistently, but the lastes ESR appears to be consistently BAD and the latest Nightly as GOOD. NI me if I can still help.

Dear Mr Bodea Daniel,

1. BTW, are you using Firefox Sync to log in to Firefox with your account before trying to reproduce? (moving all user data into the browser before attempting to reproduce? we might want to avoid this to see if it reproduces in a clean profile.)

I don't use Firefox Sync. This is 100% clean profile.

2. Do you have any addons installed on the profile you are able to reproduce?

I don't have installed any addons. I have installed fresh and clean firefox without 3rd party programs and extensions.

3. I've seen that you've already reproduced it in safe mode; please make sure that you did it correctly:

I tried and I used safe mode correctly. I am 100% sure.

I noticed that only on my one machine I have often problem with this website. On others machines this issue also exist but very rare. So this can be problem with hardware compability with firefox? On other browsers I don't have problems. I updated also BIOS for my motherboard but this didn't help me.

Problem with above link from Allegro website is that this website can't load at all. Sometimes this loads partly (only top part of the website is loading). I can load sometimes this website but if I will refresh this website about ten or more times. Maybe I will be do some photos.

I hope that you fix it.

Comment 19

[Kershaw Chang [:kershaw]]

Hi Reporter,

Could you try to get the http log?
Note that the log file may contain cookies, so you could send the log directly to my email address.

Thanks.

Comment 20

[Daniel Bodea [:danibodea]]

(In reply to Bodea Daniel [:danibodea] from comment #15)

I do not know what influences these builds to render as GOOD/BAD inconsistently, but the latest ESR appears to be consistently BAD and the latest Nightly as GOOD. NI me if I can still help.

Sorry, but I hope you've noticed that I meant it the other way around, as the flags show: ESR is consistently unaffected while Nightly is consistently affected.

(In reply to Kershaw Chang [:kershaw] from comment #17)

Bug 1671885 should not be the root cause, since echConfig is not enabled at all. I also can't reproduce this locally. This web page looks the same on ESR and nightly to me.

Bodea, could you try to capture http logs on ESR and nightly?
Thanks.

Yes, attempting it now.

Comment 21

[Daniel Bodea [:danibodea]]

Firstly, I have to mention that I have performed the repetitive reproduction attempt with mozregression by importing all data from Chrome to save time by not typing in the Facebook password manually and this might have influenced the reproduction of the issue.

I have attempted to reproduce the same issue in the latest Nightly by introducing the Facebook credentials manually and it did not reproduce.
Here is the networking log for the action: https://drive.google.com/file/d/1MaJmDdGI_SXmYePuyHco52ixr14Qfl_f/view?usp=sharing

This being considered, I will use my exact previous steps to attempt to reproduce it in the same Nightly build.
It did not reproduce. Log: https://drive.google.com/file/d/1UcaCGa-YNSq6BzGJlxPHu46b8nBC0ctb/view?usp=sharing

It appears I can't seem to be able to reproduce it today in the latest Nightly. Fortunately, I have managed to reproduce it in Beta v89.0b13.
Networking logs: https://drive.google.com/file/d/1O8mqxefQMaPgxx4Cnc9F3nkFnoT15BO9/view?usp=sharing

One last try to identify a "fix" between FX90 and FX89 using mozregression:
Bug 1700850 - Part 2: Remove temporary background profile directories very late. r=dthayer

When --backgroundtask TASK invocations exit, they try to remove
their temporary profile directory. This mostly works, except there
are some very late writes to the profile directory including
Telemetry.ShutdownTime.txt and the security_state directory. This
commit accommodates by moving the profile directory removal even
later. It might be possible to instead avoid these very late writes,
but that is hard in general, and is more likely to depend on the exact
code invoked by the background task itself.

Differential Revision: https://phabricator.services.mozilla.com/D110472

I have to say that the previously set flags might be incorrect.
Hope my information helps determine the cause. If not, feel free to ask for more.

Comment 22

[Kershaw Chang [:kershaw]]

(In reply to Bodea Daniel [:danibodea] from comment #21)

Firstly, I have to mention that I have performed the repetitive reproduction attempt with mozregression by importing all data from Chrome to save time by not typing in the Facebook password manually and this might have influenced the reproduction of the issue.

I have attempted to reproduce the same issue in the latest Nightly by introducing the Facebook credentials manually and it did not reproduce.
Here is the networking log for the action: https://drive.google.com/file/d/1MaJmDdGI_SXmYePuyHco52ixr14Qfl_f/view?usp=sharing

This being considered, I will use my exact previous steps to attempt to reproduce it in the same Nightly build.
It did not reproduce. Log: https://drive.google.com/file/d/1UcaCGa-YNSq6BzGJlxPHu46b8nBC0ctb/view?usp=sharing

It appears I can't seem to be able to reproduce it today in the latest Nightly. Fortunately, I have managed to reproduce it in Beta v89.0b13.
Networking logs: https://drive.google.com/file/d/1O8mqxefQMaPgxx4Cnc9F3nkFnoT15BO9/view?usp=sharing

Thanks for the log, but unfortunately, I can't find anything wrong from the log. It seems all http requests were succeeded.

One last try to identify a "fix" between FX90 and FX89 using mozregression:
Bug 1700850 - Part 2: Remove temporary background profile directories very late. r=dthayer

When --backgroundtask TASK invocations exit, they try to remove
their temporary profile directory. This mostly works, except there
are some very late writes to the profile directory including
Telemetry.ShutdownTime.txt and the security_state directory. This
commit accommodates by moving the profile directory removal even
later. It might be possible to instead avoid these very late writes,
but that is hard in general, and is more likely to depend on the exact
code invoked by the background task itself.

Differential Revision: https://phabricator.services.mozilla.com/D110472

I'll ni the author of bug 1700850 to have a look, although it seems unlikely that bug 1700850 is the cause.

Comment 23

[Nick Alexander :nalexander [he/him]]

(In reply to Kershaw Chang [:kershaw] from comment #22)

(In reply to Bodea Daniel [:danibodea] from comment #21)

Firstly, I have to mention that I have performed the repetitive reproduction attempt with mozregression by importing all data from Chrome to save time by not typing in the Facebook password manually and this might have influenced the reproduction of the issue.

I have attempted to reproduce the same issue in the latest Nightly by introducing the Facebook credentials manually and it did not reproduce.
Here is the networking log for the action: https://drive.google.com/file/d/1MaJmDdGI_SXmYePuyHco52ixr14Qfl_f/view?usp=sharing

This being considered, I will use my exact previous steps to attempt to reproduce it in the same Nightly build.
It did not reproduce. Log: https://drive.google.com/file/d/1UcaCGa-YNSq6BzGJlxPHu46b8nBC0ctb/view?usp=sharing

It appears I can't seem to be able to reproduce it today in the latest Nightly. Fortunately, I have managed to reproduce it in Beta v89.0b13.
Networking logs: https://drive.google.com/file/d/1O8mqxefQMaPgxx4Cnc9F3nkFnoT15BO9/view?usp=sharing

Thanks for the log, but unfortunately, I can't find anything wrong from the log. It seems all http requests were succeeded.

One last try to identify a "fix" between FX90 and FX89 using mozregression:
Bug 1700850 - Part 2: Remove temporary background profile directories very late. r=dthayer

When --backgroundtask TASK invocations exit, they try to remove
their temporary profile directory. This mostly works, except there
are some very late writes to the profile directory including
Telemetry.ShutdownTime.txt and the security_state directory. This
commit accommodates by moving the profile directory removal even
later. It might be possible to instead avoid these very late writes,
but that is hard in general, and is more likely to depend on the exact
code invoked by the background task itself.

Differential Revision: https://phabricator.services.mozilla.com/D110472

I'll ni the author of bug 1700850 to have a look, although it seems unlikely that bug 1700850 is the cause.

Oh hai! I am said author, and there's no plausible link between Bug 1700850 and this behaviour. That ticket impacts Firefox only when run with a --backgroundtask ... command line parameter; it doesn't impact page load (or other browsing profile related things, like the cache) at all.

At first blush, this looks like the impacted page itself might have a race condition in its JS that Firefox triggers more frequently than other browsers. I.e., setTimeout differences or a similar thing. Sorry I can't be more help!

Comment 24

[Piotr]

In next few weeks I will change my network operator so I will have sure if it is problem with firefox. Now my bug is still exist. I can't load this website. I can't send to Mr Bodea my cookies files for security reason. I am very sorry.

If it is bug with firefox I think that this problem can have more than one people.

I hope that this will be fixed in the future.

Comment 25

[Piotr]

This is very strange but today I don't have issue with load this website: https://allegro.pl/myaccount/newpayments_incoming.php

This can be problem with internet provider or you did some changes with last firefox update? Today firefox worked well when I visited above website. I can't reproduce this issue anymore today. I will check this tommorow. If it will be the same result this mean that some update fixed it. I also did Windows update but I think that this was problem with firefox and now last update fixed it or problems with internet provider. In next weeks I will change internet provider so I am optimist that this not happen again.

Comment 26

[Piotr]

I can confirm that now this website work for me without issue: https://allegro.pl/myaccount/newpayments_incoming.php

I checked also with older firefox version like 85.0 and 88.0 and of course 89.0 and on each of them website works without issue. This wasn't problem with firefox because earlier I had problems with this website on each version of firefox. Probably this was problem with my internet provider or of this website itself because like I said this work fine. I can close this subject now because everything works fine.

Thanks for your help guys!

All the best for you!

Comment 27

[Emilio Cobos Álvarez (:emilio)]

Well, glad to hear!