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

Expected results:

The page is blank, but the buttons and links work.

Nightly 88.0a1 (2021-02-27) (64-bit)
Operating System: openSUSE Tumbleweed 20210223
KDE Plasma Version: 5.21.0
KDE Frameworks Version: 5.79.0
Qt Version: 5.15.2
Kernel Version: 5.10.16-1-default
OS Type: 64-bit
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-4810MQ CPU @ 2.80GHz
Memory: 31.0 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 4600

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

If you try to select the (invisible) text what happens? What happens if you click the copy raw or copy text to clipboard? I'm trying to determine if the page failed to populate text or there is some graphical issue with not drawing the text that is in the page.

Here is what I get with a ctrl+a.

This is from 86.0

Why are we not able to delete on this page. ;-((

Can you use the copy raw/text buttons to clipboard and see if the text is in there or not?

Copy Raw does nothing. Copy text to clipboard works, but no data.

Application Basics

Name:
Version:
Build ID:
Distribution ID:
Update Channel:
User Agent:
OS:
Multiprocess Windows:
Fission Windows:
Remote Processes:
Enterprise Policies:
Google Location Service Key:
Google Safebrowsing Key:
Mozilla Location Service Key:
Safe Mode:

Crash Reports

Nightly Features

Remote Features

Remote Processes

Add-ons

Security Software

Type:

Type:

Type:

Graphics

Features
GPU #1
GPU #2
Diagnostics
Decision Log
Crash Guard Disabled Features
Workarounds
Failure Log

Media

Output Devices
Name: Group
Input Devices
Name: Group
Media Capabilities
Enumerate database

Environment Variables

Experimental Features

Remote Experiments

Important Modified Preferences

Important Locked Preferences

Places Database

Accessibility

Activated:
Prevent Accessibility:

Library Versions

Sandbox

Rejected System Calls

Startup Cache

Disk Cache Path:
Ignore Disk Cache:
Found Disk Cache on Init:
Wrote to Disk Cache:

Internationalization & Localization

Application Settings
Requested Locales:
Available Locales:
App Locales:
Regional Preferences:
Default Locale:
Operating System
System Locales:
Regional Preferences:

Remote Debugging (Chromium Protocol)

Accepting Connections:
URL:

Printing

Modified print settings

If you run firefox from a terminal do you get any error output that might be related?

No errors. If you want to get on and drive we can use Anydesk.com, no install needed on Windows just run.

Just for S&Gs I downloaded Nightly to another folder and it works. I also ran my regular Nightly in Safe Mode, but still the same issue.

When you run nightly from a different folder you are using your same profile?

No, I did not log into it.

Can you goto about:support and then to the menus
Tools, Web Developer, Browser Console
and
Tools, Web Developer, Web Developer Tools, Console
and see if there are any errors in there?

Here ya go. ;-))
Not sure how to include the message under the errors, but here is a screenshot also.

Michael, can you take a look at this please?

The critical error seems to the following, which is called from Troubleshooting.jsm:

19:07:20.206 TypeError: can't convert undefined to object PreferenceExperiments.jsm:877:19

It seems like some of the data invariants for Normandy's PreferenceExperiment storage aren't true. We should probably be robust to this kind of failure, but I'd like to know how this profile got into this state.

jonzn, in your Firefox profile, there should be a file shield-preference-experiments.json. Can you attach that file here? Note that in that file there are identifiers that are similar to Client ID, under the key enrollmentId. If you'd prefer, you can remove those values from the file (if they are present).

Additionally , can you report what the value of the preference app.normandy.migrationsApplied is?

The file is corrupt and empty for the Nightly with no troubleshooting info.

This is the file for the 2nd Nightly that works and I did not log into my Firefox account.

Should I just copy the files from my 2nd Nightly into my daily driver Nightly to fix the issue?

Copying that file over to the broken profile should fix this problem. Sorry for the issues there.

It seems like Normandy needs to handle this data getting corrupted/deleted more effectively. That seems like a simple thing to fix to avoid this for other people in the future.

All is well. Thanks ;-))

Hi
i was not able to replicate this on ubuntu 20 on nightly 88.0a1.

Since it is working well for you now i will resolve the issue

thanks

Thanks for verifying this Pablo, however the issue here is a pretty clear lack of error handling in the code that we should fix. I'm going to re-open that to handle fixing that problem.

When there is a failure to load the experiments store, Normandy now simply
resets the store back to an empty set which is generally a safe operation.
Being resilient to errors here is especially important now that about:support
shows data from Normandy. Errors in loading data for about:support can cause
the entire page to be blank, blocking critical support information.

This is a safe operation from a clients point of view because withouot this
information Normandy will assume that no clients should be enrolled. It may
take a restart, but eventually it will reset the client back to default if
there are I/O errors.

https://hg.mozilla.org/mozilla-central/rev/a571d69735d9

Please nominate this for Beta approval when you get a chance. Maybe a decent dot release ride-along candidate too.

Comment on attachment 9211143 [details]
Bug 1695451 - Handle I/O Errors when loading Normandy preference experiments r=gijs

Beta/Release Uplift Approval Request

• User impact if declined: If storage files for Normandy Preference experiments become unreadable or are removed, then about:support will show a mostly blank page. Headers will still be present, but none of the data will fill in.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Start with Firefox shut down

2. Make shield-preference-experiments.json in the profile directory invalid by either
   a) deleting it,
   b) modifying the file to not be valid JSON, or
   c) modifying the file to be valid JSON but not have a top level experiments key (such as making the document an empty object, {}).
3. Start Firefox and navigate to about:support.

Expected: About support works, and the Normandy sections are blank (Remote Features and Remote Experiment Experiments).

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This adds additional error checking to Normandy and about:config. It does not affect the normal path of execution. If there is a problem, the impacted areas will be minimal (Normandy and about:support).
• String changes made/needed:

Comment on attachment 9211143 [details]
Bug 1695451 - Handle I/O Errors when loading Normandy preference experiments r=gijs

Approved for 88.0b5.

https://hg.mozilla.org/releases/mozilla-beta/rev/484e9aedc4a1

I have verified that the issue is no longer reproducible on the latest Nightly 89.0a1 (Build ID 20210331092207) and Firefox Beta 88.0b5 (Build ID 20210330185720) using Windows 10 x64, macOS 11.1.2, and Linux MX 4.19.
I've verified that the about:support page displays data in all cases mentioned in comment 32: deleting the file, modifying it to no longer be a valid JSON, modifying it to no longer have the top level "experiments" key, and modifying the file to have a different extension than JSON.

Comment on attachment 9211143 [details]
Bug 1695451 - Handle I/O Errors when loading Normandy preference experiments r=gijs

88 is in RC now and there are no plans for an 87 dot release.