1471824 - Unable to open any webpage after upgrading to version 61

Status: RESOLVED FIXED

(Firefox :: Untriaged, defect)

Description

[yxu]

Attachment: web page loading

After upgrading to version 61, we received a lot of user feedback from China. They visit any web page that is in a loading state and the page is blank.[see attachment]

There is no problem with the user's network. Other browsers access the Internet normally. There is no special software or firewall installed in the background. All users with this problem use the Windows system.

This issue occurs with both 32-bit and 64-bit versions of 61, and it works as normal when they downgraded to 60.

Methods that have been tried:

We have let users try to modify sanity-test.running to true, layout.display-list.retain to false, browser.tabs.remote.warmup.enabled to false and didn't work.

Hardware acceleration has no effect.

Because this problem can only be reproduced on the user's device, is there a simple way to obtain the information we need? We can contact the user to operate and upload the result to this bug. One user is willing to help with the regression test but need to wait until tomorrow.

Comment 1

[Hector Zhao [:hectorz]]

(In reply to yxu from comment #0)
> 
> We have let users try to modify sanity-test.running to true,

For one of the affected users, we noticed the gfx sanity test window won't go away, so we tried to skip the test with this.

> layout.display-list.retain to false,
> browser.tabs.remote.warmup.enabled to false
> and didn't work.

These two were tried only because they were mentioned as new features in Fx 61

Also, it's possible to open a few about:* pages like about:preferences directly from menu buttons, while entering about:* urls into address bar doesn't work.

Comment 2

[yxu]

Currently found if 'Prevent accessibility services from accessing your browser' in 'Privacy & Security' is checked, then users with previous problem use normal.

Because of 'Accessibility Instantiator' in about:support shown as 'UNKNOWN|', It is currently not possible to determine which accessibility tool is causing this problem.

Comment 3

[yxu]

Also modifying browser.tabs.remote.autostart and browser.tabs.remote.autostart.2 in about:config to false can also solve this problem (without checking the option in Comment 2).

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Jamie or Aaron, are you aware of any a11y changes in the 61 timeframe that might be related here? Sounds like workarounds so far are turning off accessibility or disabling e10s.

Comment 5

[(No longer employed by Mozilla) Aaron Klotz]

I haven't done any a11y work on 61.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

A regression range from mozregression would be extremely helpful here.

Comment 7

[James Teh [:Jamie]]

The only thing that comes to mind is bug 1364624, which originally caused some pretty serious breakage. However, that was fixed in bug 1459085, which also got uplifted to 61. So, I don't see how this could be the cause now, but I mention it anyway because it seems like similar nasty breakage.

I tried installing 61 on Windows 10 and running with accessibility, but everything works as expected for me.

What versions of Windows are these users running?

It would be helpful to know what happens if you set the pref accessibility.handler.enabled to false. That's not a "fix", as it will make accessibility ridiculously slow for some tools, but the findings might be enlightening.

Note that using mozregression unfortunately doesn't allow you to test accessibility properly, as accessibility requires a component to be installed on the system (via registry entries). Effectively, using mozregression is like having accessibility.handler.enabled set to false. If setting that to false has no impact, using mozregression should be just fine to track down the issue.

Comment 8

[yxu]

(In reply to James Teh [:Jamie] from comment #7)
> What versions of Windows are these users running?
Both win7 or win10 appear. 

> It would be helpful to know what happens if you set the pref
> accessibility.handler.enabled to false. That's not a "fix", as it will make
> accessibility ridiculously slow for some tools, but the findings might be
> enlightening.
This is non't useful. The performance is the same as before, and no suspicious reasons are found at the same time.

> If setting that to false has no impact, using mozregression should be just fine
> to track down the issue.
Unexpected performance here. When I use mozregression to download version 60 and run, any page crashes(not loading state or blank). But download 61 version can run normally. 

I can only look for a bug fix instead of a regression then got:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=359cecde7c3ea604dc7f55ae958b9de420924f44&tochange=c36098a8e83f0238196d0bfbaad1f81ae84ae28e

This regression test does not match the actual problem, so mozregression has no effect.

I also let users try exe or zip packages of nightly 60 and 61. The result is there is a page crash when the user install the 60 version and 61 version is used normally. Same result as mozregression.

The user install beta 61.0b3 and it works fine.

To sum up, the user can't reproduce this bug when they use beta or nightly version 61. However, it still exists when using release version. The difference can be thought of is that his release version is installed in the default path, C:\Program Files\Mozilla Firefox, beta and nightly are custom paths. I'm not sure if this will lead to the problem. We still need other users help us test.

Comment 9

[[:philipp]]

could someone affected test, if the issue wasn't present in 61.0b5 and started in 61.0b6? this was the timeframe when bug 1364624 got uplifted to the beta channel, in case it is related... 
(also see bug bug 1472137, which noticeably skews toward chinese builds)

Comment 10

[yxu]

(In reply to [:philipp] from comment #9)
> could someone affected test, if the issue wasn't present in 61.0b5 and
> started in 61.0b6? this was the timeframe when bug 1364624 got uplifted to
> the beta channel, in case it is related... 
> (also see bug bug 1472137, which noticeably skews toward chinese builds)

Two users helped test the 61b5 and 61b6 versions(win64 zh-CN). The performance is 61b5 is normal and 61b6 start until the latest beta version 62b4 are not normal.

I think it may be related to the bugs mentioned above.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

yxu, below are links to what will eventually turn into the Fx 61.0.1 release builds. It would be fantastic if you could get affected users to try them out to verify that things are better with them :-)

Win32: https://queue.taskcluster.net/v1/task/BGh_SoO5RIesKCHDL3E6Dw/runs/0/artifacts/public/build/target.installer.exe
Win64: https://queue.taskcluster.net/v1/task/JG0hm9NcQk6UZTnxR2F8yA/runs/0/artifacts/public/build/target.installer.exe

Comment 12

[yxu]

(In reply to Ryan VanderMeulen [:RyanVM][PTO July 4-9] from comment #11)
> yxu, below are links to what will eventually turn into the Fx 61.0.1 release
> builds. It would be fantastic if you could get affected users to try them
> out to verify that things are better with them :-)
> 
> Win32:
> https://queue.taskcluster.net/v1/task/BGh_SoO5RIesKCHDL3E6Dw/runs/0/
> artifacts/public/build/target.installer.exe
> Win64:
> https://queue.taskcluster.net/v1/task/JG0hm9NcQk6UZTnxR2F8yA/runs/0/
> artifacts/public/build/target.installer.exe

There is no problem after installing these two versions.

Comment 13

[Julien Cristau [:jcristau]]

Calling this fixed in 61.0.1 based on comment 12.