deCDN

[thosrtanner]

Ah. OK, this is what the event log says:

Code: Select all

Faulting application name: palemoon.exe, version: 6.7.0.9101, time stamp: 0x674cc60c
Faulting module name: xul.dll, version: 6.7.0.9101, time stamp: 0x674cc6a6
Exception code: 0xc0000005
Fault offset: 0x00000000007aa57c
Faulting process id: 0x0x8A68
Faulting application start time: 0x0x1DB6358243A7271
Faulting application path: C:\Program Files\Pale Moon\palemoon.exe
Faulting module path: C:\Program Files\Pale Moon\xul.dll
Report Id: 91985086-b01f-4cff-8e54-61370857275d
Faulting package full name: 
Faulting package-relative application ID: 

Not sure how to attach a debugger but I'll give it a try next time I'm feeling brave

[RealityRipple]

If there's anything further I can provide to help you work out what is going on, I'd be happy to help.

Just to confirm, you're using the release build (33.1), not the pre-release with bundle and google font support (33.2pre)?

I'll need a list of extensions and plugins you have installed to see if there's a conflict.

It'd also be a good idea to confirm that you successfully downloaded and extracted the LocalCDN resources - see earlier in this topic to determine if the branch list loaded in the config window, if the zip archive downloaded and extracted, and if the extension successfully read the extracted files.

[thosrtanner]

Yes, I've done that check succesfully (after reading the comment about ticking the right box first) and it has the list of cdns installed.

[RealityRipple]

Code: Select all

Fault offset: 0x00000000007aa57c
Faulting module path: C:\Program Files\Pale Moon\xul.dll

I'm not particularly good with WinDbg, but it looks like the error is being triggered by "NormalizedConstraintSet::Range<bool>::Merge"? Assuming you're on 33.5.0, anyway. As far as I can tell, NormalizedConstraintSet should only be used by WebRTC, which should be disabled at compile-time, and should have nothing to do with Pale Moon. So either you're not on 33.5.0 or I've messed up entirely.

[thosrtanner]

yup 33.5.0 54 bit.

[RealityRipple]

Well, then I think I've failed to use WinDBG correctly. I'll try putting a test profile of the same add-ons as you sent me, but you're using a lot of extensions that are dependent on user-chosen settings and scripts and whatnot, so it might not be as effective as you trying the normal debug process yourself - start with all add-ons disabled, see if there's a problem with your base browser settings, and enable extensions one by one until the crash occurs.

[frostknight]

yup 33.5.0 54 bit.

64 bit you mean.

[thosrtanner]

64 +/- experimental error.

[Moonchild]

64 +/- experimental error.

64 +/- 2cm finger-slip

[Drugwash]

OS: Linux Mint 19.2 Cinnamon x64
Pale Moon: 33.6.0 x64 GTK3 SSE2 (Nuck-TH)
deCDN: 33.1

Just installed this extension minutes ago. Noticed the Preferences window doesn't update the Repo Commit field after (re)downloading - it requires closing the Preferences window and reopening it in order to notice the commit number on success. Just a small bug but could drive people into reporting false failures.

Was thinking, as some users asked about adding custom domains/links to the list and/or need a strict(er) check of the list update: would it be possible to add code for loading a previously downloaded (and possibly manually edited) list archive from a local/networked resource, while at the same time allowing automatic list update to be disabled? Could be useful for network admins too - avoids redownloading same file N times. Just an idea.

Thanks for your work, will see how this extension works in time. For now Decentraleyes is disabled. Will have to edit options in NoScript and RequestPolicy as well.

[RealityRipple]

Noticed the Preferences window doesn't update the Repo Commit field after (re)downloading - it requires closing the Preferences window and reopening it in order to notice the commit number on success.

You mean when pressing the new Erase/Reset button? The extension doesn't actually do any of the erasing/resetting until you hit OK in the preferences - just in case, I wanted to make it so you could hit Cancel and prevent the erasure. Or are you opening the preferences again after hitting OK but before the archive has been re-downloaded? I'll have to check that...

Would it be possible to add code for loading a previously downloaded (and possibly manually edited) list archive from a local/networked resource, while at the same time allowing automatic list update to be disabled? Could be useful for network admins too - avoids redownloading same file N times.

The extension won't redownload the same file regardless - it checks the LocalCDN commit hash before initiating the download, to prevent just that.

At present, the best way to achieve what you're talking about would be to make your own clone of the LocalCDN repository in a self-hosted GitLab/Codeberg repo. I specifically included the preferences extensions.decdn.repo.branches.api, extensions.decdn.repo.url.base, extensions.decdn.repo.url.zip, and even extensions.decdn.repo.url.graph (for the preferences window) to allow use of any repo you choose. However, I can see the merit in using a more direct archive access, and I might be able to rig something up. However, it will likely only be available through direct about:config preferences, as the chances of non-technical users breaking their extension is high for something like that.

[Drugwash]

You mean when pressing the new Erase/Reset button? [...] Or are you opening the preferences again after hitting OK but before the archive has been re-downloaded? I'll have to check that...

Not the former but something similar to the latter. I installed the extension and went to its Preferences, but at the time it had not finished downloading/unpacking the archive (speed limited by ISP according to contract), and when finished it did not update the Repo Commit status, so I thought there may have been some error. Switched to the devel version which was more recent, clicked the download button and waited for a confirmation of some sort - which would have been the commit number. As it didn't do anything like that I closed the Preferences dialog and then reopened it; only then had it shown the commit number signifying the update had been succesful.

I can see the merit in using a more direct archive access, and I might be able to rig something up. However, it will likely only be available through direct about:config preferences, as the chances of non-technical users breaking their extension is high for something like that.

For a single machine/browser profile that may be acceptable, in principle, but when dealing with multiple machines and/or profiles that could be cumbersome, albeit it would be (?) a one-time setting. Dunno, it's not my own user case but reading through the topic thought it could be useful for some people. Decision is yours.

[RealityRipple]

There isn't a "download" button - I think you might have mistaken the "refresh branches" button?

In either case, I've confirmed the base problem and it'll show the new commit when it changes. Thanks for bringing the issue to my attention.

[Drugwash]

There isn't a "download" button - I think you might have mistaken the "refresh branches" button?

Most likely - it's so tiny, and my eyesight worse every day. And there's no tooltip.

Screenshot from 2025-02-10 21-02-55.jpg

In either case, I've confirmed the base problem and it'll show the new commit when it changes. Thanks for bringing the issue to my attention.

Thank you for the quick response.

[RealityRipple]

Yup. I'll add a tooltip descriptor to that as well!

Edit: Done and done. New version, v33.2, includes Google Font blocking, Bundle support (except MathJax because of an incompatibility with redirecting fonts), and improves the preferences window's responsiveness as discussed above.

[Drugwash]

Got 33.2. Tooltip works (thanks!) however it doesn't seem to do anything after clicking Erase/Reset - files are still there in the decdn folder with the old timestamp (16:23) when first installed. Have I got something wrong? Should the Preferences window be closed in order to perform the update?

[RealityRipple]

Got 33.2. Tooltip works (thanks!) however it doesn't seem to do anything after clicking Erase/Reset - files are still there in the decdn folder with the old timestamp (16:23) when first installed. Have I got something wrong? Should the Preferences window be closed in order to perform the update?

Yes, as I said, if you hit OK on the Preferences window, it performs the reset, if you hit Cancel, it cancels the changes. I'm kind of a stickler about the options window paradigm: until you hit "OK" or "Apply" in one, none of the things you do in the window should actually occur.

[BenFenner]

I'm kind of a stickler about the options window paradigm: until you hit "OK" or "Apply" in one, none of the things you do in the window should actually occur.

And thank you for that.

[Drugwash]

Yes, as I said, if you hit OK on the Preferences window, it performs the reset, if you hit Cancel, it cancels the changes. I'm kind of a stickler about the options window paradigm: until you hit "OK" or "Apply" in one, none of the things you do in the window should actually occur.

Yeah, that's a sound logic alright but heh, thing is there's no OK or Cancel there - there's only Close (as per the screenshot above), and one has no idea whether the action they triggered has been performed or not. Usually people need a feedback of some sort in such case. If there was an Apply button then yes, it would be intuitive. However in Linux world there's rarely such thing (button) - any change is performed instantly. I kinda got used to this kind of behavior quite quickly after leaving the Windows world, and I assume other Linux PM users would reason similarly. Since there's only a Close button one would assume every action has been performed instantly, regardless of running under Linux or Windows. Am I wrong?

Anyway, just now I repeated the operation: opened deCDN Preferences dialog, hit Erase/Reset, OK on the confirmation dialog, and then Close. Old files are still there with same timestamp.
Maybe the check for commit version prevents the delete/download when it finds them as being identical. But what happens when the user really needs to clean up the old files due to file corruption or whatever other reason?

[RealityRipple]

Yes, as I said, if you hit OK on the Preferences window, it performs the reset, if you hit Cancel, it cancels the changes. I'm kind of a stickler about the options window paradigm: until you hit "OK" or "Apply" in one, none of the things you do in the window should actually occur.

Yeah, that's a sound logic alright but heh, thing is there's no OK or Cancel there - there's only Close (as per the screenshot above), and one has no idea whether the action they triggered has been performed or not. Usually people need a feedback of some sort in such case. If there was an Apply button then yes, it would be intuitive. However in Linux world there's rarely such thing (button) - any change is performed instantly. I kinda got used to this kind of behavior quite quickly after leaving the Windows world, and I assume other Linux PM users would reason similarly. Since there's only a Close button one would assume every action has been performed instantly, regardless of running under Linux or Windows. Am I wrong?

Anyway, just now I repeated the operation: opened deCDN Preferences dialog, hit Erase/Reset, OK on the confirmation dialog, and then Close. Old files are still there with same timestamp.
Maybe the check for commit version prevents the delete/download when it finds them as being identical. But what happens when the user really needs to clean up the old files due to file corruption or whatever other reason?

That's a difference in how the browser renders Preference dialog boxes - if "browser.preferences.instantApply" is set to false, it does show an OK and Cancel button. I figured the "onbeforeaccept" event would run when "instantApply" is set to true and the user hits Close, but apparently that assumption was wrong. I guess I'm going to have to add instantApply-awareness by hand...

I'll try to get another update out by Wednesday at the latest. In the meantime, I suggest toggling instantApply for now.