Pale Moon forum

Doesn't want to work on beta 3

https://www.canadapost.ca/cpotools/apps ... &LOCALE=en

Looks fine here, 27.0.0b3 x64 on W7 with uBlockO.

Yes again we have a situation of permissions that WORKED in PM26 and earlier and now don't work in Beta.
Setting "maintain offline storage" to ALWAYS ASK allows the site to work. BUT IT NEVER ASKS!!

There is obviously something wrong with this permission manager.

Do you mean this (mine - nothing stored or asked) ?:

about:permissions

paste that in the address bar...I wouldn't monkey with it though if yours works, leave it

Mine's also Always ask - but there's nothing stored anyway... red herring? Something else causing the difference?

The problem is if I set the site individually to allow, it still wont work, only if I set all sites to always ask will it work.
Even twitter is doing it.

Okay, it's a beta, until Moonchild weighs in, how about you changing those prefs to find settings that work for you and report back?

I checked the canada post site.
It doesn't matter what setting I set the site's offline storage to (including block and allow), it works. It doesn't seem to store any local app data, as Satrow observed.
Are you blocking anything else that might interfere? have you tried on a new profile or with reset preferences?

I even checked with dom.storage.enabled set to false, and it still worked... so something must certainly be interfering in your setup.

ok brand new profile, I deleted the old profile and let PM create a new one.

https://youtu.be/CxEnueW_Os4

watch in HD

What it looks like to me is:

The data needed for the site to get tracking data is not pulled directly from the website's domain, but from a separate domain, instead (all too common because the front-end (canadapost) and the back-end (the logistics tracking provider) are very likely not operated or provided the same company).

So, when you BLOCK this for all sites, you will BLOCK it for the tracker server (regardless of whether you allow it for the website), resulting in it not working.
And if you ALLOW it for all sites (a manual confirmation with "ask" will normally only be triggered over a certain threshhold) then the tracker server will be able to store the data even if you block it for the website.

EDIT: Digging a bit deeper:
When "all sites" offline storage is blocked, it toggles dom.indexedDB.enabled to "false", and the site throws the following errors:
InvalidStateError: A mutation operation was attempted on a database that did not allow mutations. modernizr.js:8:0
ReferenceError: Modernizr is not defined search_autocomplete.js:137:0
ReferenceError: Modernizr is not defined findByTrackNumber:303:7

The first error is the key one. Unfortunately it's minified without a source map, so that makes it difficult to see what's happening, but my guess is that modernizr breaks if it can't juggle data in a local/temporary store (e.g. when trying to access its embedder's source docs). Because of that, the modernizr object is unavailable to the scripts that call it later on, and bam, no working tracking as a result.

EDIT2: This is bug #1192643 (blocking for all sites disables IndexedDB (sets dom.indexedDB.enabled to false)) -> indexedDB throws because it's disabled (it shouldn't throw, that's a bug) -> modernizr fails to initialize -> tracking fails.

EDIT3: The fix for this is relatively easy, actually - just don't throw, but return undefined/null instead. That way, even when indexedDB is switched off as part of globally denying offline storage (it sort of makes sense to do that), the detection of the API being available or not doesn't error out but acts as if it was never there to begin with, which makes feature detection as it's supposed to be done happy.

Fixed in https://github.com/MoonchildProductions/Pale-Moon/commit/84d8514ae8c00b860ae823f915d40973791175b0