Open Bug 1582686 Opened 5 years ago Updated 2 years ago

Expose specfic network-related update errors to the user outside of the browser console log

Categories

(Toolkit :: Application Update, enhancement, P3)

71 Branch
enhancement

Tracking

()

People

(Reporter: mozilla, Unassigned)

Details

Attachments

(2 files)

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

Steps to reproduce:

Run Nightly.

These are official mozilla builds, extracted in home directory: /home/duclare/firefox/nightly/firefox

$ ls -lahd firefox/nightly/firefox/
drwxr-xr-x 9 duclare duclare 4.0K Sep 20 11:49 firefox/nightly/firefox/

Every file in profile & firefox directory is writable:

$ find ~/.mozilla/firefox/28ysncuu.default/ ! -perm -600 | wc -l
0

$ find ~/firefox/nightly/ ! -perm -600 | wc -l
0

There is no shortage of disk space either, with 57GB of free space available on the partition with the home directory and 4 GB under /tmp.

Actual results:

Nightly keeps giving a popup every two hours: "Nightly can't update to the latest version" and prompts me to download and install a new version manually. I did that, but the same behavior continues.

Expected results:

Nightly should just update itself like it used to. If it really can't, it should tell me why it can't so I can attempt to fix the problem. And it most certainly shouldn't bombard me with that same popup every two hours.

Component: Untriaged → Application Update
Product: Firefox → Toolkit

Okay, let's see if we can figure out what's going on. Permissions are indeed the most common way that this problem happens, so thanks for ruling out that and also disk space up front. Collecting some of the updater logs might tell us where to start looking. Can you look in ~/firefox/nightly/updates/ for a file called last-update.log, and in ~/firefox/nightly/updates/0/ for an update.log and attach whichever of those exist? Hopefully those will have some meaningful errors in them. Thanks.

Flags: needinfo?(mozilla)
Attached file last-update.log

Attached last-update.log, which was last modified a week ago, roughly when the problem started. Popups prompting to download manually are still happening.

updates/0/ is an empty directory.

Flags: needinfo?(mozilla)

Okay, thanks. That means we aren't getting far enough to attempt actually applying an update, which is a bit surprising and means we need to look at a different log from earlier in the process, when Firefox is downloading and trying (but apparently failing) to start running the update. Here's the detailed steps for how to collect those log entries:

  1. Type about:config in the URL bar and press return
  2. Click through the warning if one is displayed
  3. Type app.update.log in the search box
  4. Toggle the value from false to true by either double clicking it or via the context menu.
  5. Restart Firefox
  6. Open the Browser Console by pressing Ctrl+Shift+J or selecting the item from the Web Developer menu.
  7. Open the About dialog box (to trigger an update check)
  8. In the Browser Console window, type AUS:SVC into the filter box at the top. Copy and paste the messages that remain in the console window here.

Thanks again.

Flags: needinfo?(mozilla)
Attached file nightly-update.txt

Great, looks like a hostname resolution issue. My DNS server is fine but aus5.mozilla.org seems to have a good number of IPv6 addresses.. I'm guessing a braindead resolver somewhere (glibc? Or does Firefox use its own?) has been deciding to priorize those, even though I have no IPv6 connectivity to the world at large. Looks like similar issues have plagued glibc's resolver since 2006 and there's no way to toggle AAAA queries off without touching the source code.

I don't know what happened, Firefox has finally managed to resolve and download an update somehow, but getent hosts aus5.mozilla.org still only returns IPv6 addresses and ping aus5.mozilla.org gives Temporary failure in name resolution while IPv6 is turned off in kernel (via sysctl) and I have no v6 addresses.

dig @192.168.1.1 aus5.mozilla.org and host aus5.mozilla.org return perfectly good A records from the server that is specified in /etc/resolv.conf. ping also results in a query to the same server and according to tcpdump, it gets its A records just fine..

I think I'm going to go buy a BSD :(

As far as I'm concerned, this bug is invalid, although I still think it would be very nice if there were a way for the user to learn what went wrong without involving a bug report, about:conf tweaking and the developer console. Or at least the steps required to get logs could be documented somewhere? Maybe they are and my Google-fu just didn't bring up anything useful; only people blindly guessing whether it might be permissions or the moon phase.

Flags: needinfo?(mozilla)

Ooooh, okay. I'm not a network expert, but I think we do always use our own resolver, and I see that there's a pref called network.dns.ipv4OnlyDomains which takes a comma-separated list of domains to only return IPv4 addresses for, so you might be able to get somewhere with that, or some of the other DNS prefs.

As far as I'm concerned, this bug is invalid, although I still think it would be very nice if there were a way for the user to learn what went wrong without involving a bug report, about:conf tweaking and the developer console. Or at least the steps required to get logs could be documented somewhere? Maybe they are and my Google-fu just didn't bring up anything useful; only people blindly guessing whether it might be permissions or the moon phase.

You've got a point here, there's room for some UX work around getting this kind of error info. I'll leave the bug open and change the summary to be about that. I will say I don't expect this to get a high priority because I don't think there's a lot of users who hit errors of this kind and also would understand what to do to correct them when they happen.

Status: UNCONFIRMED → NEW
Type: defect → enhancement
Ever confirmed: true
Summary: Nightly can't update to the latest version → Expose specfic network-related update errors to the user outside of the browser console log
Priority: -- → P3

As far as app update is concerned. I suspect that for our average client we just want to ask the client to install the latest version as we already do. For clients that hit this error I think a more general fix along the lines of bug 1536580.

Matt, what do you think?

Flags: needinfo?(mhowell)

What I had in mind is storing these errors to be displayed in something like the update history window where you have to go look it up, not in the doorhanger message. I do agree that bug 1536580 would be the more impactful effort.

Flags: needinfo?(mhowell)

(In reply to Robert Strong [:rstrong] (Robert they/them - use needinfo to contact me) from comment #6)

I suspect that for our average client we just want to ask the client to install the latest version as we already do.

The other thing I was left wondering about is whether the frequency of that message should be reduced. IIRC it wakes up the screen every time and it's not like there are going to be new updates every two hours or so. It got a bit irritating at some point.

Firefox Product and Release Management decided that they want nightly testers using the latest asap which is why it happens so often on nightly. I brought this up recently and hopefully it will be evaluated though even after analysis the choice might very well be the same.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: