Modification time of language packs is invalid

[mfschumann]

It shows as 1 Jan 1970 in the extensions manager because that is the mtime of /app/share/runtime/locale/*. Can we preserve the actual modification date when repacking the langpack?

[mfschumann]

As per https://github.com/flatpak/flatpak/issues/5542 this is by design.

@Betterbird Could you patch the language pack details view to hide the "most recent update date" row when FLATPAK_COMPILE is set?

Right now it shows the modification time of the language pack .xpi file which is reset to 01/01/1970 when it is packed into the flatpak.

[Betterbird]

I'm confused here. The ones we build an distribute look like this:

Where does the "Last Updated" timestamp come from? It's not in the language pack manifest.json file.

It would be good if we didn't have to mess around with Mozilla platform code just because your build doesn't get the date right. Besides, FLATPAK_COMPILE is a C++ compile flag, and extension handling in Mozilla is all in JS. How do language packs look in TB, what date do they have?

[mfschumann]

The timestamp shown in this dialog is the modification time of the language pack .xpi file that we ship as distribution extension. The problem with this approach is that the modification time of almost all files that are packed into the flatpak sandbox is being reset to 01/01/1970. So when Betterbird runs it can only see language packs with modification time 01/01/1970 and shows this date as "Last Update" timestamp.

Flatpak devs pointed out that resetting the modification time is intentional (https://github.com/flatpak/flatpak/issues/5542#issuecomment-1856030210) and there is no way to fix this issue during build.

For the TB flatpak the timestamp is shown correctly because they don't ship language packs as distribution extensions (i.e. in the sandbox), but as user extensions.

[Betterbird]

I can put it onto the TO-DO list, but there are more important things. As I said, the flag is nothing we can access in JS code. And the Mozilla add-on manage is code I'd rather not touch too much.

[mfschumann]

Completely understood. It is a cosmetic issue after all, I just wanted to let you know about this issue and that I don't see what I can do about it on my end ;-)

[Betterbird]

Be happy that some parts of the system are from 1970, the "cool" hippie era years ;-)

[Betterbird]

We took a look, the code is here: https://searchfox.org/mozilla-esr115/rev/91fdddde76ece8836ce76560d59a51b335d2f302/toolkit/mozapps/extensions/content/aboutaddons.js#2327-2336

    let updateDate = this.querySelector(".addon-detail-row-lastUpdated");
    if (addon.updateDate) {
      let lastUpdated = addon.updateDate.toLocaleDateString(undefined, {
        year: "numeric",
        month: "long",
        day: "numeric",
      });
      updateDate.appendChild(new Text(lastUpdated));
    } else {
      updateDate.hidden = true;
    }

One could test addon.updateDate for 01/01/1970 and not show that since it's a lie anyway.

That's like a one liner.

[mfschumann]

Thanks for fixing this!