Bugzilla

(In reply to Sören Hentzschel from comment #11)
> (In reply to :Gijs (he/him) from comment #3)
> > I expect opening the about: dialog might also cause errors to show up for these users; Sören, can you check?
> 
> The ESR user checked the about dialog. Since the log from comment #0 was from another user (with Firefox 97) I asked the ESR user for the console output from both - opening the settings and the about dialog.
> 
> settings:
> 
> ```
> Error initializing preference category paneGeneral: TypeError: URL constructor:  is not a valid URL. preferences.js:277
>     gotoPref chrome://browser/content/preferences/preferences.js:277
>     AsyncFunctionThrow self-hosted:696
> Uncaught (in promise) TypeError: URL constructor:  is not a valid URL.  aboutDialog-appUpdater.js:47:19
>     appUpdater chrome://browser/content/aboutDialog-appUpdater.js:47
>     init chrome://browser/content/preferences/main.js:649
>     init chrome://browser/content/preferences/preferences.js:105
```

OK, so this part is a dupe of bug 1754409 (already fixed in 99, I guess we can ask for uplift). They've customized the manual update URL via about:config or a custom prefs file and this is upsetting things. It's a regression from bug 1747293 which got uplifted.

> ```
> Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/bildschirm.uc.js
> CustomizableUI is not defined bookmarks_backup_restore_button.uc.js:25
```

Uh, so they're running custom user chrome scripts that they or someone else wrote and those are breaking. I can't help with that.

At this point this bug is pretty confusing because it would appear that the two reports are not necessarily related. I'm confident that your last comment is from someone who is seeing the exact same thing as bug 1754409. They can work around locally by making the manual update URL something that does parse as a URL. This [comment from Kirk](https://bugzilla.mozilla.org/show_bug.cgi?id=1754409#c2) seems apt to me:

(Kirk Steuber (he/him) [:bytesized] from bug 1754409 comment #2)
> (In reply to Tynth from comment #0)
> > Normally i delete URL for option app.update.url.manual
> 
> Why do you want to be able to do this? I can't think of any reason to. It seems like the only real change this would cause is to break the link that Firefox shows you if an update fails. But if you don't want to use the link, can't you just not click on it? Why is it necessary to break it?
> 
> It's kind of inevitable that if you screw up your prefs enough, it will break things. And I would consider removing the manual update URL to be a form of screwing up your prefs.


Anyway, the logs in comment 0 (from the user on 97) do not really match the same issue, AFAICT. Do we have any more details from that user? The list of possible causes there is significantly longer because there were obviously more changes between 96 and 97. If the user can reproduce the problem with mozregression, that would be much the quickest way of finding out what the cause of their issue is. AFAICT their browser has no idea where to put updates, and this is breaking all sorts of things, including telemetry and (I'm guessing) further updates, so it seems pretty important to still find out what is going on there.

(In reply to Sören Hentzschel from comment #11)
> (In reply to :Gijs (he/him) from comment #3)
> > I expect opening the about: dialog might also cause errors to show up for these users; Sören, can you check?
> 
> The ESR user checked the about dialog. Since the log from comment #0 was from another user (with Firefox 97) I asked the ESR user for the console output from both - opening the settings and the about dialog.
> 
> settings:
> 
> ```
> Error initializing preference category paneGeneral: TypeError: URL constructor:  is not a valid URL. preferences.js:277
>     gotoPref chrome://browser/content/preferences/preferences.js:277
>     AsyncFunctionThrow self-hosted:696
> Uncaught (in promise) TypeError: URL constructor:  is not a valid URL.  aboutDialog-appUpdater.js:47:19
>     appUpdater chrome://browser/content/aboutDialog-appUpdater.js:47
>     init chrome://browser/content/preferences/main.js:649
>     init chrome://browser/content/preferences/preferences.js:105
> ```

OK, so this part is a dupe of bug 1754409 (already fixed in 99, I guess we can ask for uplift). They've customized the manual update URL via about:config or a custom prefs file and this is upsetting things. It's a regression from bug 1747293 which got uplifted.

> ```
> Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/bildschirm.uc.js
> CustomizableUI is not defined bookmarks_backup_restore_button.uc.js:25
```

Uh, so they're running custom user chrome scripts that they or someone else wrote and those are breaking. I can't help with that.

At this point this bug is pretty confusing because it would appear that the two reports are not necessarily related. I'm confident that your last comment is from someone who is seeing the exact same thing as bug 1754409. They can work around locally by making the manual update URL something that does parse as a URL. This [comment from Kirk](https://bugzilla.mozilla.org/show_bug.cgi?id=1754409#c2) seems apt to me:

(Kirk Steuber (he/him) [:bytesized] from bug 1754409 comment #2)
> (In reply to Tynth from comment #0)
> > Normally i delete URL for option app.update.url.manual
> 
> Why do you want to be able to do this? I can't think of any reason to. It seems like the only real change this would cause is to break the link that Firefox shows you if an update fails. But if you don't want to use the link, can't you just not click on it? Why is it necessary to break it?
> 
> It's kind of inevitable that if you screw up your prefs enough, it will break things. And I would consider removing the manual update URL to be a form of screwing up your prefs.


Anyway, the logs in comment 0 (from the user on 97) do not really match the same issue, AFAICT. Do we have any more details from that user? The list of possible causes there is significantly longer because there were obviously more changes between 96 and 97. If the user can reproduce the problem with mozregression, that would be much the quickest way of finding out what the cause of their issue is. AFAICT their browser has no idea where to put updates, and this is breaking all sorts of things, including telemetry and (I'm guessing) further updates, so it seems pretty important to still find out what is going on there.

(In reply to Sören Hentzschel from comment #11)
> (In reply to :Gijs (he/him) from comment #3)
> > I expect opening the about: dialog might also cause errors to show up for these users; Sören, can you check?
> 
> The ESR user checked the about dialog. Since the log from comment #0 was from another user (with Firefox 97) I asked the ESR user for the console output from both - opening the settings and the about dialog.
> 
> settings:
> 
> ```
> Error initializing preference category paneGeneral: TypeError: URL constructor:  is not a valid URL. preferences.js:277
>     gotoPref chrome://browser/content/preferences/preferences.js:277
>     AsyncFunctionThrow self-hosted:696
> Uncaught (in promise) TypeError: URL constructor:  is not a valid URL.  aboutDialog-appUpdater.js:47:19
>     appUpdater chrome://browser/content/aboutDialog-appUpdater.js:47
>     init chrome://browser/content/preferences/main.js:649
>     init chrome://browser/content/preferences/preferences.js:105
> ```

OK, so this part is a dupe of bug 1754409 (already fixed in 99, I guess we can ask for uplift). They've customized the manual update URL via about:config or a custom prefs file and this is upsetting things. It's a regression from bug 1747293 which got uplifted.

> ```
> Tue Feb 22 2022 07:41:34 GMT+0100 (Mitteleuropäische Normalzeit) userChromeJS userChrome.loadScript: [UChrm]/bildschirm.uc.js
> CustomizableUI is not defined bookmarks_backup_restore_button.uc.js:25
> ```

Uh, so they're running custom user chrome scripts that they or someone else wrote and those are breaking. I can't help with that.

At this point this bug is pretty confusing because it would appear that the two reports are not necessarily related. I'm confident that your last comment is from someone who is seeing the exact same thing as bug 1754409. They can work around locally by making the manual update URL something that does parse as a URL. This [comment from Kirk](https://bugzilla.mozilla.org/show_bug.cgi?id=1754409#c2) seems apt to me:

(Kirk Steuber (he/him) [:bytesized] from bug 1754409 comment #2)
> (In reply to Tynth from comment #0)
> > Normally i delete URL for option app.update.url.manual
> 
> Why do you want to be able to do this? I can't think of any reason to. It seems like the only real change this would cause is to break the link that Firefox shows you if an update fails. But if you don't want to use the link, can't you just not click on it? Why is it necessary to break it?
> 
> It's kind of inevitable that if you screw up your prefs enough, it will break things. And I would consider removing the manual update URL to be a form of screwing up your prefs.


Anyway, the logs in comment 0 (from the user on 97) do not really match the same issue, AFAICT. Do we have any more details from that user? The list of possible causes there is significantly longer because there were obviously more changes between 96 and 97. If the user can reproduce the problem with mozregression, that would be much the quickest way of finding out what the cause of their issue is. AFAICT their browser has no idea where to put updates, and this is breaking all sorts of things, including telemetry and (I'm guessing) further updates, so it seems pretty important to still find out what is going on there.