Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.comp.software.firefox > #16805 > unrolled thread
| Started by | The Real Bev <bashley101@gmail.com> |
|---|---|
| First post | 2026-04-25 08:45 -0700 |
| Last post | 2026-04-27 04:07 +0000 |
| Articles | 20 on this page of 91 — 15 participants |
Back to article view | Back to alt.comp.software.firefox
Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-25 08:45 -0700
Re: Unwanted update to 150 just happened Retirednoguilt <HapilyRetired@fakeaddress.invalid> - 2026-04-25 13:12 -0400
Re: Unwanted update to 150 just happened Andy Burns <usenet@andyburns.uk> - 2026-04-25 18:18 +0100
Re: Unwanted update to 150 just happened Nobody <jock@soccer.com> - 2026-04-25 10:26 -0700
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-25 11:01 -0700
Re: Unwanted update to 150 just happened Dave Royal <dave@dave123royal.com> - 2026-04-28 10:14 +0100
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-28 12:40 -0700
Re: Unwanted update to 150 just happened Dave Royal <dave@dave123royal.com> - 2026-04-28 22:21 +0100
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-28 19:36 -0700
Re: Unwanted update to 150 just happened dillinger <dillinger@invalid.not> - 2026-04-29 15:45 +0200
Re: Unwanted update to 150 just happened Richmond <dnomhcir@gmx.com> - 2026-04-29 15:04 +0100
Re: Unwanted update to 150 just happened Andy Burns <usenet@andyburns.uk> - 2026-04-29 15:10 +0100
Re: Unwanted update to 150 just happened Richmond <dnomhcir@gmx.com> - 2026-04-29 15:21 +0100
Re: Unwanted update to 150 just happened dillinger <dillinger@invalid.not> - 2026-04-29 17:26 +0200
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-29 19:41 -0700
Re: Unwanted update to 150 just happened Richmond <dnomhcir@gmx.com> - 2026-04-29 16:47 +0100
Re: Unwanted update to 150 just happened Andy Burns <usenet@andyburns.uk> - 2026-04-29 16:52 +0100
Re: Unwanted update to 150 just happened Richmond <dnomhcir@gmx.com> - 2026-04-29 16:54 +0100
Re: Unwanted update to 150 just happened Andy Burns <usenet@andyburns.uk> - 2026-04-29 17:00 +0100
Re: Unwanted update to 150 just happened Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-02 05:41 +0000
Re: Unwanted update to 150 just happened dillinger <dillinger@invalid.not> - 2026-04-29 18:11 +0200
Re: Unwanted update to 150 just happened Dave Royal <dave@dave123royal.com> - 2026-04-29 20:20 +0100
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-29 20:30 -0700
Re: Unwanted update to 150 just happened Richmond <dnomhcir@gmx.com> - 2026-04-30 09:10 +0100
Re: Unwanted update to 150 just happened Andy Burns <usenet@andyburns.uk> - 2026-04-30 10:03 +0100
Re: Unwanted update to 150 just happened dillinger <dillinger@invalid.not> - 2026-04-30 05:48 +0200
Re: Unwanted update to 150 just happened Richmond <dnomhcir@gmx.com> - 2026-04-30 14:23 +0100
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-30 20:16 -0700
Re: Unwanted update to 150 just happened Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-03 21:47 +0000
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-05-03 19:33 -0700
Re: Unwanted update to 150 just happened Dave Royal <dave@dave123royal.com> - 2026-05-01 07:04 +0000
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-05-01 09:33 -0700
Re: Unwanted update to 150 just happened Dave Royal <dave@dave123royal.com> - 2026-05-01 18:00 +0100
Re: Unwanted update to 150 just happened Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-03 21:51 +0000
Re: Unwanted update to 150 just happened Dave Royal <dave@dave123royal.com> - 2026-05-03 11:52 +0000
Re: Unwanted update to 150 just happened Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-01 08:09 +0000
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-05-01 09:17 -0700
Re: Unwanted update to 150 just happened Frank Miller <miller@posteo.ee> - 2026-05-01 19:10 +0200
Re: Unwanted update to 150 just happened R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> - 2026-05-01 20:16 +0200
Re: Unwanted update to 150 just happened Nobody <jock@soccer.com> - 2026-05-01 12:57 -0700
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-05-02 11:58 -0700
Re: Unwanted update to 150 just happened Frank Miller <miller@posteo.ee> - 2026-05-02 21:15 +0200
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-05-02 12:53 -0700
Re: Unwanted update to 150 just happened Frank Miller <miller@posteo.ee> - 2026-05-02 22:25 +0200
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-05-02 22:10 -0700
Re: Unwanted update to 150 just happened Nobody <jock@soccer.com> - 2026-05-02 16:40 -0700
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-05-02 22:01 -0700
Re: Unwanted update to 150 just happened Nobody <jock@soccer.com> - 2026-05-03 18:49 -0700
Re: Unwanted update to 150 just happened Frank Miller <miller@posteo.ee> - 2026-05-01 22:09 +0200
Re: Unwanted update to 150 just happened Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-02 12:08 +1200
Re: Unwanted update to 150 just happened Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-02 00:11 +0000
Re: Unwanted update to 150 just happened R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> - 2026-04-25 20:13 +0200
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-25 11:25 -0700
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-25 11:35 -0700
Re: Unwanted update to 150 just happened "Alan K." <alan@invalid.com> - 2026-04-25 14:56 -0400
Re: Unwanted update to 150 just happened -- SOLVED! The Real Bev <bashley101@gmail.com> - 2026-04-25 12:41 -0700
Re: Unwanted update to 150 just happened -- SOLVED! "Alan K." <alan@invalid.com> - 2026-04-25 15:56 -0400
Re: Unwanted update to 150 just happened -- SOLVED! Frank Miller <miller@posteo.ee> - 2026-04-25 23:03 +0200
Re: Unwanted update to 150 just happened -- SOLVED! The Real Bev <bashley101@gmail.com> - 2026-04-25 14:51 -0700
Re: Unwanted update to 150 just happened -- SOLVED! "Alan K." <alan@invalid.com> - 2026-04-25 18:12 -0400
Re: Unwanted update to 150 just happened -- SOLVED! The Real Bev <bashley101@gmail.com> - 2026-04-25 22:13 -0700
Re: Unwanted update to 150 just happened R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> - 2026-04-26 10:12 +0200
Re: Unwanted update to 150 just happened Frank Miller <miller@posteo.ee> - 2026-04-25 21:40 +0200
Re: Unwanted update to 150 just happened VanguardLH <V@nguard.LH> - 2026-04-25 14:21 -0500
Re: Unwanted update to 150 just happened -- SOLVED! The Real Bev <bashley101@gmail.com> - 2026-04-25 12:45 -0700
Re: Unwanted update to 150 just happened -- SOLVED! The Real Bev <bashley101@gmail.com> - 2026-04-25 13:01 -0700
Re: Unwanted update to 150 just happened micky <NONONOmisc07@fmguy.com> - 2026-04-25 19:58 -0400
Re: Unwanted update to 150 just happened Retirednoguilt <HapilyRetired@fakeaddress.invalid> - 2026-04-26 07:42 -0400
Re: Unwanted update to 150 just happened R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> - 2026-04-26 18:46 +0200
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-26 12:11 -0700
Re: Unwanted update to 150 just happened Nobody <jock@soccer.com> - 2026-04-26 15:47 -0700
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-26 17:05 -0700
Re: Unwanted update to 150 just happened Nobody <jock@soccer.com> - 2026-04-26 18:49 -0700
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-26 21:48 -0700
Re: Unwanted update to 150 just happened Retirednoguilt <HapilyRetired@fakeaddress.invalid> - 2026-04-27 13:42 -0400
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-27 11:28 -0700
Re: Unwanted update to 150 just happened Retirednoguilt <HapilyRetired@fakeaddress.invalid> - 2026-04-27 16:01 -0400
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-28 12:45 -0700
Re: Unwanted update to 150 just happened "Adam H. Kerman" <ahk@chinet.com> - 2026-04-28 00:23 +0000
Re: Unwanted update to 150 just happened Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-28 08:36 +0000
Re: Unwanted update to 150 just happened "Adam H. Kerman" <ahk@chinet.com> - 2026-04-28 12:35 +0000
Re: Unwanted update to 150 just happened Retirednoguilt <HapilyRetired@fakeaddress.invalid> - 2026-04-28 15:42 -0400
Re: Unwanted update to 150 just happened Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-28 01:14 +0000
Re: Unwanted update to 150 just happened "Adam H. Kerman" <ahk@chinet.com> - 2026-04-28 02:51 +0000
Re: Unwanted update to 150 just happened The Real Bev <bashley101@gmail.com> - 2026-04-28 12:51 -0700
Re: Unwanted update to 150 just happened Char Jackson <none@none.invalid> - 2026-05-08 15:06 -0500
Re: Unwanted update to 150 just happened micky <NONONOmisc07@fmguy.com> - 2026-04-26 22:27 -0400
Re: Unwanted update to 150 just happened Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-28 01:12 +0000
Re: Unwanted update to 150 just happened Retirednoguilt <HapilyRetired@fakeaddress.invalid> - 2026-04-27 13:24 -0400
Re: Unwanted update to 150 just happened R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> - 2026-04-28 09:15 +0200
Re: Unwanted update to 150 just happened Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-27 04:07 +0000
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | dillinger <dillinger@invalid.not> |
|---|---|
| Date | 2026-04-29 18:11 +0200 |
| Message-ID | <a7n9cm-arov3.ln1@spock.lan> |
| In reply to | #16946 |
On 29/04/2026 17:47, Richmond wrote:
> dillinger <dillinger@invalid.not> writes:
>
>> Op 29-04-2026 om 04:36 schreef The Real Bev:
>>> On 4/28/26 14:21, Dave Royal wrote:
>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>
>>>>> On 4/28/26 02:14, Dave Royal wrote:
>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>
>>>>>>> On 4/25/26 10:26, Nobody wrote:
>>>>>>>> On Sat, 25 Apr 2026 18:18:07 +0100, Andy Burns <usenet@andyburns.uk>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Retirednoguilt wrote:
>>>>>>>>>
>>>>>>>>>> I've never had FF update me autonomously.
>>>>>>>>>
>>>>>>>>> I have it set for "Check for updates but let you choose to
>>>>>>>>> install them"
>>>>>>>>> and as best as I can remember, its never disobeyed ...
>>>>>>>>
>>>>>>>> Should a user (for whatever reason) 'uninstall/re-install' then that
>>>>>>>> radio button changes to 'automatically install/recommended'.
>>>>>>>>
>>>>>>>> Semi-OT, Thunderbird conversely holds the 'check for updates but
>>>>>>>> lemme
>>>>>>>> do the work' setting.
>>>>>>>
>>>>>>> I have had that setting for decades -- and still do. Some years
>>>>>>> ago it stopped working and some kind person posted the
>>>>>>> policies.json fix -- which worked until today. Posted herewith:
>>>>>>>
>>>>>>> Make a new firefox/distribution/ subdirectory which will contain
>>>>>>> the file policies.json which contains
>>>>>>> {
>>>>>>> "policies": {
>>>>>>> "DisableAppUpdate": true
>>>>>>> }
>>>>>>> }
>>>>>>
>>>>>> Did that 'kind person' provide a policies.json file for you to
>>>>>> download, or did you create one - on Linux?
>>>>>
>>>>> Someone posted about that file long ago, and the one I created with
>>>>> pico worked for years.
>>>>>> Just wondering how these Windows line endings - if that was the
>>>>>> problem - got there.
>>>>> They appeared when Firefox chose to update itself against my express
>>>>> wishes. I suspect that Firefox did it of its own volition -- or
>>>>> simple clumsiness. Core dump complete.
>>>>
>>>> You /found/ them after the unwanted update. Were they responsible
>>>> for it? I doubt it: line endings - of either type - are ignored
>>>> in a json file.
>>>
>>> The windows endings damaged the file such that it no longer served the
>>> purpose. Fixing it worked.
>>>
>>
>> Firefox doesn't care about line endings.
>>
>> Just for the sake of it I tested it for you, I created a policies.json
>> which blocks about:config and tested it with both CRLF (windows) and LF
>> (unix) line endings.
>>
>> The result are the same for both, it works:
>> Blocked Page, Firefox can’t connect to the server at about:config
>>
>> ^M is not a corruption, this is how cat -A shows CR, your AI needs an
>> update.
>>
>> CRLF (windows):
>> cat -A policies.json
>> {^M$
>> "policies": {^M$
>> "BlockAboutConfig": true^M$
>> }^M$
>> }^M$
>>
>> LF (unix):
>> cat -A policies.json
>> {$
>> "policies": {$
>> "BlockAboutConfig": true$
>> }$
>> }$
>
> You tested whether it blocked about:config, but you didn't test whether
> it blocked an update, or if the update altered the json file.
I tested policies.json, which was reported corrupted, with both CRLF and
LF, any policy will do, we don't need to wait for the next update.
Policies.json is not included by default, updates will either not touch
it at all or remove it completely, depending on how you update.
Since we can't see the original file there is no way to tell how it was
changed.
[toc] | [prev] | [next] | [standalone]
| From | Dave Royal <dave@dave123royal.com> |
|---|---|
| Date | 2026-04-29 20:20 +0100 |
| Message-ID | <10stlmh$51ep$1@dont-email.me> |
| In reply to | #16950 |
dillinger <dillinger@invalid.not> Wrote in message:
> On 29/04/2026 17:47, Richmond wrote:
>> dillinger <dillinger@invalid.not> writes:
>>
>>> Op 29-04-2026 om 04:36 schreef The Real Bev:
>>>> On 4/28/26 14:21, Dave Royal wrote:
>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>
>>>>>> On 4/28/26 02:14, Dave Royal wrote:
>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>
>>>>>>>> On 4/25/26 10:26, Nobody wrote:
>>>>>>>>> On Sat, 25 Apr 2026 18:18:07 +0100, Andy Burns <usenet@andyburns.uk>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Retirednoguilt wrote:
>>>>>>>>>>
>>>>>>>>>>> I've never had FF update me autonomously.
>>>>>>>>>>
>>>>>>>>>> I have it set for "Check for updates but let you choose to
>>>>>>>>>> install them"
>>>>>>>>>> and as best as I can remember, its never disobeyed ...
>>>>>>>>>
>>>>>>>>> Should a user (for whatever reason) 'uninstall/re-install' then that
>>>>>>>>> radio button changes to 'automatically install/recommended'.
>>>>>>>>>
>>>>>>>>> Semi-OT, Thunderbird conversely holds the 'check for updates but
>>>>>>>>> lemme
>>>>>>>>> do the work' setting.
>>>>>>>>
>>>>>>>> I have had that setting for decades -- and still do. Some years
>>>>>>>> ago it stopped working and some kind person posted the
>>>>>>>> policies.json fix -- which worked until today. Posted herewith:
>>>>>>>>
>>>>>>>> Make a new firefox/distribution/ subdirectory which will contain
>>>>>>>> the file policies.json which contains
>>>>>>>> {
>>>>>>>> "policies": {
>>>>>>>> "DisableAppUpdate": true
>>>>>>>> }
>>>>>>>> }
>>>>>>>
>>>>>>> Did that 'kind person' provide a policies.json file for you to
>>>>>>> download, or did you create one - on Linux?
>>>>>>
>>>>>> Someone posted about that file long ago, and the one I created with
>>>>>> pico worked for years.
>>>>>>> Just wondering how these Windows line endings - if that was the
>>>>>>> problem - got there.
>>>>>> They appeared when Firefox chose to update itself against my express
>>>>>> wishes. I suspect that Firefox did it of its own volition -- or
>>>>>> simple clumsiness. Core dump complete.
>>>>>
>>>>> You /found/ them after the unwanted update. Were they responsible
>>>>> for it? I doubt it: line endings - of either type - are ignored
>>>>> in a json file.
>>>>
>>>> The windows endings damaged the file such that it no longer served the
>>>> purpose. Fixing it worked.
>>>>
>>>
>>> Firefox doesn't care about line endings.
>>>
>>> Just for the sake of it I tested it for you, I created a policies.json
>>> which blocks about:config and tested it with both CRLF (windows) and LF
>>> (unix) line endings.
>>>
>>> The result are the same for both, it works:
>>> Blocked Page, Firefox can’t connect to the server at about:config
>>>
>>> ^M is not a corruption, this is how cat -A shows CR, your AI needs an
>>> update.
>>>
>>> CRLF (windows):
>>> cat -A policies.json
>>> {^M$
>>> "policies": {^M$
>>> "BlockAboutConfig": true^M$
>>> }^M$
>>> }^M$
>>>
>>> LF (unix):
>>> cat -A policies.json
>>> {$
>>> "policies": {$
>>> "BlockAboutConfig": true$
>>> }$
>>> }$
>>
>> You tested whether it blocked about:config, but you didn't test whether
>> it blocked an update, or if the update altered the json file.
>
> I tested policies.json, which was reported corrupted, with both CRLF and
> LF, any policy will do, we don't need to wait for the next update.
> Policies.json is not included by default, updates will either not touch
> it at all or remove it completely, depending on how you update.
> Since we can't see the original file there is no way to tell how it was
> changed.
Why might an update remove policies.json? I assume that the
firefox updater will read it if it's there but never write to it.
The point of it is that it's user, or organisation,
controlled.
I did wonder if updates might /update/ policies.json, for changes
in format say, in the way they update a profile. But I doubt
it.
On Debian I have tarballs of Fx nightly and TB beta, in addtion to
packaged versions for regular use. They do not include a
distribution/ directory or a template policies.json.
--
Remove numerics from my email address.
[toc] | [prev] | [next] | [standalone]
| From | The Real Bev <bashley101@gmail.com> |
|---|---|
| Date | 2026-04-29 20:30 -0700 |
| Message-ID | <10suick$c4n8$2@dont-email.me> |
| In reply to | #16951 |
On 4/29/26 12:20, Dave Royal wrote:
> dillinger <dillinger@invalid.not> Wrote in message:
>
>> On 29/04/2026 17:47, Richmond wrote:
>>> dillinger <dillinger@invalid.not> writes:
>>>
>>>> Op 29-04-2026 om 04:36 schreef The Real Bev:
>>>>> On 4/28/26 14:21, Dave Royal wrote:
>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>
>>>>>>> On 4/28/26 02:14, Dave Royal wrote:
>>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>>
>>>>>>>>> On 4/25/26 10:26, Nobody wrote:
>>>>>>>>>> On Sat, 25 Apr 2026 18:18:07 +0100, Andy Burns <usenet@andyburns.uk>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Retirednoguilt wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I've never had FF update me autonomously.
>>>>>>>>>>>
>>>>>>>>>>> I have it set for "Check for updates but let you choose to
>>>>>>>>>>> install them"
>>>>>>>>>>> and as best as I can remember, its never disobeyed ...
>>>>>>>>>>
>>>>>>>>>> Should a user (for whatever reason) 'uninstall/re-install' then that
>>>>>>>>>> radio button changes to 'automatically install/recommended'.
>>>>>>>>>>
>>>>>>>>>> Semi-OT, Thunderbird conversely holds the 'check for updates but
>>>>>>>>>> lemme
>>>>>>>>>> do the work' setting.
>>>>>>>>>
>>>>>>>>> I have had that setting for decades -- and still do. Some years
>>>>>>>>> ago it stopped working and some kind person posted the
>>>>>>>>> policies.json fix -- which worked until today. Posted herewith:
>>>>>>>>>
>>>>>>>>> Make a new firefox/distribution/ subdirectory which will contain
>>>>>>>>> the file policies.json which contains
>>>>>>>>> {
>>>>>>>>> "policies": {
>>>>>>>>> "DisableAppUpdate": true
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>
>>>>>>>> Did that 'kind person' provide a policies.json file for you to
>>>>>>>> download, or did you create one - on Linux?
>>>>>>>
>>>>>>> Someone posted about that file long ago, and the one I created with
>>>>>>> pico worked for years.
>>>>>>>> Just wondering how these Windows line endings - if that was the
>>>>>>>> problem - got there.
>>>>>>> They appeared when Firefox chose to update itself against my express
>>>>>>> wishes. I suspect that Firefox did it of its own volition -- or
>>>>>>> simple clumsiness. Core dump complete.
>>>>>>
>>>>>> You /found/ them after the unwanted update. Were they responsible
>>>>>> for it? I doubt it: line endings - of either type - are ignored
>>>>>> in a json file.
>>>>>
>>>>> The windows endings damaged the file such that it no longer served the
>>>>> purpose. Fixing it worked.
>>>>>
>>>>
>>>> Firefox doesn't care about line endings.
>>>>
>>>> Just for the sake of it I tested it for you, I created a policies.json
>>>> which blocks about:config and tested it with both CRLF (windows) and LF
>>>> (unix) line endings.
>>>>
>>>> The result are the same for both, it works:
>>>> Blocked Page, Firefox can’t connect to the server at about:config
>>>>
>>>> ^M is not a corruption, this is how cat -A shows CR, your AI needs an
>>>> update.
>>>>
>>>> CRLF (windows):
>>>> cat -A policies.json
>>>> {^M$
>>>> "policies": {^M$
>>>> "BlockAboutConfig": true^M$
>>>> }^M$
>>>> }^M$
>>>>
>>>> LF (unix):
>>>> cat -A policies.json
>>>> {$
>>>> "policies": {$
>>>> "BlockAboutConfig": true$
>>>> }$
>>>> }$
>>>
>>> You tested whether it blocked about:config, but you didn't test whether
>>> it blocked an update, or if the update altered the json file.
>>
>> I tested policies.json, which was reported corrupted, with both CRLF and
>> LF, any policy will do, we don't need to wait for the next update.
>> Policies.json is not included by default, updates will either not touch
>> it at all or remove it completely, depending on how you update.
>> Since we can't see the original file there is no way to tell how it was
>> changed.
>
> Why might an update remove policies.json? I assume that the
> firefox updater will read it if it's there but never write to it.
> The point of it is that it's user, or organisation,
> controlled.
>
> I did wonder if updates might /update/ policies.json, for changes
> in format say, in the way they update a profile. But I doubt
> it.
>
> On Debian I have tarballs of Fx nightly and TB beta, in addtion to
> packaged versions for regular use. They do not include a
> distribution/ directory or a template policies.json.
No, they're not included with the tarball. "Some kind person" posted
the fix at some point in the past (earliest I have is Firefox 72, July
7,2020) posted how to do it. If I want to use a newer version I don't
update. I download the tarball, untar it into its own subdirectory and
run it from within that subdirectory (/blabla/firefox/firefox -P &).
After running it once I exit and copy over (cp -rf *) my previous
profile into the newly created profile. Accordingly, I have at least a
dozen fully functional firefoxes. TMI, but there it is.
Worked fine until somebody said that FF148 had some sort of security
problem, at which point I did an update to 149 rather than building a
whole new installation. I think I renamed the policies.json file, which
would have been the simplest thing. Sorry I can't be more certain. Then
I would have renamed it back. And then I got the unwanted surprise of
the 150 update. I turned the problem over to Perplexity, which provided
the solution. If anyone is interested I can have Perplexity generate a
nice pdf file of the entire interchange.
I assume that firefox does some variant of cp -rf * when it updates and
then does some profile-creation stuff and god knows what else. It must
also use some touch-like command, becuase the date of the policies.json
file was the same as the date on all the other FF 150 subdirectories and
files. I don't remember looking at the FF149/firefox files because I
would have had no reason to. And that must be when the mischief occurred.
AH-HAH! At some point when I first heard about the policies.json thing
I was unsure about where to put it, so I put one in the /firefox
subdirectory. It's still there, and contains the ^M characters. They
seem to be M- instead of ^M, for what it's worth. Its date is the same
as all the others -- April 24 19:37.
cat -A policies.json
{$
M- "policies": {$
M- M- "DisableAppUpdate": true$
M- }$
}$
$
--
Cheers, Bev
"Nothing in the universe can withstand the relentless application
of brute force and ignorance." -- Frd, via Dennis (evil)
[toc] | [prev] | [next] | [standalone]
| From | Richmond <dnomhcir@gmx.com> |
|---|---|
| Date | 2026-04-30 09:10 +0100 |
| Message-ID | <82jyto27il.fsf@example.com> |
| In reply to | #16958 |
The Real Bev <bashley101@gmail.com> writes:
> On 4/29/26 12:20, Dave Royal wrote:
>> dillinger <dillinger@invalid.not> Wrote in message:
>>
>>> On 29/04/2026 17:47, Richmond wrote:
>>>> dillinger <dillinger@invalid.not> writes:
>>>>
>>>>> Op 29-04-2026 om 04:36 schreef The Real Bev:
>>>>>> On 4/28/26 14:21, Dave Royal wrote:
>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>
>>>>>>>> On 4/28/26 02:14, Dave Royal wrote:
>>>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>>>
>>>>>>>>>> On 4/25/26 10:26, Nobody wrote:
>>>>>>>>>>> On Sat, 25 Apr 2026 18:18:07 +0100, Andy Burns
>>>>>>>>>>> <usenet@andyburns.uk>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Retirednoguilt wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I've never had FF update me autonomously.
>>>>>>>>>>>>
>>>>>>>>>>>> I have it set for "Check for updates but let you choose to
>>>>>>>>>>>> install them" and as best as I can remember, its never
>>>>>>>>>>>> disobeyed ...
>>>>>>>>>>>
>>>>>>>>>>> Should a user (for whatever reason) 'uninstall/re-install'
>>>>>>>>>>> then that radio button changes to 'automatically
>>>>>>>>>>> install/recommended'.
>>>>>>>>>>>
>>>>>>>>>>> Semi-OT, Thunderbird conversely holds the 'check for updates
>>>>>>>>>>> but lemme do the work' setting.
>>>>>>>>>>
>>>>>>>>>> I have had that setting for decades -- and still do. Some
>>>>>>>>>> years ago it stopped working and some kind person posted the
>>>>>>>>>> policies.json fix -- which worked until today. Posted
>>>>>>>>>> herewith:
>>>>>>>>>>
>>>>>>>>>> Make a new firefox/distribution/ subdirectory which will
>>>>>>>>>> contain the file policies.json which contains { "policies": {
>>>>>>>>>> "DisableAppUpdate": true } }
>>>>>>>>>
>>>>>>>>> Did that 'kind person' provide a policies.json file for you to
>>>>>>>>> download, or did you create one - on Linux?
>>>>>>>>
>>>>>>>> Someone posted about that file long ago, and the one I created
>>>>>>>> with pico worked for years. > Just wondering how these Windows
>>>>>>>> line endings - if that was the > problem - got there. They
>>>>>>>> appeared when Firefox chose to update itself against my express
>>>>>>>> wishes. I suspect that Firefox did it of its own volition --
>>>>>>>> or simple clumsiness. Core dump complete.
>>>>>>>
>>>>>>> You /found/ them after the unwanted update. Were they
>>>>>>> responsible for it? I doubt it: line endings - of either type
>>>>>>> - are ignored in a json file.
>>>>>>
>>>>>> The windows endings damaged the file such that it no longer
>>>>>> served the purpose. Fixing it worked.
>>>>>>
>>>>>
>>>>> Firefox doesn't care about line endings.
>>>>>
>>>>> Just for the sake of it I tested it for you, I created a
>>>>> policies.json which blocks about:config and tested it with both
>>>>> CRLF (windows) and LF (unix) line endings.
>>>>>
>>>>> The result are the same for both, it works: Blocked Page, Firefox
>>>>> can’t connect to the server at about:config
>>>>>
>>>>> ^M is not a corruption, this is how cat -A shows CR, your AI needs
>>>>> an update.
>>>>>
>>>>> CRLF (windows): cat -A policies.json {^M$ "policies": {^M$
>>>>> "BlockAboutConfig": true^M$ }^M$ }^M$
>>>>>
>>>>> LF (unix): cat -A policies.json {$ "policies": {$
>>>>> "BlockAboutConfig": true$ }$ }$ >>>> You tested whether it blocked
>>>>> about:config, but you didn't test >>>> whether >>>> it blocked an
>>>>> update, or if the update altered the json file. >>> I tested
>>>>> policies.json, which was reported corrupted, with both >>> CRLF
>>>>> and LF, any policy will do, we don't need to wait for the next >>>
>>>>> update. >>> Policies.json is not included by default, updates
>>>>> will either not >>> touch it at all or remove it completely,
>>>>> depending on how you >>> update. >>> Since we can't see the
>>>>> original file there is no way to tell how it >>> was changed. >>
>>>>> Why might an update remove policies.json? I assume that the >>
>>>>> firefox updater will read it if it's there but never write to it.
>>>>> >> The point of it is that it's user, or organisation, >>
>>>>> controlled. >> I did wonder if updates might /update/
>>>>> policies.json, for changes >> in format say, in the way they
>>>>> update a profile. But I doubt >> it. >> On Debian I have tarballs
>>>>> of Fx nightly and TB beta, in addtion to >> packaged versions for
>>>>> regular use. They do not include a >> distribution/ directory or a
>>>>> template policies.json.
>
> No, they're not included with the tarball. "Some kind person" posted
> the fix at some point in the past (earliest I have is Firefox 72, July
> 7,2020) posted how to do it. If I want to use a newer version I don't
> update. I download the tarball, untar it into its own subdirectory
> and run it from within that subdirectory (/blabla/firefox/firefox -P
> &). After running it once I exit and copy over (cp -rf *) my previous
> profile into the newly created profile. Accordingly, I have at least
> a dozen fully functional firefoxes. TMI, but there it is.
>
> Worked fine until somebody said that FF148 had some sort of security
> problem, at which point I did an update to 149 rather than building a
> whole new installation. I think I renamed the policies.json file,
> which would have been the simplest thing. Sorry I can't be more
> certain. Then I would have renamed it back. And then I got the
> unwanted surprise of the 150 update. I turned the problem over to
> Perplexity, which provided the solution. If anyone is interested I
> can have Perplexity generate a nice pdf file of the entire
> interchange.
>
> I assume that firefox does some variant of cp -rf * when it updates
> and then does some profile-creation stuff and god knows what else. It
> must also use some touch-like command, becuase the date of the
> policies.json file was the same as the date on all the other FF 150
> subdirectories and files. I don't remember looking at the
> FF149/firefox files because I would have had no reason to. And that
> must be when the mischief occurred.
>
> AH-HAH! At some point when I first heard about the policies.json
> thing I was unsure about where to put it, so I put one in the /firefox
> subdirectory. It's still there, and contains the ^M characters. They
> seem to be M- instead of ^M, for what it's worth. Its date is the same
> as all the others -- April 24 19:37.
>
> cat -A policies.json {$ M- "policies": {$ M- M- "DisableAppUpdate":
> true$ M- }$ }$ $
The plot thickens. Here is what my favourite AI said:
"In your case, the indentation uses UTF-8 encoded non-breaking spaces
(or similar Unicode whitespace) instead of regular ASCII spaces
(0x20). For example, M- is likely a non-breaking space (U+00A0, encoded
as 0xC2 0xA0 in UTF-8).
Why this matters for a JSON file: Most JSON parsers only treat ASCII
whitespace (regular space, tab, newline) as insignificant
whitespace. Non-breaking spaces can cause parse errors depending on the
parser. "
[toc] | [prev] | [next] | [standalone]
| From | Andy Burns <usenet@andyburns.uk> |
|---|---|
| Date | 2026-04-30 10:03 +0100 |
| Message-ID | <n5gk7aFqjvdU2@mid.individual.net> |
| In reply to | #16964 |
Richmond wrote: > Most JSON parsers only treat ASCII > whitespace (regular space, tab, newline) as insignificant > whitespace. Non-breaking spaces can cause parse errors depending on the > parser. Yeah, that'd b0rk it ...
[toc] | [prev] | [next] | [standalone]
| From | dillinger <dillinger@invalid.not> |
|---|---|
| Date | 2026-04-30 05:48 +0200 |
| Message-ID | <p10bcm-jq3.ln1@spock.lan> |
| In reply to | #16958 |
On 30/04/2026 05:30, The Real Bev wrote:
> On 4/29/26 12:20, Dave Royal wrote:
>> dillinger <dillinger@invalid.not> Wrote in message:
>>
>>> On 29/04/2026 17:47, Richmond wrote:
>>>> dillinger <dillinger@invalid.not> writes:
>>>>
>>>>> Op 29-04-2026 om 04:36 schreef The Real Bev:
>>>>>> On 4/28/26 14:21, Dave Royal wrote:
>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>
>>>>>>>> On 4/28/26 02:14, Dave Royal wrote:
>>>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>>>
>>>>>>>>>> On 4/25/26 10:26, Nobody wrote:
>>>>>>>>>>> On Sat, 25 Apr 2026 18:18:07 +0100, Andy Burns
>>>>>>>>>>> <usenet@andyburns.uk>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Retirednoguilt wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I've never had FF update me autonomously.
>>>>>>>>>>>>
>>>>>>>>>>>> I have it set for "Check for updates but let you choose to
>>>>>>>>>>>> install them"
>>>>>>>>>>>> and as best as I can remember, its never disobeyed ...
>>>>>>>>>>>
>>>>>>>>>>> Should a user (for whatever reason) 'uninstall/re-install'
>>>>>>>>>>> then that
>>>>>>>>>>> radio button changes to 'automatically install/recommended'.
>>>>>>>>>>>
>>>>>>>>>>> Semi-OT, Thunderbird conversely holds the 'check for updates but
>>>>>>>>>>> lemme
>>>>>>>>>>> do the work' setting.
>>>>>>>>>>
>>>>>>>>>> I have had that setting for decades -- and still do. Some years
>>>>>>>>>> ago it stopped working and some kind person posted the
>>>>>>>>>> policies.json fix -- which worked until today. Posted herewith:
>>>>>>>>>>
>>>>>>>>>> Make a new firefox/distribution/ subdirectory which will contain
>>>>>>>>>> the file policies.json which contains
>>>>>>>>>> {
>>>>>>>>>> "policies": {
>>>>>>>>>> "DisableAppUpdate": true
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Did that 'kind person' provide a policies.json file for you to
>>>>>>>>> download, or did you create one - on Linux?
>>>>>>>>
>>>>>>>> Someone posted about that file long ago, and the one I created with
>>>>>>>> pico worked for years.
>>>>>>>>> Just wondering how these Windows line endings - if that was the
>>>>>>>>> problem - got there.
>>>>>>>> They appeared when Firefox chose to update itself against my
>>>>>>>> express
>>>>>>>> wishes. I suspect that Firefox did it of its own volition -- or
>>>>>>>> simple clumsiness. Core dump complete.
>>>>>>>
>>>>>>> You /found/ them after the unwanted update. Were they responsible
>>>>>>> for it? I doubt it: line endings - of either type - are ignored
>>>>>>> in a json file.
>>>>>>
>>>>>> The windows endings damaged the file such that it no longer served
>>>>>> the
>>>>>> purpose. Fixing it worked.
>>>>>>
>>>>>
>>>>> Firefox doesn't care about line endings.
>>>>>
>>>>> Just for the sake of it I tested it for you, I created a policies.json
>>>>> which blocks about:config and tested it with both CRLF (windows)
>>>>> and LF
>>>>> (unix) line endings.
>>>>>
>>>>> The result are the same for both, it works:
>>>>> Blocked Page, Firefox can’t connect to the server at about:config
>>>>>
>>>>> ^M is not a corruption, this is how cat -A shows CR, your AI needs an
>>>>> update.
>>>>>
>>>>> CRLF (windows):
>>>>> cat -A policies.json
>>>>> {^M$
>>>>> "policies": {^M$
>>>>> "BlockAboutConfig": true^M$
>>>>> }^M$
>>>>> }^M$
>>>>>
>>>>> LF (unix):
>>>>> cat -A policies.json
>>>>> {$
>>>>> "policies": {$
>>>>> "BlockAboutConfig": true$
>>>>> }$
>>>>> }$
>>>>
>>>> You tested whether it blocked about:config, but you didn't test whether
>>>> it blocked an update, or if the update altered the json file.
>>>
>>> I tested policies.json, which was reported corrupted, with both CRLF
>>> and LF, any policy will do, we don't need to wait for the next update.
>>> Policies.json is not included by default, updates will either not
>>> touch it at all or remove it completely, depending on how you update.
>>> Since we can't see the original file there is no way to tell how it
>>> was changed.
>>
>> Why might an update remove policies.json? I assume that the
>> firefox updater will read it if it's there but never write to it.
>> The point of it is that it's user, or organisation,
>> controlled.
>>
>> I did wonder if updates might /update/ policies.json, for changes
>> in format say, in the way they update a profile. But I doubt
>> it.
>>
>> On Debian I have tarballs of Fx nightly and TB beta, in addtion to
>> packaged versions for regular use. They do not include a
>> distribution/ directory or a template policies.json.
>
> No, they're not included with the tarball. "Some kind person" posted
> the fix at some point in the past (earliest I have is Firefox 72, July
> 7,2020) posted how to do it. If I want to use a newer version I don't
> update. I download the tarball, untar it into its own subdirectory and
> run it from within that subdirectory (/blabla/firefox/firefox -P &).
> After running it once I exit and copy over (cp -rf *) my previous
> profile into the newly created profile. Accordingly, I have at least a
> dozen fully functional firefoxes. TMI, but there it is.
>
> Worked fine until somebody said that FF148 had some sort of security
> problem, at which point I did an update to 149 rather than building a
> whole new installation. I think I renamed the policies.json file, which
> would have been the simplest thing. Sorry I can't be more certain. Then
> I would have renamed it back. And then I got the unwanted surprise of
> the 150 update. I turned the problem over to Perplexity, which provided
> the solution. If anyone is interested I can have Perplexity generate a
> nice pdf file of the entire interchange.
>
> I assume that firefox does some variant of cp -rf * when it updates and
> then does some profile-creation stuff and god knows what else. It must
> also use some touch-like command, becuase the date of the policies.json
> file was the same as the date on all the other FF 150 subdirectories and
> files. I don't remember looking at the FF149/firefox files because I
> would have had no reason to. And that must be when the mischief occurred.
>
> AH-HAH! At some point when I first heard about the policies.json thing
> I was unsure about where to put it, so I put one in the /firefox
> subdirectory. It's still there, and contains the ^M characters. They
> seem to be M- instead of ^M, for what it's worth. Its date is the same
> as all the others -- April 24 19:37.
>
> cat -A policies.json
> {$
> M- "policies": {$
> M- M- "DisableAppUpdate": true$
> M- }$
> }$
> $
>
Why cat -A? Check man cat.
In the output of cat -A "M-" is a tab, "^M" is a CR and "$" is a LF
If you copy those literally into a script it will very likely produce an
error.
[toc] | [prev] | [next] | [standalone]
| From | Richmond <dnomhcir@gmx.com> |
|---|---|
| Date | 2026-04-30 14:23 +0100 |
| Message-ID | <82ecjwintw.fsf@example.com> |
| In reply to | #16970 |
dillinger <dillinger@invalid.not> writes:
> On 30/04/2026 05:30, The Real Bev wrote:
>> On 4/29/26 12:20, Dave Royal wrote:
>>> dillinger <dillinger@invalid.not> Wrote in message:
>>>
>>>> On 29/04/2026 17:47, Richmond wrote:
>>>>> dillinger <dillinger@invalid.not> writes:
>>>>>
>>>>>> Op 29-04-2026 om 04:36 schreef The Real Bev:
>>>>>>> On 4/28/26 14:21, Dave Royal wrote:
>>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>>
>>>>>>>>> On 4/28/26 02:14, Dave Royal wrote:
>>>>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>>>>
>>>>>>>>>>> On 4/25/26 10:26, Nobody wrote:
>>>>>>>>>>>> On Sat, 25 Apr 2026 18:18:07 +0100, Andy Burns
>>>>>>>>>>>> <usenet@andyburns.uk>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Retirednoguilt wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've never had FF update me autonomously.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have it set for "Check for updates but let you choose to
>>>>>>>>>>>>> install them"
>>>>>>>>>>>>> and as best as I can remember, its never disobeyed ...
>>>>>>>>>>>>
>>>>>>>>>>>> Should a user (for whatever reason) 'uninstall/re-install'
>>>>>>>>>>>> then that
>>>>>>>>>>>> radio button changes to 'automatically install/recommended'.
>>>>>>>>>>>>
>>>>>>>>>>>> Semi-OT, Thunderbird conversely holds the 'check for updates but
>>>>>>>>>>>> lemme
>>>>>>>>>>>> do the work' setting.
>>>>>>>>>>>
>>>>>>>>>>> I have had that setting for decades -- and still do. Some years
>>>>>>>>>>> ago it stopped working and some kind person posted the
>>>>>>>>>>> policies.json fix -- which worked until today. Posted herewith:
>>>>>>>>>>>
>>>>>>>>>>> Make a new firefox/distribution/ subdirectory which will contain
>>>>>>>>>>> the file policies.json which contains
>>>>>>>>>>> {
>>>>>>>>>>> "policies": {
>>>>>>>>>>> "DisableAppUpdate": true
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Did that 'kind person' provide a policies.json file for you to
>>>>>>>>>> download, or did you create one - on Linux?
>>>>>>>>>
>>>>>>>>> Someone posted about that file long ago, and the one I created with
>>>>>>>>> pico worked for years.
>>>>>>>>>> Just wondering how these Windows line endings - if that was the
>>>>>>>>>> problem - got there.
>>>>>>>>> They appeared when Firefox chose to update itself against my
>>>>>>>>> express
>>>>>>>>> wishes. I suspect that Firefox did it of its own volition -- or
>>>>>>>>> simple clumsiness. Core dump complete.
>>>>>>>>
>>>>>>>> You /found/ them after the unwanted update. Were they responsible
>>>>>>>> for it? I doubt it: line endings - of either type - are ignored
>>>>>>>> in a json file.
>>>>>>>
>>>>>>> The windows endings damaged the file such that it no longer
>>>>>>> served the
>>>>>>> purpose. Fixing it worked.
>>>>>>>
>>>>>>
>>>>>> Firefox doesn't care about line endings.
>>>>>>
>>>>>> Just for the sake of it I tested it for you, I created a policies.json
>>>>>> which blocks about:config and tested it with both CRLF (windows)
>>>>>> and LF
>>>>>> (unix) line endings.
>>>>>>
>>>>>> The result are the same for both, it works:
>>>>>> Blocked Page, Firefox can’t connect to the server at about:config
>>>>>>
>>>>>> ^M is not a corruption, this is how cat -A shows CR, your AI needs an
>>>>>> update.
>>>>>>
>>>>>> CRLF (windows):
>>>>>> cat -A policies.json
>>>>>> {^M$
>>>>>> "policies": {^M$
>>>>>> "BlockAboutConfig": true^M$
>>>>>> }^M$
>>>>>> }^M$
>>>>>>
>>>>>> LF (unix):
>>>>>> cat -A policies.json
>>>>>> {$
>>>>>> "policies": {$
>>>>>> "BlockAboutConfig": true$
>>>>>> }$
>>>>>> }$
>>>>>
>>>>> You tested whether it blocked about:config, but you didn't test whether
>>>>> it blocked an update, or if the update altered the json file.
>>>>
>>>> I tested policies.json, which was reported corrupted, with both
>>>> CRLF and LF, any policy will do, we don't need to wait for the
>>>> next update.
>>>> Policies.json is not included by default, updates will either not
>>>> touch it at all or remove it completely, depending on how you
>>>> update.
>>>> Since we can't see the original file there is no way to tell how
>>>> it was changed.
>>>
>>> Why might an update remove policies.json? I assume that the
>>> firefox updater will read it if it's there but never write to it.
>>> The point of it is that it's user, or organisation,
>>> controlled.
>>>
>>> I did wonder if updates might /update/ policies.json, for changes
>>> in format say, in the way they update a profile. But I doubt
>>> it.
>>>
>>> On Debian I have tarballs of Fx nightly and TB beta, in addtion to
>>> packaged versions for regular use. They do not include a
>>> distribution/ directory or a template policies.json.
>> No, they're not included with the tarball. "Some kind person"
>> posted the fix at some point in the past (earliest I have is Firefox
>> 72, July 7,2020) posted how to do it. If I want to use a newer
>> version I don't update. I download the tarball, untar it into its
>> own subdirectory and run it from within that subdirectory
>> (/blabla/firefox/firefox -P &). After running it once I exit and
>> copy over (cp -rf *) my previous profile into the newly created
>> profile. Accordingly, I have at least a dozen fully functional
>> firefoxes. TMI, but there it is.
>> Worked fine until somebody said that FF148 had some sort of security
>> problem, at which point I did an update to 149 rather than building
>> a whole new installation. I think I renamed the policies.json file,
>> which would have been the simplest thing. Sorry I can't be more
>> certain. Then I would have renamed it back. And then I got the
>> unwanted surprise of the 150 update. I turned the problem over to
>> Perplexity, which provided the solution. If anyone is interested I
>> can have Perplexity generate a nice pdf file of the entire
>> interchange.
>> I assume that firefox does some variant of cp -rf * when it updates
>> and then does some profile-creation stuff and god knows what else.
>> It must also use some touch-like command, becuase the date of the
>> policies.json file was the same as the date on all the other FF 150
>> subdirectories and files. I don't remember looking at the
>> FF149/firefox files because I would have had no reason to. And that
>> must be when the mischief occurred.
>> AH-HAH! At some point when I first heard about the policies.json
>> thing I was unsure about where to put it, so I put one in the
>> /firefox subdirectory. It's still there, and contains the ^M
>> characters. They seem to be M- instead of ^M, for what it's
>> worth. Its date is the same as all the others -- April 24 19:37.
>> cat -A policies.json
>> {$
>> M- "policies": {$
>> M- M- "DisableAppUpdate": true$
>> M- }$
>> }$
>> $
>>
>
> Why cat -A? Check man cat.
> In the output of cat -A "M-" is a tab, "^M" is a CR and "$" is a LF
> If you copy those literally into a script it will very likely produce
> an error.
My manual didn't say that. I tested:
hexdump -C tab.txt
00000000 09 0a |..|
00000002
cat -A tab.txt
^I$
So, tab is ^I, as you would expect if carriage return is ^M
I am starting to suspect that all this is a wild goose chase.
[toc] | [prev] | [next] | [standalone]
| From | The Real Bev <bashley101@gmail.com> |
|---|---|
| Date | 2026-04-30 20:16 -0700 |
| Message-ID | <10t15tn$14kib$1@dont-email.me> |
| In reply to | #16970 |
On 4/29/26 20:48, dillinger wrote:
> On 30/04/2026 05:30, The Real Bev wrote:
>> AH-HAH! At some point when I first heard about the policies.json thing
>> I was unsure about where to put it, so I put one in the /firefox
>> subdirectory. It's still there, and contains the ^M characters. They
>> seem to be M- instead of ^M, for what it's worth. Its date is the same
>> as all the others -- April 24 19:37.
>>
>> cat -A policies.json
>> {$
>> M- "policies": {$
>> M- M- "DisableAppUpdate": true$
>> M- }$
>> }$
>> $
>>
>
> Why cat -A? Check man cat.
> In the output of cat -A "M-" is a tab, "^M" is a CR and "$" is a LF
> If you copy those literally into a script it will very likely produce an
> error.
I don't use cat, so I assumed that the -A switch is supposed to show All
characters. That was just showing the corrupted/altered file because
somebody said it was too bad it didn't exist any more..
--
Cheers, Bev
Will give investment advice for food.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-05-03 21:47 +0000 |
| Message-ID | <10t8fq0$37epi$1@dont-email.me> |
| In reply to | #16977 |
On Thu, 30 Apr 2026 20:16:06 -0700, The Real Bev wrote: > I don't use cat ... WHAT?!!?? Whoever heard of a CLI veteran who never used cat??!!?? If anything, cat tends to be overused, at least by those at a certain point on the Dunning-Kruger curve <https://en.wiktionary.org/wiki/UUOC> ...
[toc] | [prev] | [next] | [standalone]
| From | The Real Bev <bashley101@gmail.com> |
|---|---|
| Date | 2026-05-03 19:33 -0700 |
| Message-ID | <10t90hi$3au6n$1@dont-email.me> |
| In reply to | #17033 |
On 5/3/26 14:47, Lawrence D’Oliveiro wrote:
> On Thu, 30 Apr 2026 20:16:06 -0700, The Real Bev wrote:
>
>> I don't use cat ...
>
> WHAT?!!?? Whoever heard of a CLI veteran who never used cat??!!??
Mostly I want to edit a file rather than just look at it.
And this is the most frequent ls alias (dird) I use and can't understand
why anybody would want anything else as a default:: ls -altGF
--color=yes |more
> If anything, cat tends to be overused, at least by those at a certain
> point on the Dunning-Kruger curve
> <https://en.wiktionary.org/wiki/UUOC> ...
Akin to Dunder-Mifflin, I understand...
--
Cheers, Bev
"The Flat Earth Society has members all over the globe."
-- Bob Henson
[toc] | [prev] | [next] | [standalone]
| From | Dave Royal <dave@dave123royal.com> |
|---|---|
| Date | 2026-05-01 07:04 +0000 |
| Message-ID | <10t1jag$17hp9$1@dont-email.me> |
| In reply to | #16958 |
On Wed, 29 Apr 2026 20:30:28 -0700, The Real Bev wrote:
> On 4/29/26 12:20, Dave Royal wrote:
>> dillinger <dillinger@invalid.not> Wrote in message:
>>
>>> On 29/04/2026 17:47, Richmond wrote:
>>>> dillinger <dillinger@invalid.not> writes:
>>>>
>>>>> Op 29-04-2026 om 04:36 schreef The Real Bev:
>>>>>> On 4/28/26 14:21, Dave Royal wrote:
>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>
>>>>>>>> On 4/28/26 02:14, Dave Royal wrote:
>>>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>>>
>>>>>>>>>> On 4/25/26 10:26, Nobody wrote:
>>>>>>>>>>> On Sat, 25 Apr 2026 18:18:07 +0100, Andy Burns
>>>>>>>>>>> <usenet@andyburns.uk>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Retirednoguilt wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I've never had FF update me autonomously.
>>>>>>>>>>>>
>>>>>>>>>>>> I have it set for "Check for updates but let you choose to
>>>>>>>>>>>> install them"
>>>>>>>>>>>> and as best as I can remember, its never disobeyed ...
>>>>>>>>>>>
>>>>>>>>>>> Should a user (for whatever reason) 'uninstall/re-install'
>>>>>>>>>>> then that radio button changes to 'automatically
>>>>>>>>>>> install/recommended'.
>>>>>>>>>>>
>>>>>>>>>>> Semi-OT, Thunderbird conversely holds the 'check for updates
>>>>>>>>>>> but lemme do the work' setting.
>>>>>>>>>>
>>>>>>>>>> I have had that setting for decades -- and still do. Some
>>>>>>>>>> years ago it stopped working and some kind person posted the
>>>>>>>>>> policies.json fix -- which worked until today. Posted
>>>>>>>>>> herewith:
>>>>>>>>>>
>>>>>>>>>> Make a new firefox/distribution/ subdirectory which will
>>>>>>>>>> contain the file policies.json which contains {
>>>>>>>>>> "policies": {
>>>>>>>>>> "DisableAppUpdate": true
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Did that 'kind person' provide a policies.json file for you to
>>>>>>>>> download, or did you create one - on Linux?
>>>>>>>>
>>>>>>>> Someone posted about that file long ago, and the one I created
>>>>>>>> with pico worked for years.
>>>>>>>>> Just wondering how these Windows line endings - if that was the
>>>>>>>>> problem - got there.
>>>>>>>> They appeared when Firefox chose to update itself against my
>>>>>>>> express wishes. I suspect that Firefox did it of its own
>>>>>>>> volition -- or simple clumsiness. Core dump complete.
>>>>>>>
>>>>>>> You /found/ them after the unwanted update. Were they responsible
>>>>>>> for it? I doubt it: line endings - of either type - are ignored
>>>>>>> in a json file.
>>>>>>
>>>>>> The windows endings damaged the file such that it no longer served
>>>>>> the purpose. Fixing it worked.
>>>>>>
>>>>>>
>>>>> Firefox doesn't care about line endings.
>>>>>
>>>>> Just for the sake of it I tested it for you, I created a
>>>>> policies.json which blocks about:config and tested it with both CRLF
>>>>> (windows) and LF (unix) line endings.
>>>>>
>>>>> The result are the same for both, it works:
>>>>> Blocked Page, Firefox can’t connect to the server at about:config
>>>>>
>>>>> ^M is not a corruption, this is how cat -A shows CR, your AI needs
>>>>> an update.
>>>>>
>>>>> CRLF (windows):
>>>>> cat -A policies.json {^M$
>>>>> "policies": {^M$
>>>>> "BlockAboutConfig": true^M$
>>>>> }^M$
>>>>> }^M$
>>>>>
>>>>> LF (unix):
>>>>> cat -A policies.json {$
>>>>> "policies": {$
>>>>> "BlockAboutConfig": true$
>>>>> }$
>>>>> }$
>>>>
>>>> You tested whether it blocked about:config, but you didn't test
>>>> whether it blocked an update, or if the update altered the json file.
>>>
>>> I tested policies.json, which was reported corrupted, with both CRLF
>>> and LF, any policy will do, we don't need to wait for the next update.
>>> Policies.json is not included by default, updates will either not
>>> touch it at all or remove it completely, depending on how you update.
>>> Since we can't see the original file there is no way to tell how it
>>> was changed.
>>
>> Why might an update remove policies.json? I assume that the
>> firefox updater will read it if it's there but never write to it.
>> The point of it is that it's user, or organisation,
>> controlled.
>>
>> I did wonder if updates might /update/ policies.json, for changes
>> in format say, in the way they update a profile. But I doubt it.
>>
>> On Debian I have tarballs of Fx nightly and TB beta, in addtion to
>> packaged versions for regular use. They do not include a
>> distribution/ directory or a template policies.json.
>
> No, they're not included with the tarball. "Some kind person" posted
> the fix at some point in the past (earliest I have is Firefox 72, July
> 7,2020) posted how to do it. If I want to use a newer version I don't
> update. I download the tarball, untar it into its own subdirectory and
> run it from within that subdirectory (/blabla/firefox/firefox -P &).
> After running it once I exit and copy over (cp -rf *) my previous
> profile into the newly created profile. Accordingly, I have at least a
> dozen fully functional firefoxes. TMI, but there it is.
>
> Worked fine until somebody said that FF148 had some sort of security
> problem, at which point I did an update to 149 rather than building a
> whole new installation. I think I renamed the policies.json file, which
> would have been the simplest thing. Sorry I can't be more certain. Then
> I would have renamed it back. And then I got the unwanted surprise of
> the 150 update. I turned the problem over to Perplexity, which provided
> the solution. If anyone is interested I can have Perplexity generate a
> nice pdf file of the entire interchange.
>
> I assume that firefox does some variant of cp -rf * when it updates and
> then does some profile-creation stuff and god knows what else. It must
> also use some touch-like command, becuase the date of the policies.json
> file was the same as the date on all the other FF 150 subdirectories and
> files. I don't remember looking at the FF149/firefox files because I
> would have had no reason to. And that must be when the mischief
> occurred.
I assumed (having never noticed) that update would only update selected
files.
Here on Debian 13 I have a tarball installation for Firefox nightly. I
haven't used it recently: it was v145. (All the files were dated 9/25 but
I /think/ that's because I copied it from another machines.) I just ran it
and allowed it to update itself, which was to 152. All the files and
directories are now dated today - which was not what I expected. But it
may because of the jump from 145 to 152. Maybe single-version updates
would do as I had expected.
AND it has created a firefox/distribution/distribution.ini file. I wrote
earlier that it didn't have a distribution/ directory, so unless I missed
it that is new since v145. (The Thunderbird beta tarball, which has been
used more recently does not have a distribution directory.)
[Global]
id=mozilla-official
version=1.0
about=Mozilla Firefox Official Build
But still no policies.json. I've put one in there to see whether it gets
touched at the next update.
Caveat: All this is with nightly, which may not update the same as
release.
> AH-HAH! [snip rest of post]
--
(Remove any numerics from my email address.)
[toc] | [prev] | [next] | [standalone]
| From | The Real Bev <bashley101@gmail.com> |
|---|---|
| Date | 2026-05-01 09:33 -0700 |
| Message-ID | <10t2kl4$1h9gu$3@dont-email.me> |
| In reply to | #16984 |
On 5/1/26 00:04, Dave Royal wrote: > On Wed, 29 Apr 2026 20:30:28 -0700, The Real Bev wrote: <massive snippage> >> I assume that firefox does some variant of cp -rf * when it updates and >> then does some profile-creation stuff and god knows what else. It must >> also use some touch-like command, becuase the date of the policies.json >> file was the same as the date on all the other FF 150 subdirectories and >> files. I don't remember looking at the FF149/firefox files because I >> would have had no reason to. And that must be when the mischief >> occurred. > > I assumed (having never noticed) that update would only update selected > files. > > Here on Debian 13 I have a tarball installation for Firefox nightly. I > haven't used it recently: it was v145. (All the files were dated 9/25 but > I /think/ that's because I copied it from another machines.) I just ran it > and allowed it to update itself, which was to 152. All the files and > directories are now dated today - which was not what I expected. But it > may because of the jump from 145 to 152. Maybe single-version updates > would do as I had expected. > > AND it has created a firefox/distribution/distribution.ini file. With the same date as all the other new files. I wonder when this started. My previous hand-created firefox/distribution subdirectory (containing only policies.json) was 148 so it has to have been 149 or 150. > I wrote > earlier that it didn't have a distribution/ directory, so unless I missed > it that is new since v145. (The Thunderbird beta tarball, which has been > used more recently does not have a distribution directory.) > > [Global] > id=mozilla-official > version=1.0 > about=Mozilla Firefox Official Build > > But still no policies.json. I've put one in there to see whether it gets > touched at the next update. > > Caveat: All this is with nightly, which may not update the same as > release. I used nightlies for maybe a year before installing the release version. Why would nightlies be any differet if the idea is to test before release? I never want files to change creation/edit dates unless edits are actually made. First thing I did was alias cp to cp -ia. Why is -a NOT the default? -- Cheers, Bev His men would follow him anywhere, but only out of morbid curiosity.
[toc] | [prev] | [next] | [standalone]
| From | Dave Royal <dave@dave123royal.com> |
|---|---|
| Date | 2026-05-01 18:00 +0100 |
| Message-ID | <10t2m7o$1i8ck$1@dont-email.me> |
| In reply to | #16990 |
The Real Bev <bashley101@gmail.com> Wrote in message: > On 5/1/26 00:04, Dave Royal wrote: >> On Wed, 29 Apr 2026 20:30:28 -0700, The Real Bev wrote: > <massive snippage> >>> I assume that firefox does some variant of cp -rf * when it updates and >>> then does some profile-creation stuff and god knows what else. It must >>> also use some touch-like command, becuase the date of the policies.json >>> file was the same as the date on all the other FF 150 subdirectories and >>> files. I don't remember looking at the FF149/firefox files because I >>> would have had no reason to. And that must be when the mischief >>> occurred. >> >> I assumed (having never noticed) that update would only update selected >> files. >> >> Here on Debian 13 I have a tarball installation for Firefox nightly. I >> haven't used it recently: it was v145. (All the files were dated 9/25 but >> I /think/ that's because I copied it from another machines.) I just ran it >> and allowed it to update itself, which was to 152. All the files and >> directories are now dated today - which was not what I expected. But it >> may because of the jump from 145 to 152. Maybe single-version updates >> would do as I had expected. >> >> AND it has created a firefox/distribution/distribution.ini file. > > With the same date as all the other new files. I wonder when this > started. My previous hand-created firefox/distribution subdirectory > (containing only policies.json) was 148 so it has to have been 149 or 150. > >> I wrote >> earlier that it didn't have a distribution/ directory, so unless I missed >> it that is new since v145. (The Thunderbird beta tarball, which has been >> used more recently does not have a distribution directory.) >> >> [Global] >> id=mozilla-official >> version=1.0 >> about=Mozilla Firefox Official Build >> >> But still no policies.json. I've put one in there to see whether it gets >> touched at the next update. >> >> Caveat: All this is with nightly, which may not update the same as >> release. > > I used nightlies for maybe a year before installing the release version. > Why would nightlies be any differet if the idea is to test before release? To test Firefox itself, yes, but not necessarily to test the release process. Nightles (alphas) are inherently buggy, so I can imagine that it's easier and safer to release the complete program, and not add bugs as a result of the release process being buggy. But I'm speculating. Maybe the Beta and Release versions are the same. My release version is an ESR Debian package updated by apt - the Debian package manager - so I don't know how a Release tarball updates itself. > [snip] -- Remove numerics from my email address.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-05-03 21:51 +0000 |
| Message-ID | <10t8g1o$37epi$2@dont-email.me> |
| In reply to | #16990 |
On Fri, 1 May 2026 09:33:40 -0700, The Real Bev wrote: > I never want files to change creation/edit dates unless edits are > actually made. First thing I did was alias cp to cp -ia. Why is -a > NOT the default? I tend to be a bit picky about timestamps, too. But I try to avoid such aliasing of common commands. I use “cp -p” a lot when running nonprivileged, or “cp --preserve=timestamps” when running privileged. I suppose the thing with plain “cp” is that the updated modification timestamp can be used to trigger build rules in software development projects.
[toc] | [prev] | [next] | [standalone]
| From | Dave Royal <dave@dave123royal.com> |
|---|---|
| Date | 2026-05-03 11:52 +0000 |
| Message-ID | <10t7cuj$2rvuo$1@dont-email.me> |
| In reply to | #16984 |
On Fri, 1 May 2026 07:04:48 -0000 (UTC), Dave Royal wrote:
> On Wed, 29 Apr 2026 20:30:28 -0700, The Real Bev wrote:
>
>> On 4/29/26 12:20, Dave Royal wrote:
>>> dillinger <dillinger@invalid.not> Wrote in message:
>>>
>>>> On 29/04/2026 17:47, Richmond wrote:
>>>>> dillinger <dillinger@invalid.not> writes:
>>>>>
>>>>>> Op 29-04-2026 om 04:36 schreef The Real Bev:
>>>>>>> On 4/28/26 14:21, Dave Royal wrote:
>>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>>
>>>>>>>>> On 4/28/26 02:14, Dave Royal wrote:
>>>>>>>>>> The Real Bev <bashley101@gmail.com> Wrote in message:
>>>>>>>>>>
>>>>>>>>>>> On 4/25/26 10:26, Nobody wrote:
>>>>>>>>>>>> On Sat, 25 Apr 2026 18:18:07 +0100, Andy Burns
>>>>>>>>>>>> <usenet@andyburns.uk>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Retirednoguilt wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've never had FF update me autonomously.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have it set for "Check for updates but let you choose to
>>>>>>>>>>>>> install them"
>>>>>>>>>>>>> and as best as I can remember, its never disobeyed ...
>>>>>>>>>>>>
>>>>>>>>>>>> Should a user (for whatever reason) 'uninstall/re-install'
>>>>>>>>>>>> then that radio button changes to 'automatically
>>>>>>>>>>>> install/recommended'.
>>>>>>>>>>>>
>>>>>>>>>>>> Semi-OT, Thunderbird conversely holds the 'check for updates
>>>>>>>>>>>> but lemme do the work' setting.
>>>>>>>>>>>
>>>>>>>>>>> I have had that setting for decades -- and still do. Some
>>>>>>>>>>> years ago it stopped working and some kind person posted the
>>>>>>>>>>> policies.json fix -- which worked until today. Posted
>>>>>>>>>>> herewith:
>>>>>>>>>>>
>>>>>>>>>>> Make a new firefox/distribution/ subdirectory which will
>>>>>>>>>>> contain the file policies.json which contains {
>>>>>>>>>>> "policies": {
>>>>>>>>>>> "DisableAppUpdate": true
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Did that 'kind person' provide a policies.json file for you to
>>>>>>>>>> download, or did you create one - on Linux?
>>>>>>>>>
>>>>>>>>> Someone posted about that file long ago, and the one I created
>>>>>>>>> with pico worked for years.
>>>>>>>>>> Just wondering how these Windows line endings - if that was the
>>>>>>>>>> problem - got there.
>>>>>>>>> They appeared when Firefox chose to update itself against my
>>>>>>>>> express wishes. I suspect that Firefox did it of its own
>>>>>>>>> volition -- or simple clumsiness. Core dump complete.
>>>>>>>>
>>>>>>>> You /found/ them after the unwanted update. Were they responsible
>>>>>>>> for it? I doubt it: line endings - of either type - are
>>>>>>>> ignored in a json file.
>>>>>>>
>>>>>>> The windows endings damaged the file such that it no longer served
>>>>>>> the purpose. Fixing it worked.
>>>>>>>
>>>>>>>
>>>>>> Firefox doesn't care about line endings.
>>>>>>
>>>>>> Just for the sake of it I tested it for you, I created a
>>>>>> policies.json which blocks about:config and tested it with both
>>>>>> CRLF (windows) and LF (unix) line endings.
>>>>>>
>>>>>> The result are the same for both, it works:
>>>>>> Blocked Page, Firefox can’t connect to the server at about:config
>>>>>>
>>>>>> ^M is not a corruption, this is how cat -A shows CR, your AI needs
>>>>>> an update.
>>>>>>
>>>>>> CRLF (windows):
>>>>>> cat -A policies.json {^M$
>>>>>> "policies": {^M$
>>>>>> "BlockAboutConfig": true^M$
>>>>>> }^M$
>>>>>> }^M$
>>>>>>
>>>>>> LF (unix):
>>>>>> cat -A policies.json {$
>>>>>> "policies": {$
>>>>>> "BlockAboutConfig": true$
>>>>>> }$
>>>>>> }$
>>>>>
>>>>> You tested whether it blocked about:config, but you didn't test
>>>>> whether it blocked an update, or if the update altered the json
>>>>> file.
>>>>
>>>> I tested policies.json, which was reported corrupted, with both CRLF
>>>> and LF, any policy will do, we don't need to wait for the next
>>>> update.
>>>> Policies.json is not included by default, updates will either not
>>>> touch it at all or remove it completely, depending on how you update.
>>>> Since we can't see the original file there is no way to tell how it
>>>> was changed.
>>>
>>> Why might an update remove policies.json? I assume that the
>>> firefox updater will read it if it's there but never write to it.
>>> The point of it is that it's user, or organisation,
>>> controlled.
>>>
>>> I did wonder if updates might /update/ policies.json, for changes
>>> in format say, in the way they update a profile. But I doubt it.
>>>
>>> On Debian I have tarballs of Fx nightly and TB beta, in addtion to
>>> packaged versions for regular use. They do not include a
>>> distribution/ directory or a template policies.json.
>>
>> No, they're not included with the tarball. "Some kind person" posted
>> the fix at some point in the past (earliest I have is Firefox 72, July
>> 7,2020) posted how to do it. If I want to use a newer version I don't
>> update. I download the tarball, untar it into its own subdirectory and
>> run it from within that subdirectory (/blabla/firefox/firefox -P &).
>> After running it once I exit and copy over (cp -rf *) my previous
>> profile into the newly created profile. Accordingly, I have at least a
>> dozen fully functional firefoxes. TMI, but there it is.
>>
>> Worked fine until somebody said that FF148 had some sort of security
>> problem, at which point I did an update to 149 rather than building a
>> whole new installation. I think I renamed the policies.json file,
>> which would have been the simplest thing. Sorry I can't be more
>> certain. Then I would have renamed it back. And then I got the
>> unwanted surprise of the 150 update. I turned the problem over to
>> Perplexity, which provided the solution. If anyone is interested I can
>> have Perplexity generate a nice pdf file of the entire interchange.
>>
>> I assume that firefox does some variant of cp -rf * when it updates and
>> then does some profile-creation stuff and god knows what else. It must
>> also use some touch-like command, becuase the date of the policies.json
>> file was the same as the date on all the other FF 150 subdirectories
>> and files. I don't remember looking at the FF149/firefox files because
>> I would have had no reason to. And that must be when the mischief
>> occurred.
>
> I assumed (having never noticed) that update would only update selected
> files.
>
> Here on Debian 13 I have a tarball installation for Firefox nightly. I
> haven't used it recently: it was v145. (All the files were dated 9/25
> but I /think/ that's because I copied it from another machines.) I just
> ran it and allowed it to update itself, which was to 152. All the files
> and directories are now dated today - which was not what I expected. But
> it may because of the jump from 145 to 152. Maybe single-version updates
> would do as I had expected.
>
> AND it has created a firefox/distribution/distribution.ini file. I wrote
> earlier that it didn't have a distribution/ directory, so unless I
> missed it that is new since v145. (The Thunderbird beta tarball, which
> has been used more recently does not have a distribution directory.)
>
> [Global]
> id=mozilla-official version=1.0 about=Mozilla Firefox Official Build
>
> But still no policies.json. I've put one in there to see whether it gets
> touched at the next update.
Yes, it did. After the update all files are dated identically, including
policies.json.
Might it be changed - e.g. errors corrected, keys re-ordered, obsolete
keys removed, file re-encoded, prettified? No idea.
> Caveat: All this is with nightly, which may not update the same as
> release.
>
>> AH-HAH! [snip rest of post]
--
(Remove any numerics from my email address.)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-05-01 08:09 +0000 |
| Message-ID | <10t1n4h$196ee$1@dont-email.me> |
| In reply to | #16919 |
On Tue, 28 Apr 2026 19:36:56 -0700, The Real Bev wrote: > The windows endings damaged the file such that it no longer served > the purpose. Fixing it worked. In case it’s relevant, I keep seeing those “^M” sequences in postings from you when I paste the text into Emacs. I just find that odd, for a Linux user ...
[toc] | [prev] | [next] | [standalone]
| From | The Real Bev <bashley101@gmail.com> |
|---|---|
| Date | 2026-05-01 09:17 -0700 |
| Message-ID | <10t2jn7$1h9gu$2@dont-email.me> |
| In reply to | #16985 |
On 5/1/26 01:09, Lawrence D’Oliveiro wrote: > On Tue, 28 Apr 2026 19:36:56 -0700, The Real Bev wrote: > >> The windows endings damaged the file such that it no longer served >> the purpose. Fixing it worked. > > In case it’s relevant, I keep seeing those “^M” sequences in postings > from you when I paste the text into Emacs. > > I just find that odd, for a Linux user ... Blame Thunderbird. -- Cheers, Bev His men would follow him anywhere, but only out of morbid curiosity.
[toc] | [prev] | [next] | [standalone]
| From | Frank Miller <miller@posteo.ee> |
|---|---|
| Date | 2026-05-01 19:10 +0200 |
| Message-ID | <69F4DE79.7090604@backwurst.de> |
| In reply to | #16989 |
The Real Bev wrote: > On 5/1/26 01:09, Lawrence D’Oliveiro wrote: >> On Tue, 28 Apr 2026 19:36:56 -0700, The Real Bev wrote: >> >>> The windows endings damaged the file such that it no longer served >>> the purpose. Fixing it worked. >> >> In case it’s relevant, I keep seeing those “^M” sequences in postings >> from you when I paste the text into Emacs. >> >> I just find that odd, for a Linux user ... > > Blame Thunderbird. Yes. Just blame Thunderbird, blame Firefox, blame Mozilla as a whole. Or better blame Microsoft or Linux, blame the developers of software. But never take responsibility for all that weird mix up of an operating system you created but don't understand yourself.
[toc] | [prev] | [next] | [standalone]
| From | R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> |
|---|---|
| Date | 2026-05-01 20:16 +0200 |
| Message-ID | <10t2qlo$2ktq4$1@paganini.bofh.team> |
| In reply to | #16993 |
Frank Miller wrote: > The Real Bev wrote: >> On 5/1/26 01:09, Lawrence D’Oliveiro wrote: >>> On Tue, 28 Apr 2026 19:36:56 -0700, The Real Bev wrote: >>> >>>> The windows endings damaged the file such that it no longer served >>>> the purpose. Fixing it worked. >>> >>> In case it’s relevant, I keep seeing those “^M” sequences in postings >>> from you when I paste the text into Emacs. >>> >>> I just find that odd, for a Linux user ... >> >> Blame Thunderbird. > > Yes. Just blame Thunderbird, blame Firefox, blame Mozilla as a whole. > Or better blame Microsoft or Linux, blame the developers of software. > But never take responsibility for all that weird mix up of an operating > system you created but don't understand yourself. > You have no idea, https://www.youtube.com/watch?v=bOR38552MJA - Blame Canada!
[toc] | [prev] | [next] | [standalone]
| From | Nobody <jock@soccer.com> |
|---|---|
| Date | 2026-05-01 12:57 -0700 |
| Message-ID | <q11avk9bmm35eeqpcitnoa4k2n5ov75c1r@4ax.com> |
| In reply to | #16997 |
On Fri, 1 May 2026 20:16:24 +0200, R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> wrote: >Frank Miller wrote: >> The Real Bev wrote: >>> On 5/1/26 01:09, Lawrence D’Oliveiro wrote: >>>> On Tue, 28 Apr 2026 19:36:56 -0700, The Real Bev wrote: >>>> >>>>> The windows endings damaged the file such that it no longer served >>>>> the purpose. Fixing it worked. >>>> >>>> In case it’s relevant, I keep seeing those “^M” sequences in postings >>>> from you when I paste the text into Emacs. >>>> >>>> I just find that odd, for a Linux user ... >>> >>> Blame Thunderbird. >> >> Yes. Just blame Thunderbird, blame Firefox, blame Mozilla as a whole. >> Or better blame Microsoft or Linux, blame the developers of software. >> But never take responsibility for all that weird mix up of an operating >> system you created but don't understand yourself. >> > >You have no idea, https://www.youtube.com/watch?v=bOR38552MJA - Blame >Canada! OT: ha, ha funny... until that disgusting epithet hurled at a well-known Nova Scotian singer. Humour/satire doesn't carry the right to insult others by name.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | alt.comp.software.firefox
csiph-web