Closed Bug 1513571 Opened 1 year ago Closed 1 year ago

“Hmm. We’re having trouble finding that site” issue with Firefox ESR 60

Categories

(Core :: Networking: DNS, defect, P2)

60 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1494364

People

(Reporter: marius.tarlo, Unassigned)

References

Details

(Keywords: regression, regressionwindow-wanted, Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36

Steps to reproduce:

Hello,

I work for Orange, a French company, which has a IT infrastructure of ~100K computers.

We’ve just deployed Firefox ESR 60 on ~8000 computers (the other computers are still in version ESR 52), and we have implemented the GPO.
We have a negative feedback from some users who encounter disconnections while browsing the internet.

At first they can browse normally, but after a while, the users see the following error : “Hmm. We’re having trouble finding that site” with the little character in blue on the left with his map.
And they need to close and relaunch Firefox.

We’ve found a website where it’s easy to reproduce the issue (www.lequipe.fr, a French sports news website), it may obviously occur on other sites but we’ve performed our tests on this one. 
If we just open this website and let it open without doing anything for some while, the error message appears.

For the internet and intranet connection, we use a proxy .pac file (somewhat complex, with ~300 lines).
Even if we use a simplified version of our proxy.pac file (just the 2 lines to define the variables for the proxy servers and one line like this : return  var_proxy_nom + ";" + var_proxy_bkp + "; DIRECT; " ;), we still encounter the issue

After performing some cross-testing, we’ve found the following:
- if we set Firefox to use the proxy system settings like we did at first, we encounter the issue (on Internet Explorer there is the same proxy .pac address)
- if we set Firefox to use the automatic proxy configuration address and put the proxy .pac address in the field, we encounter the issue as well
- but if we set Firefox to use the manual configuration, and here we set a proxy server address with port 8080, then it works, the issue does not appear
- (we tried other things like disabling IPV6, disabling DNS Prefetch, repairing the profiles, with or without the GPO, the policies.json file, etc. but all of these wasn’t relevant, the issue continued to appear after each of these tests)

Unfortunately, on a large scale, we cannot implement this third solution, we must find a way to make it work with our proxy .pac address.

On previous versions of Firefox like Firefox ESR 52 or lower: no issue
On Internet Explorer 11: no issue as well

Could you help us please ?
Thank you very much
Component: Untriaged → Networking: DNS
Keywords: regression
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hi Marius,

I can't reproduce your issue without some kind of working test case. I am guessing that the original proxy.pac file is not sharable. Can you provide a similar proxy.pac file, maybe a mock one with which we could reproduce the issue? Also, a tutorial on how to use it.

If this is not possible, then we would like you to perform some regression tests to help address this bug.
1. Firstly, we need to know whether this issue reproduces while using the Nightly browser.
Please download the latest Nightly browser, install it, set it up the way you set up the Firefox ESR60 version and retest it.
Go to the "about:support" page and copy/write down the Build ID.

2.1.1 If the issue reproduces in the latest Nightly, next, you need to find an older version of Nightly where the issue does not reproduce. Considering that it did not reproduce in ESR52, then you should probably try Nightly v63, down to Nightly v56 or older.
This means you should download Nightly builds released between 25th of June 2018 and 12th of June 2017 or older. Find one build that does NOT reproduce the issue, go to the "about:support" page and copy/write down the Build ID.
You can find the builds here, arranged by date: http://archive.mozilla.org/pub/firefox/nightly/
2.1.2 Next, you need to install the mozregression tool: https://mozilla.github.io/mozregression/install.html
There are 2 forms of the tool: the GUI version and the terminal version. Install any of them; the GUI version is probably easier to use.
2.1.3 You need to run a regression on your issue. To start a mozregression test, you need to know how to set it. In this case, you need to know the bad build ID (the ID of the latest Nightly Build if the issue reproduced in the latest Nightly) and the good build ID (the ID of the build which did NOT reproduce the issue). You will use this info in the "Build selection" screen from the GUI mozregression tool. 
ALSO, I am not sure how you set the proxy settings normally, but you will need to set them from the mozregression tool or from the OS lever/third-party app (preferably from the OS in this case).
2.1.4 Then, several builds will open one by one, you have to test the build and determine whether it is a bad build (reproduces the issue) or a good build (does not reproduce the issue).
2.1.5 After all the builds are being run and tested, please take the results and paste them here.

2.2.1 If the issue does NOT reproduce in Nightly, it means that the issue was already fixed in Nightly (most probably by accident). In this case, you will need to find an older version of Nightly in which the issue DOES reproduce to run the mozregression tool with the option to "find fix". 
This means you should download Nightly builds released between the current day (last Nightly) and 12th of June 2017. Find one build that does NOT reproduce the issue, go to the "about:support" page and copy/write down the Build ID.
You can find the builds here, arranged by date: http://archive.mozilla.org/pub/firefox/nightly/
2.2.2 Next, you need to install the mozregression tool: https://mozilla.github.io/mozregression/install.html
There are 2 forms of the tool: the GUI version and the terminal version. Install any of them; the GUI version is probably easier to use.
2.2.3 You need to run a regression on your issue. To start a mozregression test, you need to know how to set it. In this case, you need to know the bad build ID (the ID of the build which DID reproduce the issue) and the good build ID (the ID of the latest Nightly Build if the issue did NOT reproduce in the latest Nightly). You will use this info in the "Build selection" screen from the GUI mozregression tool. Alsom you will need to check the "Search for fix" checkbox from the Build selection screen.
2.2.4 Then, several builds will open one by one, you have to test the build and determine whether it is a bad build (reproduces the issue) or a good build (does not reproduce the issue).
2.2.5 After all the builds are being run and tested, please take the results and paste them here.

This should be the entire regression process explained. Please try to regress your issue and contact me if there's anything I can help with.

Thank you for your contribution.
Flags: needinfo?(marius.tarlo)
Thanks Daniel for your comment,

You guess right, I cannot share our real proxy.pac file, but we can reproduce the issue with some simple one like this :
function FindProxyForURL(url, host)
{
	return "PROXY <master_proxy_addr>:3128; PROXY <backup_proxy_addr>:3128; DIRECT" ;
}

I will follow what you suggest with the Nightly and mozregression and keep you in touch

Thank you very much
Flags: needinfo?(marius.tarlo)
Junior, can you take a look?
Priority: -- → P2
Whiteboard: [necko-triaged]
Hello,

I've followed the methodology suggested by Daniel Bodea and I've found the following (FYI, at first Nightly crashed when I tried to browse any website, but I've fixed that issue by deleting my Firefox user profile) :

Nightly version 58.0a1 build 20171017141229 and previous : doesn't reproduce the issue
Nightly version 58.0a1 build 20171017220415 to Nightly 65.0a1 20181105220107 : does reproduce the issue
Nightly version 65.0a1 build 20181106100114 and later : doesn't reproduce the issue

I've tried to use mozregression but I get the following error message :

platform: Windows-10-10.0.16299
python: 2.7.15 FROZEN (32bit)
mozregui: 0.9.35
mozregression: 2.3.37
message: ProxyError: HTTPSConnectionPool(host='api.github.com', port=443): Max retries exceeded with url: /repos/mozilla/mozregression/releases/latest (Caused by ProxyError('Cannot connect to proxy.', error('Tunnel connection failed: 407 Proxy Authentication Required',)))
traceback:   File ".\mozregui\check_release.py", line 20, in run
  File "..\mozregression\network.py", line 27, in retry_get
  File "C:\Python27\lib\site-packages\redo\__init__.py", line 162, in retry
  File "C:\Python27\lib\site-packages\requests\api.py", line 75, in get
  File "C:\Python27\lib\site-packages\requests\api.py", line 60, in request
  File "C:\Python27\lib\site-packages\requests\sessions.py", line 524, in request
  File "C:\Python27\lib\site-packages\requests\sessions.py", line 637, in send
  File "C:\Python27\lib\site-packages\requests\adapters.py", line 510, in send

I've tried to install Python 2.7.15 but I get the same error

Would you be able to find where the issue can come from with the Nightly builds I've provided above ?
Or must I make mozregression work in order to point out exactly where the bug comes from ?

Thank you very much
That should be good enough.

Using about:buildconfig to determine revisions, I think the window is:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f27105b62753c71ecadad2f8d632ec7e5ac96bbd&tochange=f78d5947333422ab09ec23e3dab0d48538c9d6ad

But I see nothing there that jumps out at me.

As far as your mozregression error, it appears proxy related. Like mozregression can't retrieve the builds through the proxy.
I forgot to need-info Junior: comment #3 and look at comment #4, try to find out what has fix this between 20181105220107 and 
20181106100114
(In reply to Marius Tarlo from comment #4)
> Hello,
> 
> I've followed the methodology suggested by Daniel Bodea and I've found the
> following (FYI, at first Nightly crashed when I tried to browse any website,
> but I've fixed that issue by deleting my Firefox user profile) :
>

This i interesting. It is an unrelated problem. You have deleted that profile, as you wrote, so you cannot reproduce it?
(In reply to Dragana Damjanovic [:dragana] from comment #7)
> (In reply to Marius Tarlo from comment #4)
> > Hello,
> > 
> > I've followed the methodology suggested by Daniel Bodea and I've found the
> > following (FYI, at first Nightly crashed when I tried to browse any website,
> > but I've fixed that issue by deleting my Firefox user profile) :
> >
> 
> This i interesting. It is an unrelated problem. You have deleted that
> profile, as you wrote, so you cannot reproduce it?

Yes, when I downloaded a old version of Nightly (I didn't have this issue with the latest build) and tried to browse another website than my homepage, Nightly instantly closed, and I had the report window
I fixed that by deleting the Mozilla folder in C:\Users\<account>\AppData\Roaming
We suspect that something is wrong at the switch/router level, but we can't be sure. If possible, could you record a network log when the issue reproduces? Considering that the proxy configuration is not sharable, you should use the simplified version.

Take these steps:
1. Open the (affected) browser (preferably the latest ESR60 v60.4.0esr).
2. Go to "about:networking#logging"
3. Click on the "Start Logging" button.
4. Make note of the location of the log file displayed right below (Current Log File: ...)
5. Reproduce the issue (open some page that shows the error message in a new tab)
6. Go back the "about:networking#logging" tab.
7. Click the "Stop Logging" button (Before, make sure you made a note of the log file location)
8. Get the log file and attach it to this bug.

Thank you!
Flags: needinfo?(marius.tarlo)
I do not know why it is not setting a need-info for Junior, when I add it?

Junior, please look at comment #6
Flags: needinfo?(juhsu)
I believe it's bug 1494364.
An easy way to experiment is setting network.proxy.failover_timeout to 0 in about:config solves your problem.

Once verified, let us try to uplift that to ESR.

Hello Marius Tarlo,
Could you please verify in your side? Thanks.
Flags: needinfo?(juhsu)
If Marius can verify this works we may want to uplift for 60.5.0 ESR, or even for a potential dot release for 60.4.1.
Hello,

I've got a log file produced with the method of comment #9, but unfortunately it's too big to attach it here, do you have a way to upload it to you elsewhere ?

For the comment #11, yes the parameter network.proxy.failover_timeout to 0 seems to be a good workaround

Our proxy guys tell us that it seems that this parameter makes Firefox only target the main proxy server and not the backup, but at least we don't have the “Hmm. We’re having trouble finding that site” issue any more.

I will not be working next week so I wish to all of you a merry Christmas and a happy new year !
Flags: needinfo?(marius.tarlo)
Hi Marius,

I don't know if the network log file will help, considering the considering the workaround you just confirmed, but you can put the  file here: https://drive.google.com/drive/u/1/folders/1zfF59PGLSRyn9QoJfhcNzu7O5yXYAZAD

Thank you!
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #12)
> If Marius can verify this works we may want to uplift for 60.5.0 ESR, or
> even for a potential dot release for 60.4.1.

I'm worried to uplift for 60.4.1 since bug 1494364 is in beta for few weeks only.
Since the pref works per comment 6, I propose to uplift to 60.5
Sounds like a good plan! Can you request uplift to ESR? Thanks!
Flags: needinfo?(juhsu)
(In reply to Liz Henry (:lizzard) (PTO Dec 28) from comment #16)
> Sounds like a good plan! Can you request uplift to ESR? Thanks!

Bug 1494364 Comment 36
Flags: needinfo?(juhsu)
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1494364
You need to log in before you can comment on or make changes to this bug.